[Zope3-dev] Re: Use case not covered for translation of message ids

Martijn Faassen faassen at infrae.com
Tue Sep 28 13:11:23 EDT 2004


Jim Fulton wrote:
> Godefroid Chapelle wrote:
> 
>> Stephan Richter wrote:
>>
>> <snip>
>>
>>
>>> So in other applications making something a message id translates 
>>> immediately. Maybe this is the reason it feels so natural for 
>>> Godefroid and Martijn to think about automatic translation. I like 
>>> Zope 3's idiom though, which separates the declaration of something 
>>> being translatable and actually translating something.
>>
>> I am all for this separation, I am just pleading for no need of 
>> explicit use of i18n:translate when the engine actually decides to 
>> translate !
> 
> You keep pleading, but you don't give any reason why you need this.
> I, OTOH, have given a specific reason why this would be harmful.

Some possible reasons:

* more work than needed. The Python programmer already indicates by 
using a i18n string that they want this to be translated upon display. 
The page template designer will now have to say this *again*. You could 
make argument that your use case of explicitly managing this stuff would 
be better served by an explicit way to turn translation *off* in ZPT, 
not having to turn it on explicitly all over the place when the source 
strings are i18n-ed anyway.

* possible ambiguity. What if both the ZPT and the Python programmer 
state domains and message ids? Which one has priority? Why even allow 
such a source of confusion? I can see people being very confused in 
debugging sessions as the behavior will differ depending on whether i18n 
strings come in or not, and i18n strings behave very much like normal 
strings and vice versa.

Regards,

Martijn


More information about the Zope3-dev mailing list