[ZPT] I18n mechanism (was Re: Use case not covered for translation of message ids)

[Godefroid Chapelle]

Hi all,

This thread has been begun in zope3-dev where we argue about how and if 
  the strings declared as translatable in Python code should be declared 
again as translatable in ZPT code.

I think we all agree that the following distinction needs to be made :

- on the one hand, we want to explicitely mark which strings could be 
part of a translation mechanism. This has the advantage of being 
explicit and harvestable by tools.

- on the other hand, we want the translation mechanism/decision to be 
centralized and to happen in the presentation layer.



I'd like to sum up my current thinking.

The marking of strings needs to at least include the domain.
We currently do this in Python Code by using Messages instances.

view.msgid=Message('msgid', domain="zope3python", default="Some Text")


We do this in ZPT by specifying an i18n:domain : globally or locally.

I think it would be wrong to rely on each template to decide if the 
translation mechanism is on or off, which language negotiation mechanism 
is to be used and so on. I am trying to say that the i18n;translate is 
just a mark that something could be translated. Without this mark, there 
would be no way to decide which message to translate.

In the current state, we get tricked by the "translate" keyword : this 
makes us think that it is a imperative instruction to translate where it 
is actually a declaration that this string should/could be translated 
when translation occurs. IOW, and for the good, the translation setup is 
made at the application level by choosing to setup translation, by 
choosing a specific translation engine and so on.

I can also express it by saying that in case of translation engine OFF, 
the i18n:translate imperative instruction is wrong as it states that 
translation should happen ;-)

It might have been better to choose something like i18n:translatable.

I propose that we keep the current mechanism where the declaration of 
translatable strings happen in Python code. And the decision of 
translation is made at the ZPT engine level.



The construction hereunder

in Python code :

view.msgid=Message('msgid', domain="zope3python", default="Some Text")

in ZPT code :

<p i18n:domain="zope3zpt" i18n:translate="" 
tal:content="view/msgid">Some text</p>

will currently translate the msgid in the "zope3python" domain. It is, 
in my opinion, wrong : there is an explicit declaration of domain that 
is overridden by an implicit (from the POV of the ZPT programmer) 
declaration in the Python code.

This should use the zope3zpt domain as explicitely stated by the ZPT 
programmer. And even in the following case, the zope3zpt domain should 
be used.

<p i18n:domain="zope3zpt"><span i18n:translate="" 
tal:content="view/msgid">Some text</span></p>

In both cases, the ZPT programmer has made a conscious decision and he 
should rule.



In the case hereunder,

in Python code :

view.msgid=Message('msgid', domain="zope3python", default="Some Text")


in ZPT code :

<p tal:content="view/msgid">Some text</p>


the current mechanism does translate the message id from the zope3python 
domain. Even without i18n marking. This should be kept. The ZPT 
programmer states nothing about the translation of the message id but 
the Python programmer did !

I recall you that the decision to actually translate is made at 
application setup by switching on or off the translation engine. The set 
of available languages in case of translation being also decided upon at 
the engine level (and not at the template level !)


In the following code,

<p i18n:domain="zope3zpt"><span tal:content="view/msgid">Some 
text</span></p>

the msgid should still be translated in the zope3python domain as again 
the ZPT programmer did not express anything about a domain for the msgid.




In case we absolutely want to express "avoid translation" on message ids 
we could introduce i18n:except (or i18n:notranslate or ...) as proposed 
by Martijn.

<span i18n:except="" tal:content="view/msgid">Some text</span>

where the message id would be rendered as its default string.

This is YAGNI in my opinion.


Godefroid Chapelle