Re: Translatable text in tag attributes

Marty Vance wrote:

> I prefer method A, because the translatable text gets processed inline, 
> where it where end up anyway. 
Well, B does the same thing, but without signaling.

  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.
> 
Is this a real problem or a question of readability/esthetics?
> 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.
Yes
> 
> 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.
You mean B here, presumably?
> 
> I don't think C should be eliminated (it is necessary at times), but I 
> don't think it should be preferred.
Why?
> 
> 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.
If indeed we surrender to some form of signaling, then it would seem to 
me easiest to leave the xarML in there. Among other things it would be 
easier to port BL1 templates to BL2.
> 
> 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.
I'm going to go out on a limb here and speculate that the fragile 
behavior of the <xar:attribute> tag (if memory serves) could be an issue 
with PHP-XSL. The tag itself is quite simple.

Actually I'm hoping MrB will weigh in on this since the xd2xt scenario 
privileged proposal B.