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

[Jim Fulton]

Martijn Faassen wrote:
> 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.

I don't agree that it is more work than needed, since I don't
agree that making something a message id implies that you want
translation to occur if the value is inserted into ZPT.

I think that such an implicit rule makes this harder because it makes the
behavior ambiguous from a ZPT programmers point of view.

> * possible ambiguity. What if both the ZPT and the Python programmer 
> state domains and message ids? Which one has priority?

The Python programmer.

 > Why even allow
> such a source of confusion?

Because it is more explicit.

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

This is a reasonable argument, however, I don't think it outweighs
arguments on the other side.

IMO, the only alternative is to say that message ids are not strings.
If you want to propose that, you can. That's a big change.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org