[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff-seg] a scenario
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]