OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[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]
Sent: Tuesday, March 13, 2012 7:42 AM
To: Schnabel, Bryan S
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal

 

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.

I agree with Yves when he asked about why limit it to XML.  This concept could apply to many non-XML file format, like HTML, resource files, message files, etc.

David

Corporate Globalization Tool Development
EMail:  waltersd@us.ibm.com          
Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721

CHKPII:                    http://w3-03.ibm.com/globalization/page/2011
TM file formats:     http://w3-03.ibm.com/globalization/page/2083
TM markups:         http://w3-03.ibm.com/globalization/page/2071


Inactive hide details for "Schnabel, Bryan S" ---03/12/2012 06:23:37 PM---I move that we promote the proposed feature, "2.21. ("Schnabel, Bryan S" ---03/12/2012 06:23:37 PM---I move that we promote the proposed feature, "2.21. (B25) Preserve XML attribute or metadata without

From: "Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>
To: "xliff@lists.oasis-open.org" <xliff@lists.oasis-open.org>
Date: 03/12/2012 06:23 PM
Subject: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal
Sent by: <xliff@lists.oasis-open.org>





I move that we promote the proposed feature, "2.21. (B25) Preserve XML attribute or metadata without extensibility" (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-PreserveXMLattributeormetadatawithoutextensibility.A.28B25.29PreserveXMLattributeormetadatawithoutextensibility ) to section 1, as an approved feature for XLIFF 2.0 (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#ApprovedFeaturesforXLIFF2.0 ).
 
If any voting member of the TC agrees, please second.
 
Here's some background.
 
Today we nearly always need to use extensibility to preserve source XML attributes when converting an XML file to XLIFF. We should create a way to preserve the attributes using supported XLIFF markup - removing the need to extend.
 
Consider this XML element:
 
<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>
 
If we were to allow an element like <meta-hold> (would really need to come up with a better name though) to contain the name of the attribute, its value, and optionally its type and translate y/n, we would eliminate the need for extensibility for this use case.
 
Example:
 
<trans-unit id="para-73">
    <meta-hold name="id" translate="no">g_3423_spectrum</meta-hold>
    <meta-hold name="alt" translate="yes">It's orders of magnitude faster</meta-hold>
    <meta-hold name="rev">c</meta-hold>
    <source>This is orders of magnitude faster than swept analysis techniques.</source>
</trans-unit>
 
I include the following, not to propose to specifically update the schema in this manner, but rather to provide more background on the proposed data types and constraints.
 
Modification to schema:
 
    <xsd:element name="meta-hold">
        <xsd:complexType mixed="true">
            <xsd:group maxOccurs="unbounded" minOccurs="0" ref="xlf:ElemGroup_TextContent"/>
            <xsd:attribute name="name" type="xsd:string" use="required"/>
            <xsd:attribute name="type" use="optional"/>
            <xsd:attribute name="translate" use="optional"/>
        </xsd:complexType>
    </xsd:element>
 
Allow the usual inline elements, but do not allow nested <meta-hold> elements
 
    <xsd:group name="ElemGroup_TextContent">
        <xsd:choice>
            <xsd:element ref="xlf:g"/>
            <xsd:element ref="xlf:bpt"/>
            <xsd:element ref="xlf:ept"/>
            <xsd:element ref="xlf:ph"/>
            <xsd:element ref="xlf:it"/>
            <xsd:element ref="xlf:mrk"/>
            <xsd:element ref="xlf:x"/>
            <xsd:element ref="xlf:bx"/>
            <xsd:element ref="xlf:ex"/>
        </xsd:choice>
    </xsd:group>
 
Please feel free to join this discussion if you have questions, concerns, objects, or if you support this idea.
 
Thanks,
Bryan Schnabel
Content Management Architect
Phone: 503.627.5282

www.tektronix.com
TwitterRSS Facebook Tektronix Store
Tektronix Logo
 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]