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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-seg message

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


Subject: XLIFF Segmentation at trans-unit or group level


Summary:

In a nutshell,  the concept behind this scenario is that segments can be defined by the hard structure of trans-units,  or optionally within groups. All segmentation functionality is offloaded to the tools that generate or process the XLIFF content,  including resegmentation.

Original Discussions:
http://www.oasis-open.org/archives/xliff-seg/200404/msg00024.html
http://www.oasis-open.org/archives/xliff-seg/200404/msg00012.html

Original XLIFF file:

<trans-unit id="1">
   <source xml:lang="en-US">Long sentence. Short sentence.</source>
   <target xml:lang="sv-SE" state="final">Lång mening. Mer mening. Kort mening.</target>
</trans-unit>
 

Which can be segmented using a tool into the following "hard" segments:

<trans-unit id="1.1">
   <source xml:lang="en-US">Long sentence.</source>
   <target xml:lang="sv-SE" state="translated">Lång mening. </target>
</trans-unit>
<trans-unit id="1.2">
   <source xml:lang="en-US">Short sentence.</source>
   <target xml:lang="sv-SE" state="translated">Kort mening.</target>
</trans-unit>

Or,  we can create segmentation groups that contain the individual segments,  and tag them with additional metadata that identifies them as segment-groups/segments:

<group extype="segment-group" id="1">
   <<trans-unit extype="segment" id="1">
   <source xml:lang="en-US">Long sentence.</source>
   <target xml:lang="sv-SE" state="translated">Lång mening.</target>
</trans-unit>
<trans-unit extype="segment-group" id="2">
   <source xml:lang="en-US">Short sentence.</source>
   <target xml:lang="sv-SE" state="translated">Kort mening.</target>
</trans-unit>
</group>

When reconciling with the skeleton file,  presumably when building out the translated file,  a tool would need to match up the segment-group with the original segment it replaces.  Similar reconciliation would be required if updating the TM.

PRO's:
  1. Uses existing XLIFF structures:  no additional changes to XLIFF specification is required.
  2. For most use cases,  very simple to implement.
CON's:
  1. Matching up resegmented data becomes tool dependent,  and may be handled differently by individual tool providers.
  2. May not be suitable or very complicated for moving segments across groups (ie, resegmenting the segment-groups).
  3. May not be suitable for processing target only changes returned by vendor.
  4. <>Implementation is non-normative,  and would require adherence to profile rather than XSD validation.
  5. Complicate process of building out translated content using skeleton files.
  6. Multiple iterations of resegmentation may create tangle of groups.
-- 
Tony Jewtushenko				
Principal Product Manager - Oracle Application Development Tools
Oracle Corporation, Ireland

mailto:tony.jewtushenko@oracle.com
Direct tel: +353.1.8039080	


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