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] General metadata preservation, not just XML attributes (was RE: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal)


Hi Bryan,

 

There should be only one <source>/target> pair per segment. The two translatable portions from your example should be in their own <unit> because if you use two <segment> elements within one <unit>, they could be merged or split by the translator and that’s something you will not like.

 

We already have a “translate” attribute at segment level. It is not necessary to put that information in a metadata container.

 

If you want to withdraw your original proposal and make  a new one based in the examples I provided, then I’ll second the new initiative.

 

Regards,

Rodolfo

--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms      
http://www.maxprograms.com

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Schnabel, Bryan S
Sent: Tuesday, March 13, 2012 4:15 PM
To: Rodolfo M. Raya; xliff@lists.oasis-open.org
Subject: [xliff] General metadata preservation, not just XML attributes (was RE: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal)

 

Hi Rodolfo,

 

I love this proposal. This covers 90% of my intent - plus 100% of Yves' concern. I wonder if we could add the remaining 10% of my intent by adding a translate y/n dimension? But in doing so, it would be important to keep in mind David W.'s excellent point that adding a second <s>/<t> pair would be a game-changer (http://lists.oasis-open.org/archives/xliff/201203/msg00028.html ).

 

I am very much leaning toward doing the following.

 

1. withdraw my earlier proposal (and with that David's second goes away)

2. ask that you co-own this feature

3. add your generi-sized and improved functionality to the wiki summary

4. decide if translatable strings are in scope

5. re-propose the feature after dispensing with 1 thru 4

 

What do people think of this approach?

 

- Bryan

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya
Sent: Tuesday, March 13, 2012 7:54 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal

 

Hi,

 

There shouldn’t be something specific for XML. If there is a  needs preserving metadata, the solution should be generic and contemplate formats like HTML5 or PO as well.

 

We could recover the concept of “group” from XLIFF 1.2 and implement it as an optional module that would allow storing information at different levels, like <file>, <unit>, <segment> and <match>.

 

With two elements living in a separate namespace we could store lots of optional information like in this example:

 

<unit>

  <segment>

   <source>Translate me!</source>

  </segment>
  <mtd:metaHolder type=”attributes”>

    <mtd:meta key=”id”>gr_3456</meta>

    <mtd:meta key=”bold”>yes</meta>

  </mtd:metaHolder>

  <mtd:metaHolder type=”count”>

    <mtd:meta key=”words”>2</meta>

    <mtd:meta key=”chars”>13</meta>

  </mtd:metaHolder>

</unit>

 

One attribute in the main holder element would indicate the type of metadata and another attribute would define the key of a key-value pair.

 

In the module specification we could define a set of standard information types that covers what we have in XLIFF 1.2 and add new ones as needed to cover things that are currently handled by custom extensions in XLIFF 1.2.

 

This schema used in <match > or <matches> would be quite useful for storing metadata that today we can’t store in <alt-trans>.

 

Applications that don’t understand certain type of metadata would be able to safely ignore the proposed elements, as with any element coming from an optional module.

 

Regards,

Rodolfo

--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms       http://www.maxprograms.com

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Tuesday, March 13, 2012 11:17 AM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal

 

Hi Bryan,

 

Could you define what “metadata” means in your example? Is that implying that some of the metadata could be XML element content too?

 

I’m also wondering why XML source documents should have a specific way of being stored? Couldn’t HTML5 metadata be also important for example?

 

Cheers,

-yves

 

 

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Schnabel, Bryan S
Sent: Monday, March 12, 2012 5:23 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal

 

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]