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

[Martijn Faassen]

Jim Fulton wrote:
> Martijn Faassen wrote:
> 
>> Jim Fulton wrote:
[snip]
>>> 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.

It in part probably depends on what i18n-ed applications in Zope 3 will 
look like. Will most message ids be declared in Python, or in the page 
templates? If most happens in Python anyway, a very easy way to make a 
particular section i18ned is to have a tag/attribute saying 'everything 
inside is auto-i18ned'. You could even have another tag that says 
'except this section'. The rules for static text in the ZPT can still 
stand as they are.

I think that's still explicit, and less work.

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

The solution suggested by you, as I understand it, has the problem of 
ambiguity anyway.

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

There are ways to avoid this source of confusion. It is a grave source 
of confusion in my mind, as the ZPT programmer will sit there and 
scratch his head, wondering why the $%# ZPT engine doesn't translate 
using their message id, but instead comes up with something entirely 
different.

You could say instead:

* the ZPT programmer is always right if *they* declare a message id. 
This overrides anything lower down. If they don't declare a message id, 
but declare the particular content i18ned, then the Python id is used, 
if available. This makes the situation far more understandable for a ZPT 
programmer.

This is independent from the idea to have a command so that you can 
declare whole sections i18ned very easily. More explicit message id 
declarations always override this.

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

No, I think there are different alternatives here to make this both more 
explicit and more convenient. I think essential to avoid confusion is to 
make the ZPT always override whatever is in Python concerning message 
ids. It's relative easy to find and remove a ZPT i18n:translate, while 
it's much harder to dig into the Python code and find the spot where a 
i18n string got created. The person caring about the i18ned end result 
will most likely be messing about with ZPTs anyway.

Regards,

Martijn