Re: [Zope3-dev] Re: MessageID's automatic translation in TAL
Philipp von Weitershausen wrote:
Dmitry Vasiliev wrote:
- Should we do automatic translation for msgid's inside a TALES
expression?
IMO we shouldn't do automatic translation at all.
How then we want to translate TALES expressions like some text ${msgid}?
The only way now is explicit translate() inside the view.
- Maybe we need some new TALES expression type for msgid definition?
For example:
tal:block define=name msgid:Specific
Why? Use case?
See zope/app/apidoc/ifacemodule/iface_macros.pt at the end. With the msgid
type we can define msgid's right in TAL code.
--
Dmitry Vasiliev (dima at hlabs.spb.ru)
http://hlabs.spb.ru
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: MessageID's automatic translation in TAL
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-greetingGreetings, 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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: MessageID's automatic translation in TAL
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. 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. 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-greetingGreetings, 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. Thoughts? Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: MessageID's automatic translation in TAL
On Sunday 08 May 2005 10:01, Philipp von Weitershausen wrote: Thoughts? I don't mind the two semantics. I just think that if tal:content and an explicit message id in i18n:translate is specified, an error should be raised. I bet you it does already. Also, we need a solution now, not one that goes through the proposal process first. Also, please note that it is *very* difficult to implement new attributes in TAL, so someone would have to sign up implementing this; it would certainly not be me. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: MessageID's automatic translation in TAL
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: MessageID's automatic translation in TAL
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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
