Re: [Zope3-dev] RFC: undeprecate auto-message id translation
Martijn Faassen wrote: Dmitry Vasiliev wrote: [snip] * currently you can translate any string (not only a message id) like this: p tal:content=string: STRING TO TRANSLATE i18n:translate=/p In this case the string will be automatically converted to message id and then translated. I think we definitely shouldn't translate any string, only message ids. This is an interesting usecase. If I understand you correctly, the question, put a bit broader, is the following: p tal:content=some/call i18n:translate=/p Should this translate whatever string (not message id) is returned from some/call or should it leave it alone? You seem to be arguing it shouldn't. I can also see a usecase where this would be handy -- you can just add the string to your translation dictionary without having to mark anything in your codebase. This is a *disadvantage* if you're already using extraction tools, though. I think only message ids should be translated since you always need to have a message id at some stage anyway to be extracted by i18nextract. Translating a string (not message id) returned by 'tal:content' is just a chortcut for lazy programmers. :-) -- 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] RFC: undeprecate auto-message id translation
Martijn Faassen wrote:
* if a i18n:translate has to be explictily added, extraction tools will
find the i18n:translate= in the ZPT and think there's a message in the
ZPT to translate. But there's not, it's coming from Python code. This
might result in the extraction tool mistakenly extracting dummy text:
p tal:content=context/something i18n:translate=This dummy text is
replaced/p
Unless the tool is so smart it notices this case. Anyway, the tools
already extracted the *real* message anyway.
Currently i18nextract just extracts '${DYNAMIC_CONTENT}' marker for all dynamic
content.
Risks
-
+1 for translate message ids without explicit 'i18n:translate' attribute but
some open questions still remain:
* currently you can translate any string (not only a message id) like this:
p tal:content=string: STRING TO TRANSLATE i18n:translate=/p
In this case the string will be automatically converted to message id and then
translated. I think we definitely shouldn't translate any string, only message ids.
--
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] RFC: undeprecate auto-message id translation
Dmitry Vasiliev wrote: [snip] * currently you can translate any string (not only a message id) like this: p tal:content=string: STRING TO TRANSLATE i18n:translate=/p In this case the string will be automatically converted to message id and then translated. I think we definitely shouldn't translate any string, only message ids. This is an interesting usecase. If I understand you correctly, the question, put a bit broader, is the following: p tal:content=some/call i18n:translate=/p Should this translate whatever string (not message id) is returned from some/call or should it leave it alone? You seem to be arguing it shouldn't. I can also see a usecase where this would be handy -- you can just add the string to your translation dictionary without having to mark anything in your codebase. This is a *disadvantage* if you're already using extraction tools, though. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: undeprecate auto-message id translation
Hi there, An amendment on the behavior in Zope 2.8 + Five 1.2; it's different than I thought and actually this is quite a relief to me (though there are still problems). Zope 2.8 *is* actually interpolating and translating message ids correctly *without* i18n:translate already. I think that this is the same as Zope 3's (deprecated) behavior. The problem is when 'structure' is used in TALES. If this isn't used, translations happen normally. If it is used, translations suddenly break, as do_insertStructure_tal is used instead of do_insertText_tal. I can see that this makes sense if you structure in large pieces of HTML -- they won't have translations. It does however break a usecase where your message ids contain HTML. This isn't really clean, but very handy for translators sometimes, especially if they want to use HTML entities and the like. You can then use i18n:translate= explicitly on the structure, which will cause the *string* to be translated, without interpolation happening. This put me on the wrong track initially, not realizing the impact of 'structure' on the functioning of the TAL interpreter. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
