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