[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal
Hi David, This is not at all related to the preview function (I think). It's just about round-tripping XML and not needing extensibility. (spoiler alert, I've seen notes from this thread, after this one, where my eyes have been opened to the fact that the requirement may realistically be morphing into a general metadata handling issue, not just XML attributes. But for the excellent issues you raise, here goes . . .) Attribute values (and names) need to be preserved in XLIFF whether we translate them or not. And beyond that, I think in some cases knowing the type could be useful in the translation workflow. I understand your point that having multiple translatable string sets in a single trans-unit is a new way of thinking. And I understand how this could be viewed negatively. But to look at the flipside, I can also see negative aspects to storing attributes in two different ways depending on whether or not the attribute needs to be translated. And I perceive a need to preserve attributes w/o extensibility. Going back to my example: <para id="g_3423_spectrum" alt="It's orders of magnitude faster" rev="c">This is orders of magnitude faster than swept analysis techniques.</para> In order to preserve the id, alt, and rev, and translate the alt, I suppose, off the top of my head we would do something like: (a) <trans-unit restype="x-myxml-para" id="para-73" mynspace:id="g_3423" mynspace:alt="It's orders of magnitude faster" mynspace:alt_idref="a1" mynspace:rev="c"> <source> This is orders of magnitude faster than swept analysis techniques.</source> <target /> </trans-unit> <trans-unit restype="x-myxml_attribute-alt" id="a1"> <source> It's orders of magnitude faster </source> <target /> </trans-unit> (perhaps I overlooked a better way than the example above) But to tell you the truth, the idea of needing a second pair of <source>/<target> is an inelegance I completely spaced on (oh, boy). So let's see if my proposal still works with that reality: (b) <trans-unit restype="x-myxml-para" id="para-73"> <meta-hold name="id" translate="no">g_3423_spectrum</meta-hold> <meta-hold name="alt" translate="yes"> <source>It's orders of magnitude faster</source> <target /> </meta-hold> <meta-hold name="rev">c</meta-hold> <source>This is orders of magnitude faster than swept analysis techniques.</source> </trans-unit> To my eyes, (b) looks a lot better than (a). But I'm happy to hear why (a) is better than (b), or a better alternative is available. Thanks, Bryan From: David Walters [mailto:waltersd@us.ibm.com] What is the purpose of making these attribute values available within XLIFF? Is it related to the "preview" function that has been proposed? Providing this as a way to handle translatable attribute values does not seem to fit into the XLIFF structure very well. You would have to provide this text within <source> and <target> elements to make this translatable. Now you could have multiple (2+) translatable strings defined within one <trans-unit>. I thought we were tending towards making each translatable attribute value a separate <trans-unit> element.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]