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

[Godefroid Chapelle]

Philipp von Weitershausen wrote:
> Dmitry Vasiliev wrote:
> 
>> Recently Stephan and me have a discussion on the IRC about purpose of 
>> i18n:translate attribute for tags with dynamic content through 
>> tal:content attribute. Stephan pointed out that i18n:translate in this 
>> case is just a marker for call translate() later. But later I 
>> discovered that TALInterpreter.do_isertText_tal() does the automatic 
>> translation for all MessageID's even when the t18n:translate isn't 
>> present.
>>
>> So now the question: Do we need automatic translation for all 
>> MessageID's?
> 
> 
> No, we don't need it. In fact, there has been a discussion on this a 
> while ago in which Godefroid raised the issue that automatic translation 
> of MessageIDs wasn't always happening.

I stated automatic translation is a desirable feature.

See below for a new trial at explaining why.

AFAIK, Silva has been i18ned using this pattern.

> Jim, some other people and I 
> argued that this kind of automation is bad anyway and instead of 
> introducing more translation magic, TAL shouldn't do any automatic 
> translation at all.
> 
> So, in my opinion, do_insertText_tal() should raise a DeprecationWarning 
> if it encounters a MessageID/Message object that doesn't have an 
> accompanying i18n:translate declaration.
> 
>> Stephan also have pointed that automatic translation doesn't allow 
>> somebody to disable translation on purpose for some piece of content.
> 
> 
> Right. That's one reason why it's bad.

Can someone explain this use case a bit deeper ?

If this is a crucial use case, we could still better have 
i18n:translate="nothing" or i18n:disable="" or i18n:omit-translate or 
whatever on the specific places that needs to disable translation when 
the python module author thought it should be translated.
> 
>> I'm personally think that automatic translation would be helpful in 
>> some cases.
> 
> 
> Helpful in the sense of saving a few characters to type -- yes. In any 
> other way it is more magic than sensible automation.

No, helpful in the way that it separates clearly the responsibilities : 
- the template writer is responsible of declaring what needs to be 
translated among the strings he controls in the template itself
- while the python module writer is responsible of declaring which 
strings need to be translated among the strings he controls in the 
module itself.

Do we ask the template writer to know about the type of the dynamic 
values (like integers or floats) that come back and to explicitely 
convert them to strings ?
No, we IMPLICITELY and MAGICALLY transform them to strings ;-)
So that the template writer is insulated from this type of plumbery.

Demanding i18n:translate on message ids is demanding the template writer 
to check types of dynamic values each time he uses a tal:content or 
tal:attributes in order to not forget to add the i18n:translate in case 
the dynamic value he wants to output is a Message Id.
> 
> Philipp

sincerely-hoping-to-express-myself-better-than-last-time-in-order-to-get-understood,

Godefroid