Re: [xliff-seg] a scenario

[Andrzej Zydron <azydron@xml-intl.com>]

Hi,

Just a restatement and further developments from today's discussion.

In my view there are two possible scenarios:

1) The data in the XLIFF file has been already segmented to an atomic 
level (e.g. sentence) prior to extraction. Any attempt at further 
segmentation is discouraged.
2) The data has only been extracted according to "hard boundaries" (e.g. 
paragraph level) and is capable of further segmentation.

In case 1) we could contemplate an attribute at the <file> element level 
which states segmented="true" and an optional 
segmentation-rules="http://www.xml-intl.com/segmentation/en_US.srx"; 
attribute if SRX rules are available.

In case 2) the default for the segmented attribute would be "false". If 
we want to segment the XLIFF data we should then require the following:

i. the value of the segmented attribute should be changed to "xliff" and 
  the segmentation-rules attribute should be mandated to point at the 
URL of the SRX file describing the segmentation.
ii. We need to either allow namespace extension to the source and target 
elements, or introduce segmentation elements along the lines proposed by 
Magnus by with some modifications:

<trans-unit id='100'>
  <segment-group>
   <segment>
    <source xml:lang='en' id='100.1'>First sentence.</source>
    <target xml:lang='fi' id='100.1'>First sentence.</source>
   </segment>
   <segment>
    <source xml:lang='en' id='100.2'>Second sentence.</source>
    <target xml:lang='fi' id='100.2'>Second sentence.</source>
   </segment>
   <segment>
    <source xml:lang='en' id='100.3' translate='no'>10.25</source>
    <target xml:lang='fi' id='100.3' translate='no'>10,25</source>
   </segment>
  </segment-group>
</trans-unit>

Some notes:
a) A segment for a single blank space between sentences as in Magnus' 
original example should not be required. If xml:space is set to 
"preserve" then such a blank segment may be required IF there is more 
than once space separating the two sentences.
b) The source and target elements should be in pairs.
c) An optional "flag" attribute may be required to allow the translation 
for multiple source segments to be grouped into one target element if 
the translator needs to do this because of 1) to correct a segmentation 
error, or 2) if the translation requires this.

Hope this helps,

AZ

Eiju Akahane wrote:

> 
> 
> 
> I think one of the most important reason we need "Segmentation" is the
> translation memory we have in our repository depends on the segmentation
> rules.  We need to perform segmentation with specific rule before applying
> memories.
> 
> Are there any other scenario?
> 
> Eiju Akahane, Yamato Software Lab., Software Group, IBM
> 
> Eiju Akahane/Japan/IBM wrote on 2004/03/09 21:33:18:
> 
> 
>>I am thinking a scenario.  This will separate the needs of
>>segmentation and memory from translation editor.  This will increase
>>the flexibility of the choice of translation editors.
>>
>>1. Development to produce XLIFF with or without previous translation
>>2. "Segmentation" logic to make segmentation in XLIFF
>>   - format will be defined in the sub-committee
>>   - segmentation rule can be supplied as SRX
>>3. "Memory Insertion" logic to apply translation memories from
>>memory repository by segment basis
>>4. Translator to translate it using a XLIFF aware translation editor
>>5. "Memory Extraction" logic to extract newly translated text at
>><target> and store into the memory repository
>>6. "Segment Concatenation" logic to restore original <trans-unit> --
>>this step might not be required
>>7. Development team to receive the translated XLIFF
>>
>>Eiju Akahane, Yamato Software Lab., Software Group, IBM
> 
> 

-- 


email - azydron@xml-intl.com
smail - Mr. A.Zydron
         24 Maybrook Gardens,
         High Wycombe,
         Bucks HP13 6PJ
Mobile +(44) 7966 477181
FAX    +(44) 870 831 8868
www - http://www.xml-intl.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
may not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version. Unless
explicitly stated otherwise this message is provided for informational
purposes only and should not be construed as a solicitation or offer.