Re: [xliff] Simplified XLIFF element tree

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

  Hi Rodolfo,

Very well put. I totally agree.

Best Regards,

AZ

On 23/08/2010 13:37, Rodolfo M. Raya wrote:
> Hi again,
>
> There are two different issues to consider:
>
> 1) How to represent a single segment.
> 2) How to represent segmentation information in an XLIFF file.
>
> I propose to use<trans-unit>  with a<source>/<target>  pair to represent a single segment (issue 1).
>
> Before analyzing issue 2, we need to define some basic concepts and use cases. I would call "text block" to a portion of extracted translatable text that can be split into two or more "segments".
>
> As Andrzej suggested, a "text block" can be represented using the existing<group>  element. Each component "segment" can be stored in its own<trans-unit>. He provided an example that clearly shows how to do that.
>
> The problematic use cases requiring segmentation information that I'm aware of are:
>
> a) Wrong segmentation at text extraction time that needs to be fixed at translation time (an unrecognized abbreviation for example).
>
> b) Translation of "m" segments that requires "n" segments in target language.
>
> Both cases can be properly handled by allowing translators to merge and split<trans-unit>  elements within a given<group>  as needed. This can be done today using<group>  and<trans-unit>  and their existing attributes. I've implemented this mechanism several times and I know it works very well with XLIFF 1.0, 1.1 and 1.2.
>
> We need to define in XLIFF 2.0 the official way in which segments can be merged or split at translation time.
>
> Regards,
> Rodolfo
> --
> Rodolfo M. Raya<rmraya@maxprograms.com>
> Maxprograms      http://www.maxprograms.com
>
>
>> -----Original Message-----
>> From: Yves Savourel [mailto:ysavourel@translate.com]
>> Sent: Monday, August 23, 2010 9:05 AM
>> To: 'xliff'
>> Subject: RE: [xliff] Simplified XLIFF element tree
>>
>>> ...You can segment the<para>  or<p>  at text
>>> extraction time and put each segment in its own<trans-unit>.
>> I agree with Asgeir: extracting and segmenting should be two distinct
>> operations. While they can be done transparently at the same time for the
>> user, I think it's important to make a distinction between the representation
>> of the extracted unit and the segments.
>>
>>
>>> ...If you use a spanning mechanism inside source, you will
>>> have multiple segments in source and target and the number
>>> of source fragments may not match the number of target
>>> fragments; that's very bad for TM/MT support and not XSLT
>>> friendly at all.
>> I agree with Rodolfo: there are some drawbacks with using spans: order,
>> number of segments, etc. But those issues are maybe a product of
>> segmentation-related processes we will always have. For example an
>> automated tool can create a tentative alignment with n-to-m cases and
>> provide the result in XLIFF for a user to finish/correct the aligned set.
>>
>> Maybe there are other representations we can have other than using<trans-
>> unit>  or using<seg-source>  that would allow a more seamless tracking of
>> segments. We need to imagine it.
>>
>> -ys
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> ---------------------------------------------------------------------
> 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
>

-- 
email - azydron@xtm-intl.com
smail - c/o Mr. A.Zydron
	PO Box 2167
         Gerrards Cross
         Bucks SL9 8XF
	United Kingdom
Mobile +(44) 7966 477 181
FAX    +(44) 1753 480 465
www - http://www.xtm-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.


begin:vcard
fn;quoted-printable:Andrzej Zydro=C5=84
n;quoted-printable:Zydro=C5=84;Andrzej
email;internet:azydron@xml-intl.com
tel;work:+441494558106
tel;home:+441494532343
tel;cell:+447966477181
x-mozilla-html:FALSE
version:2.1
end:vcard