[Zope-Coders] i18n:attributes in 2.7

[Godefroid Chapelle]

Hi all,

I am currently working on Silva i18n. This led me to take a look at the 
code for i18n:attributes.

I'll try to explain the current situation :

I) in Zope 2.6.1,

I.1) space separated attributes as in

<span value="value" title="title" accesskey="acc"
i18n:attributes="value title accesskey" />

are accepted and the three attributes are translated.
This should not work according to the ZPT i18n doc/spec at
http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZPTInternationalizationSupport

I.2) semicolon separated attributes (Zope 3 current syntax) as in

<span value="value" title="title" accesskey="acc" 
i18n:attributes="value; title; accesskey" />

are accepted.
accesskey attribute is translated,
value and title are kept as they are (not translated)
and value; and title; attributes are added (HUM ;-)

IOW it doesn't work as it should according to the ZPT i18n doc/spec.

I.3) attributes with associated message ids as in

<span value="value" title="title" accesskey="acc" i18n:attributes="value 
msgvalue; title msgtitle; accesskey msgaccesskey" />

do not work.


II) in Zope 2.7.b1, and Zope3

II.1) space separated attributes as in

<span value="value" title="title" accesskey="acc" i18n:attributes="value 
title accesskey" />

generate a compile time error
IOW break the backwards compatibility.

II.2) semicolon separated attributes (Zope 3 current syntax) as in

<span value="value" title="title" accesskey="acc" 
i18n:attributes="value; title; accesskey" />

are accepted and translated correctly.

II.3) attributes with associated message ids as in

<span value="value" title="title" accesskey="acc" i18n:attributes="value 
msgvalue; title msgtitle; accesskey msgaccesskey" />

are accepted and translated correctly according to message ids.

To summarize, as message ids translation for attributes was added, 2.7 
and 3 are working according to the doc/spec,
but 2.7 breaks backward compatibility to 2.6.1.

This leads to the following question : do we (1) accept this rupture in 
i18n:attributes management or do we (2) want 2.7 to cover space 
separated attributes ?

IOW, could people that need backward compatibility stand up ?

BTW, second choice would lead us to a bad situation where we cannot 
discriminate between

<span value="value" title="title"
i18n:attributes="value title" />

and

<span value="value" title="title"
i18n:attributes="title msgtitle" />

We could add a warning mechanism somewhere in the case of use of space 
separated attributes.

Further,

I checked in both 2.7 and 3 a safety net that avoids a developer to 
declare attributes being both dynamically generated (by being included 
in a tal:attributes) and statically translated (by being included with a 
message id in a i18n:attributes).

This lead to the following comments :

1) Fred L. Drake, Jr. wrote:

> While this sounds very reasonable on the face of it, I don't think
> it's the right thing.  (Whether what was implemented to begin with is
> the right thing is a separate question. ;)
> 
> When a message id is given by i18n:attributes, the result of the
> tal:attributes expression should be used as the default text passed to
> the translation service. (If there is no tal:attributes setting for
> the attribute, the undecorated attribute should be used as a source
> for the default text, if present.)
> 
>   -Fred
> 
IMHO, as we would not use the message id value, I think it is reasonable 
to warn the developer and force him to make a choice.

2) Barry Warsaw wrote:

> What if I wanted the button text to be "Submit ${name}"?  Ignoring
> translations, I'd just write
> 
> <input type="submit" value="ignore"
>         tal:attributes="value string:Submit ${name}">
> 
> Now, what if I want to translate the button text?
> 
> <input type="submit" value="ignore"
>         tal:attributes="value string:Submit ${name}"
>         i18n:attributes="value submit_name_button">
> 
> So if the translation for submit_name_button returns "${name} Fobnitz"
> and a mapping of $name to the path "name", I'd get the right thing in
> the target language.  But if there was no translation, then I'd want
> "Submit ${name}" with the interpolation happening dynamically.
> 
> -Barry

Jim Fulton answered :

> That's an interesting case, however, it won't work with i18n:attributes,
> Because there is no mapping passed to the translation facility when
> translating attribute values.
> 
> Jim

and Barry followed with :

> Just to follow up because talked about this in person: it would be good
> if someday it was possible to have substitutions in translatable
> attributes, and it would be good if the syntax for that was as close as
> possible as it is for translatable tags.  
> 
> If that means this restriction still stays in ZPT for Zope 2.7, then
> okay.
> 
> -Barry

IOW there seems to be an agreement that there is a need for 
interpolation in attributes translation.
That won't be part of Zope 2.7.

In any case, I think it is a good opportunity to think about the way we 
want this mechanism to be implemented.

I'd propose it should be done in Zope3 first and later back-ported to 
Zope 2.x

-- 
Godefroid Chapelle

BubbleNet sprl
rue Victor Horta, 18 / 202
1348 Louvain-la-Neuve
Belgium

Tel + 32 (10) 459901

TVA 467 093 008
RC Niv 49849