[Zope3-dev] RFC: undeprecate auto-message id translation

[Martijn Faassen]

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