Re: Translatable text in tag attributes

[email protected] wrote:

> The BL2 compiler in Jamaica treats all template text nodes as 
> translatable. This means that there is no need to signal translateble 
> text through <xar:mlstring> tags. Well and good.
> 
> The other place we often encounter translatable text is in certain tag 
> attributes. Consider the following example:
> 
>     A. <input type="submit" value="#xarML('Log In')#" />
> 
> What can we do to simplify this construct, similar to what has been done 
> in text nodes?
> 
> Here are 2 other ways of expressing the same example:
> 
>     B. <input type="submit" value="Log In" />
> 
>     C. <xar:var name="label">Log In</xar:var>
>        <input type="submit" value="#$label#" />
> 
> Ideally I would like to replace A with B or C. In fact, I would pretty 
> much like to remove all xarML constructs from templates and have the 
> translation issue be handled in the background without any signaling.
> 
> Variant C is a cheap (implementation-wise) solution: it reduces our 
> issue to an application of the text node translation already 
> implemented, without any further fuss. Its drawback is that it is a bit 
> less readable and a slightly more complicated construct.
> 
> Variant B looks great, until you realize that setting up a simple rule 
> like "all text in attributes is translatable" would mean the name of the 
> button in that example would also be translated. Probably not what we want.
> 
> Opinions?

I prefer method A, because the translatable text gets processed inline, 
where it where end up anyway.  C is used in Aruba (even when the string 
is translated in php and passed to the template), but I see these string 
variables as extraneous.

Which should lead me to prefer B as well, except for the issue that 
input type and many other attribute values are "hard coded" into the 
specifications as English.

I think there are only three ways to do this: C, have BL2 keep a list of 
"unstranslateable" attribute nodes (unmanageable, given the number of 
doctypes) or provide some type of signal.

I don't think C should be eliminated (it is necessary at times), but I 
don't think it should be preferred.

To me, this comes down to the question of whether to keep #xarML('foo')# 
as the signal, or come up with a new one.  Perhaps something simpler, 
such as

<input type="submit" value="#ml:Log In#" />

although I can see where this could be seen as change for change's sake. 
  It is easy to parse, and looks cleaner than what we use now.

An alternative would be to not use the translatable attribute directly, 
but use a proxy attrubute in the xar namepsace which gets transformed:

<input type="submit" xar:ml="value:Log In" />

Looks even cleaner than the method above, and just as easy to parse.

In both, 'ml' is given for historical reasons, and could just as easily 
be 'translate' or some other token.  The delimiter ':' is also just an 
example.

The more I think about this, I increasingly prefer using a xar 
attribute.  I've thought for a long time that attributes in the xar 
namespace could be a powerful tool.