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

[Dmitry Vasiliev]

Philipp von Weitershausen wrote:
> 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.

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"
>         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.

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.

> Thoughts?

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 hlabs.spb.ru)
     http://hlabs.spb.ru