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

[Philipp von Weitershausen]

Godefroid Chapelle wrote:
>> 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 ?

Suppose you don't want to translate messages in a particular template 
that you want to have translated in others (for example editing vs. 
displaying a piece of translatable content). Or, suppose you want a 
particular message id translated in a different language than another 
one... Or, suppose you're building an app that manages message ids...

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

If we had that option, the template author would need to think of 
translation anyway, so we could just as well make it straight-forward 
and have it off by default.

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

We've had the responsibility discussion back then, too. To remind you, 
ZPT is not the only form to turn a Message ID into a translated string. 
In Zope 3, it happens often enough that a Python-written browser view 
returns a translatable message to the browser directly. In this case, 
you do not only have to declare a user message as MessageID, you also 
have to call zope.i18n.translate() explicitly.

It is one thing to denote something as translatable. It is another to 
perform the actual translation. ZPT hides this separation (separation of 
concerns, to use your vocabulary!) for strings defined in the template. 
It shouldn't do so for other objects.

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

Even that is wrong. Simply doing tal:content="pi" (where 'pi' holds the 
number pi) is just as much an i18n bug as is forgetting to translate a 
sring in a user interface. Numbers, at least floating point numbers, 
need to be formatted appropriately according the user's locale. Some 
locales use the comma as a decimal separator, so pi would be 3,1415 in 
German, not 3.1415. Also, it often makes little sense displaying all 15 
decimal places of pi, two or three are often enough. All this is 
appropriate formatting that the template author needs to be aware of.

A ZPT template author is expected to know these things and to format 
incoming values appropriately. Whether that is a MessageID that needs to 
be translated, a number or datetime object that needs to be formatted or 
any other object whose API needs to be known in order to work on it (and 
even it is only a list that is iterated over).

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

As I said above, the ZPT template author should know about the things 
he's inserting into the template. Noone does tal:content="context". You 
always do tal:content="context/useTheObjectsApi". The spelling with 
formatting numbers/dates and translating strings is a bit different, but 
it is a presentation issue... That's just the way ZPT is. It's debatable 
whether it's a good approach, some would probably draw the separation 
line of concerns elsewhere (e.g. clearsilver), but ZPT does it this way.

Philipp