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

Martijn Faassen faassen at infrae.com
Tue Sep 28 13:05:01 EDT 2004


Jim Fulton wrote:
> Martijn Faassen wrote
>> Jim Fulton wrote:
>>> Martijn Faassen wrote:
>>>> Doesn't that require setting the message id in it? But the message 
>>>> id is already available, in the i18n string. What does the 
>>>> i18n:translate attribute look like in this case?
>>>
>>> If the source string and the message id are the same, then
>>> the value of the i18n:translate attribute is empty.  In that case,
>>> the attribute functions to indicate that translation should be done.
>>
>> What if the i18n:translate attribute is not empty and we have a i18n 
>> string coming from the application? Is this an error?
> 
> Good question. I'm inclined to say think that
> in the case of a node that has *both* a translate attribute and a
> tal:contents or tal:replace attribute, it should be an error to
> specify the message id in the translate attribute, as it makes no
> sense to use a static message id for dynamic data.

An alternative is to introduce a new i18n attribute (or kind of i18n 
attribute) that says:

   * translate this

   * if there's a static string in the zpt, use that as the message id

   * if we get dynamic data, and it's a message id string, use that as 
the message id

   * if we get dynamic data and we get a *plain* string, fall back and 
use that string directly. Or alternatively, report an error. There are 
arguments for both.

So, this is always to have implicit message ids; there is no explicit 
message_id in the ZPT anywhere but is somehow derived.

The other directive could be for explicit message ids and it would be an 
error if it is left off. The explicit message id would always be used no 
matter what.

I'm not sure whether this is the right partition but it could help avoid 
ambiguous situations like this.

Regards,

Martijn


More information about the Zope3-dev mailing list