Hi there,

Last week I switched Silva to use Five's backport of Zope 3 i18n behavior instead of PlacelessTranslationService:


http://faassen.n--tree.net/blog/view/weblog/2005/12/02/0

Today I ran into some issues. The issue is that Zope 2's page template engine doesn't have the same behavior as Zope 3's concerning translation of message ids. The other is that the behavior I want ported to Zope 2 is currently deprecated in Zope 3. :)

My proposal:

* undeprecate this behavior in Zope 3.2

* port the behavior to Zope 2.9 (I can do this tomorrow if agreed upon)

* perhaps also do a bugfix in Zope 2.8 to include the undeprecated behavior too. (I'm working with Zope 2.8 so I'm motivated to help out with this too)

What's the behavior I'd like undeprecated, and why? This is an old debate, which I'll quickly summarize, and also list some new arguments.

Current (deprecated) behavior of Zope 3
----------------------------------------

If a message id is defined in python, such as _("Foo"), it gets translated by the page template engine automatically when it enters through a tal:content, tal:replace, or tal:attributes. No i18n:translate is needed.

Note that in Zope 2, the behavior is not that way, though it's simulated by PlacelessTranslationService by defining a __unicode__() that triggers translation.

What does the deprecation suggest?
-----------------------------------

The deprecation message says that this auto-translation won't be supported anymore in future Zope 3 versions. What will happen in this case is unclear. Will the user see an exception, or just no translation whatsoever and the original string?

Why this behavior is the Right Thing (tm)
-----------------------------------------

* Since I already explicitly mark that something is to be translated in Python code, I shouldn't have to be Twice As Explicit and also mark it in the ZPT again.

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

* If a library such as the Zope 3 core or formlib defines message ids in Python, then the deprecation puts the burden is on my application to actually put in i18n:translate="", even if my application actually doesn't have any i18n requirements at all. Once the deprecation happens, my application would either break with exception messages, or, alternatively, I'll see the original, non-translated messages. (the latter makes the deprecation warning a bit confusing; once the feature is removed, my code will continue to "work" but I get no more complaints from the system!)

* The latter is not so bad, you'd think. However, if interpolation is in play, i.e. Zope 3 has code like Message("Foo ${bar} Baz", {'bar': 'Hoi'}), I'd see the *uninterpolated* messages show up, unless I explicitly add the i18n:translate.

My proposal is to recommend the use of i18n:translate for ZPT translation only, and let the ZPT engine automatically translate messages when they come from Python.

Risks
-----

The one thing that requiring i18n:translate="" everywhere would be good for would be explicit control in applications without i18n requirements.

I.e. if I'm looking at an app that only offers an English UI and my browser is set to Dutch, I might see *some* translated strings in there, if these messages come from the framework. Two possible answers to this:

a) Hey, I'm lucky, at least *some* things are translated into my favorite language, the one my browser prefers to see!

b) Inconsistent user experience; better it all be in English... Promising users the hope of a translated UI when the app doesn't care about i18n. Perhaps there needs to be an explicit way to turn off i18n altogether in page templates that don't care.

I think that putting the burden on this particular edge case, which should be easy to fix with a global setting per template, is better than putting the extra burden on everyone who wants to do i18n.

Regards,

Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to