OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  XLIFF and ITS mapping- Elements within text

    Posted 12-18-2015 17:10
    Hi all! Below is the suggested text to be a part of 2.1 spec for mapping elements within text data category of ITS 2.0 in XLIFF 2.1. Please have a review and provide your feedback/comments. Best, Soroush. X-NONE X-NONE Elements Within Text Represented by withinText attribute in ITS 2.0 which has one of the 3 following values;   1- ‘yes’ : Indicates that the inline element and its content are both part of the parent element’s flow. In this case, the element should be replaced by the following native XLIFF 2.1 inline elements: <pc>, <sc>/<ec> and <ph> , while its content remains in the original data;   Using <pc> : <body>    <p>This paragraph contains <span its-within-text=”yes”>a spanned       part</span>.</p> </body>   Representation in XLIFF 2.1: <unit id="u1">    <originalData>       <data id="d1">&lt;span&gt;</data>       <data id="d2">&lt;/span&gt;</data>    </originalData>    <segment>       <source>This paragraph contains <pc id="pc1" dataRefStart="d1"               dataRefEnd="d2"> a spanned part </pc>.       </source>    </segment> </unit>   Using <sc>/<ec> : <body>    <p>A paragraph where <u>the formatted text appears in more than one       segment. The second sentence here.</u></p> </body>   Representation in XLIFF 2.1: <unit id="u1">    <originalData>       <data id="d1">&lt;u&gt;</data>       <data id="d2">&lt;/u&gt;</data>    </originalData>    <segment>       <source>A paragraph where <sc id="sc1" dataRef=”d1” type="fmt"               subType="xlf:u"/>the formatted text takes more than one               segment.         </source>    </segment>    <segment>       <source> The second sentence here.<ec dataRef=”d2”               startRef="sc1"/>       </source>    </segment> </unit>     Using <ph> : <body>    <p>This sentence has a breakpoint<br/>inside.</p> </body>   Representation in XLIFF 2.1: <unit id="u1">    <originalData>       <data id="d1">&lt;br/&gt;</data>    </originalData>-->    <segment>       <source>This sentence has a breakpoint<ph id="ph1" dataRef="d1"                type=”fmt” subType=”xlf:lb”/>inside.       </source>    </segment> </unit>   2- ‘nested’ : This value is used when the element itself does not break the flow of its parent element, but its content represents an independent dataflow. To handle this case in XLIFF 2.1, the sub-flow (i.e. element’s content) should be stored in a different <unit> while the original element is replaced by a <ph> element and order of the flow defined by the subFlows attribute.     <body>    <p>This paragraph has a textarea embeded textarea; <textarea       name="Additional Information">Add content           here...</textarea>.</p> </body> Representation in XLIFF 2.1: <unit id="u1">    <segment>       <source>Additional Information</source>    </segment> </unit> <unit id="u2">    <segment>       <source>Add content here...</source>    </segment> </unit> <unit id="u3">    <segment>       <source>This paragraph has a textarea embeded textarea; <ph               id="ph1" subFlows="u1 u2"/></source>    </segment> </unit> All the sub-flows and the <unit> element which invokes them must be in the same <file> element.   3- ‘no’ : Indicates that the element and its content are not part of the parent element’s flow. In XLIFF 2.1 such element and its parent element should be stored in separate <unit> elements.   <body>    <ul>       <li>First sentence</li>       <li>Second sentence</li>    </ul> </body>   Representation in XLIFF 2.1: <unit id="u1">    <segment>     <source>First sentence</source>    </segment>   </unit>   <unit id="u2">    <segment>     <source>Second sentence</source>    </segment> </unit>


  • 2.  RE: [xliff] XLIFF and ITS mapping- Elements within text

    Posted 12-19-2015 11:38
    Hi Soroush, A few notes: -- 1) > 1- 'yes': Indicates that the inline element and its content are both > part of the parent element's flow. In this case, the element should be > replaced by the following native XLIFF 2.1 inline elements: <pc>, <sc>/<ec> > and <ph>, while its content remains in the original data; Maybe the text "...while its content remains in the original data;" could be improved. In XLIFF 2, "original data" tends to refer to the content of the <data> element, which is protected. Instead, maybe something like: 'yes': Indicates that the inline element and its content are both part of the parent element's flow. In this case, the element should be mapped to one of the XLIFF 2.1 inline elements: <pc>, <sc>/<ec> or <ph>, while its content is extracted.; -- 2) For the nested case you use an example with the name attribute of <textarea>. I don't think it is a good example because name is not a translatable attribute for <textarea>. See the section about translatable attributes and HTML5 here: http://www.w3.org/TR/2013/CR-html5-20130806/dom.html#the-translate-attribute The attribute title on a <textarea> would be a better example. Cheers, -yves


  • 3.  RE: [xliff] XLIFF and ITS mapping- Elements within text

    Posted 12-19-2015 12:38
    Hi Soroush, More notes: -- 1) Several of the examples have "curly quotes" instead of normal ASCII double quotes to enclose attribute values. A side effect of editing in an email probably, but they need to be correct in the spec. -- 2) <unit id="u1"> <originalData> <data id="d1">&lt;br/&gt;</data> </originalData>--> <segment> <source>This sentence has a breakpoint<ph id="ph1" dataRef="d1" type="fmt" subType="xlf:lb"/>inside. </source> </segment> </unit> The example above has a dangling "-->" after </originalData>. -- 3) <unit id="u1"> <originalData> <data id="d1">&lt;u&gt;</data> <data id="d2">&lt;/u&gt;</data> </originalData> <segment> <source>A paragraph where <sc id="sc1" dataRef="d1" type="fmt" subType="xlf:u"/>the formatted text takes more than one segment. </source> </segment> <segment> <source> The second sentence here.<ec dataRef="d2" startRef="sc1"/> </source> </segment> </unit> In the example above, the <ec/> element seems to be missing the attributes type="fmt" and subType="xlf:u". Now, the Okapi validator gives an error on this, but I don't see in the spec any constraint that says type and subType must have the same values in two corresponding <sc/> and <ec/>. That constraint exists only for canCopy, canDelete and canOverlap. I don't see anywhere either that the processor should magically complement the undefined attributes in <ec/> by looking at the corresponding <sc/>. At the same time, obviously, it would be illogical to have different values. Are we missing yet another "implicit" constraint? Cheers, -yves


  • 4.  Re: [xliff] XLIFF and ITS mapping- Elements within text

    Posted 04-25-2016 17:14
    Dear Yves, all, I just found this “unsolved thread” while reviewing the spec text for ITS module in XLIFF 2.1 and I think it’s worth finalizing this question. > -- 3) > > <unit id="u1"> > <originalData> > <data id="d1">&lt;u&gt;</data> > <data id="d2">&lt;/u&gt;</data> > </originalData> > <segment> > <source>A paragraph where <sc id="sc1" dataRef="d1" type="fmt" > subType="xlf:u"/>the formatted text takes more than one > segment. > </source> > </segment> > <segment> > <source> The second sentence here.<ec dataRef="d2" > startRef="sc1"/> > </source> > </segment> > </unit> > > In the example above, the <ec/> element seems to be missing the attributes type="fmt" and subType="xlf:u". > > Now, the Okapi validator gives an error on this, but I don't see in the spec any constraint that says type and subType must have the > same values in two corresponding <sc/> and <ec/>. That constraint exists only for canCopy, canDelete and canOverlap. > > I don't see anywhere either that the processor should magically complement the undefined attributes in <ec/> by looking at the > corresponding <sc/>. At the same time, obviously, it would be illogical to have different values. > > Are we missing yet another "implicit" constraint? My validator does not raise any error for it and it seems, at least to me, that current attributes of dataRef and startRef provide sufficient information. On the other hand, as Yves mentioned, it is not explicitly mentioned in the spec. Please share your thoughts. Best, Soroush. > > On Dec 19, 2015, at 12:38 PM, Yves Savourel <ysavourel@enlaso.com> wrote: > > Hi Soroush, > > More notes: > > -- 1) > > Several of the examples have "curly quotes" instead of normal ASCII double quotes to enclose attribute values. > A side effect of editing in an email probably, but they need to be correct in the spec. > > > -- 2) > > <unit id="u1"> > <originalData> > <data id="d1">&lt;br/&gt;</data> > </originalData>--> > <segment> > <source>This sentence has a breakpoint<ph id="ph1" dataRef="d1" > type="fmt" subType="xlf:lb"/>inside. > </source> > </segment> > </unit> > > The example above has a dangling "-->" after </originalData>. > > > -- 3) > > <unit id="u1"> > <originalData> > <data id="d1">&lt;u&gt;</data> > <data id="d2">&lt;/u&gt;</data> > </originalData> > <segment> > <source>A paragraph where <sc id="sc1" dataRef="d1" type="fmt" > subType="xlf:u"/>the formatted text takes more than one > segment. > </source> > </segment> > <segment> > <source> The second sentence here.<ec dataRef="d2" > startRef="sc1"/> > </source> > </segment> > </unit> > > In the example above, the <ec/> element seems to be missing the attributes type="fmt" and subType="xlf:u". > > Now, the Okapi validator gives an error on this, but I don't see in the spec any constraint that says type and subType must have the > same values in two corresponding <sc/> and <ec/>. That constraint exists only for canCopy, canDelete and canOverlap. > > I don't see anywhere either that the processor should magically complement the undefined attributes in <ec/> by looking at the > corresponding <sc/>. At the same time, obviously, it would be illogical to have different values. > > Are we missing yet another "implicit" constraint? > > > Cheers, > -yves > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >


  • 5.  RE: [xliff] XLIFF and ITS mapping- Elements within text

    Posted 04-26-2016 00:43
    Thanks for the reminder on this Soroush. I don't have any additional comment and I'm looking forward to other input. -ys
    Original Message


Related Content