[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Suggested additional changes for XLIFF 1.2
Thank you for your explanations. Please find my comments to yours for item 4 below:
I'm happy to provide some reasons. I'll try to keep this note "light" and not too loaded up with code examples (no promises, though).
As for item 4, I think the whole idea of dealing with translatable attributes is a tricky thing. As an XML purist who grew up as an SGML purist, my instinct is to declare that translatable strings should be designed to be element content, not attribute content. But in the real world, we cannot always do that (html's <img alt="some other caption", for example, is a good use of an attribute that efficiently contains a translatable string).
There are other examples of stings in attributes that are very poorly designed, but exist in the real world, like this:
<announce>The cost for the
<item label="lift ticket" season="spring" /> is
<price unit="dollar" type="Canadian" value="175" />
In the technical publications world we see more badly designed XML than one would expect. The <sub element is very nice in this kind of a case because it lets us mark up the XLIFF in such a way that the content can be (kind of) normalized in so that all of the pertinent text is in the same <trans-unit. It is therefore not too difficult to map this efficiently to enable a nice roundtrip via XSLT. I would also argue that since it's in one <trans-unit, it is easier on the translator because it is a bit more cohesive than the approach I would envision if I had to use the xid method. Making the translator jump from one <trans-unit to another, keeping the hierarchy and flow straight, I think, is less friendly.
But to be fair, I have not actually coded up the xid approach, so maybe I'm not seeing a better xid way. I'm open to consider it if a way exists.
[Magnus] This is an interesting example. From a localization perspective extracting the translatable attribute content into separate standalone units would probably make it easier to work with, and definitely would improve recycling, as the individual components could be re-used independently.
“The cost for the <ph/> is <ph/>.” (attributes and element content omitted for clarity) looks easy to translate and is likely a good re-use candidate. And proper use of context for the standalone attribute values should give the translator enough information.
On the other hand, translating “The cost for the <ph><sub>lift ticket</sub><sub>spring</sub></ph> is <ph><sub>dollar</sub><sub>Canadian</sub><sub>175</sub></ph>.” (attributes and element content omitted for clarity) actually looks a lot more complex, at least to me.
In the end the “translatability” is to a large extent a matter of taste here and it is probably possible to find specific examples that “prove” that either representation is the better. The re-usability of existing translations however is definitely greater when using xid.
Regarding the ability to do round trips using XSLT transformation I would guess (though I have not tried) that you could also achieve this if translatable attribute content is stored in a different <trans-unit>, as the xid can be used to build XPATH expressions to locate the content. But of course it may be a bit more complex.
As for item 5, my reasons are nearly the reverse of the reasons for item 4. The identification of a resource's type or context, or name seems to me to be metadata, and not data. I am most comfortable dealing with that kind of information as an attribute value. I agree with you that the restype values in the current specification are highly file format specific. That's kind of bugged me for a while, but I haven't raised it as an issue. I kind of think that it should be all-or-nothing. And since we can never know all the resource types for all the given resources in the world, my preference would be to just make the attribute type "string", rather than an enumerated list. But for me, for now, the "x-" extension works out just fine.
So much for my "light" explanations. Many of your bullets under items 4 and 5 make sense to me. Even though I'm mostly against these changes, I think you make good points, and I'd be happy to participate in a larger discussion.
Thanks for bringing these thoughts to light,