Philipp von Weitershausen wrote:
Stephan Richter wrote:

On Friday 06 May 2005 10:11, Dmitry Vasiliev wrote:


Dimitry, I am sorry. There was already a papal's edict on the issue:

That means, message ids must be translated explicitely using i18n:translate. So, Dimitry, you can go ahead and deprecate the implict tranlation of message ids.

Great. I guess that also means backing out most of r30249.

Yes, and I pretty sure that we'll found much more cases of implicit translation.

Btw, I dug through the thread and found an 'interesting' edge case that we might want to look into as well. Imagine you have

  <span tal:content="view/getMeSomeI18nMessage"

IMO, this shouldn't happen, meaning it should be a syntax error to use tal:content and an explicit message id in i18n:translate in the same tag. Maybe this was already fixed, but I would guess not.

The fix will be trivial anyway.

A note about the edict:

The edict doesn't rule out a change of semantics, provided it was written out in a proposal. For example, thinking about the above edge case, it struck me that i18n:translate is really used for two things:

a) Translating a static string in the template

  <p i18n:translate="heading-greeting">Greetings, user!</p>

b) Translating a message id coming from Python code:

  <p tal:content="view/getAnI18nMessage" i18n:translate="">...</p>

So, i18n:translate has two different semantics, depending whether you're using it for case a) or b). In case b), for example, stating an explicit message id is nonsense, as I've stated in the edge case above.

So, here's an idea: Let's limit the use of i18n:translate to case a) and introduce i18n versions of tal:content and tal:replace that mean "insert the message id and translate it". It would look like that:

 <span i18n:content="view/getAnI18nMessage">...</span>

instead of

  <span tal:content="view/getAnI18nMessage" i18n:translate="">...</span>

The latter would be deprecated/forbidden. That would get rid of any ambiguity regarding i18n:translate and thus also a lot easier for message id extraction tools. They wouldn't collect false message ids anymore.

Also, we could even require the input of i18n:content to always be an i18n message id. So, if view.getAnI18nMessage() return a mere string, it wouldn't be translated. But maybe there are use cases against this.

It wouldn't be translated anyway since i18n:content will be only translation phase and we can't define a msgid for dynamic content, we just can pass the string through or raise an error/warning.


I like the idea and I'm ready to implement the proposal, but I like to do it after 3.1 will be released.

Dmitry Vasiliev (dima at

Zope3-dev mailing list

Reply via email to