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

[Godefroid Chapelle]

Jim Fulton wrote:

<snip>

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

Again, I disagree, do we ask the ZPT programmer to check the type of 
other values coming from Python ?

<ironic>
We could for instance force the ZPT programmer to typecast integers, 
floats and other. So that he acknowledge he does not want to translate 
numbers.
</ironic>

The main problem is that you forget that a string presented to the user 
should almost always be translated : strings that should not be 
translated are the exception in multilingual applications.

As we want to use tools to produce the .po file, we need to mark those 
strings. Reason for the i18n:translate for ZPT only strings. Reason why 
we want a special call in the Python Code. But when this is done and 
when the strings that should be translated arrives to the translation 
engine with enough information, I really do not understand why it should 
be marked a second time.

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

I am not sure I understand why the fact that they are strings is a 
problem : do you mean that python programmer could forget that they are 
special strings and use them in string arithmetics for instance ?

AFIK, this would typecast to normal strings. In this case, or the 
programmer wanted it to be translated and he has a solvable problem.

We can still argue that this is a bad situation as the programmer should 
not be allowed to make calculation on message ids. He should use message 
id mappings.

Or, he does not care, and this goes in the right direction.

> If you want to propose that, you can. That's a big change.

If you mean a big change in the code, I am pretty sure otoh, that it is 
not so big.

> 
> Jim
> 


-- 
Godefroid Chapelle (aka __gotcha)                http://bubblenet.be