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

[Philipp von Weitershausen]

Martijn Faassen wrote:

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

Incidentally, I have been thinking about introducing a new i18n TAL command for 
this, too. We have the following cases:

a) A static text in ZPT needs to be turned into a message id and translated. 
Now you do:

  <p i18n:translate="msg-id">Translate this!</p>

I propose to make the two steps more explicit, exactly like in Python:

  <p i18n:messageid="msg-id" i18n:translate="">Translate this!</p>

The i18n:message-id command turns the contained text into a message id with the 
id provided in the argument and the domain acquired from an i18n:domain 
attribute somewhere up the hierarchy. The i18n:translate command invokes 
translation.

b) A dynamic value needs to be translated. Now you do:

  <p i18n:translate="" tal:content="context/msg">msg</p>

This would not change.

c) FORBIDDEN case: An explicit message id is stated for a dynamically inserted 
value. Now you can do:

  <p i18n:translate="msgid" tal:content="context/msg">msg</p>

The new i18n:translate command will not take arguments. Message ids will have 
to be declared through i18n:messageid, however, tal:content and tal:replace 
will conflict with i18n:messageid at a parser level, thus making 
the "forbidden" case impossible.

Backward compatability can easily be provided.

Thoughts?

Philipp