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 _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com