[Zope3-dev] Re: MessageID's automatic translation in TAL

[Philipp von Weitershausen]

Stephan Richter wrote:
> On Friday 06 May 2005 10:11, Dmitry Vasiliev wrote:
> 
>>Opinions?
> 
> Dimitry, I am sorry. There was already a papal's edict on the issue:
> 
> http://mail.zope.org/pipermail/zope3-dev/2004-September/012186.html
> 
> 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.

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"
         i18n:translate="explicit_message_id"
         />

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.


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.

Thoughts?

Philipp