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] XLIFF 2.0 example files for segmentation


I'm sorry my first note was so confusing, but I think that the discussion has been good.

In my original note, there were 5 different XLIFF examples shown:

  1. XLIFF created by an extraction tool (tool A).  2 variations provided depending on whether <segment> was required (core) or not (module).
    File 1.  <segment> element was not included.
    File 2.  <segment> was included.  Translatable content of <unit> is the same as the content of <segment>.
  2. XLIFF file created and used in translation tool (tool B), created from step A XLIFF file.
    File 3.  Contains sentence segmented text and translated into Spanish.
  3. XLIFF file returned to product after translation.
    File 4.  Expected output if file 1 was used as input.
    File 5.  Expected output if file 2 was used as input..


Rodolfo: David:

Yves: David: Rodolpho: David:
Rodolfo: David:


David:


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 Yves Savourel ---11/09/2011 05:34:53 PM---> So the scenario I pulled from Dave's example,  > file witYves Savourel ---11/09/2011 05:34:53 PM---> So the scenario I pulled from Dave's example,  > file with <segment>s is refactored as file


    From:

Yves Savourel <ysavourel@enlaso.com>

    To:

"'XLIFF TC'" <xliff@lists.oasis-open.org>

    Date:

11/09/2011 05:34 PM

    Subject:

RE: [xliff] XLIFF 2.0 example files for segmentation

    Sent by:

<xliff@lists.oasis-open.org>




> So the scenario I pulled from Dave's example,
> file with <segment>s is refactored as file
> with different <segments>s but has to be
> restored to original <segments> is a chimera.

A bad dream indeed.


> ..then Dave's example would need to lose
> snippets two and five. Is that right?

1 and 4, and 5 is not needed. But the merger should work with either 3 or 5.


> If segmentation is moved to the translation domain
> and adjusted at translation time, aren't we saying
> that segmentation is really a function of the import
> filter (and hence beyond the scope of XLIFF),
> just as it would be for any other file format?
> I don't need to indicate segmentation in Word or
> IDML, so what makes XLIFF different in this regard?

Well the "re-" segmentation is moved out of the extraction tool domain. But there is a block-level segmentation too: You do use it in Word and IDML: paragraphs, footnotes, table cell, etc.
Likewise that "block"-level segmentation is done by the extraction tool: <unit> hold a "block" which initially is stored in a single <segment>.

Why use both <unit> and <segment> initially? Why not just <unit> like in David's snippets 1 and 4?

Because it's just more efficient. Maybe forget about block/sentence and see it that way: until it (optionally) gets segmented further that content is the "segment" for that unit. So why shouldn't be in <segment>?

Think about Word and pages: your content is in a single page or several: you decide where the page breaks are. Even when there are no page break there is a page. A <segment> is similar to a page.


Cheers,
-ys



---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org





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