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] Proposal to allow a translator to indicate that a translationhas had to be grouped across more than one trans-unit


Hi Gérard,

Thank you for your reply. As you state, this is a familiar problem. What I am 
advocating is not to fix the problem - that can only be done in the merged file 
or by reauthoring the source file.

My proposal is only to provide a "notation" that signals that the translator was 
only able to provide a comprehensive translation by taking more than one 
trans-unit into account and grouping the translation into one "head" trans-unit.

You are correct in stating that the better course of action is to correct the 
source. Nevertheless this is not always practical. It might mean stopping a 
translation more than half way through and then after correction and creation of 
a new XLIFF file of having to retranslate the source again. When you are 
translating into 21 languages using multiple translation suppliers the shear 
logistics of correcting the source and translating again are daunting.

Now let us consider the alternative - to leave the other trans-units empty 
without any explicit intention of purpose. Empty trans-units may signify that 
the translator has just forgotten to translate a trans-unit - an occurrence 
which I have encountered reasonably frequently. In fact I have a detailed XLIFF 
checking utility that treats empty trans-units as an error, which has prevented 
many such mistakes from passing unnoticed in the translation process.

If we provide a notation that allows the translated XLIFF to state that the 
correct translation may only be rendered by considering two or more trans-units 
together we add important extra intelligence that may be used by the merging 
filter and also by any post translation DTP process. The emphasis is on the MAY 
- there is no compulsion and there would also be on backwards compatibility issues.

Best Regards,

AZ

Gerard Cattin des Bois wrote:

> Hello Andrzej,
> We have experienced this many times. 
> 
> This is in part the reason for doing localizability validation (pseudo-localized builds and BVTs). Typically, these broken strings are logged as localizability issues, and are not passed to localizers until fixed. 
> 
> I don't believe that localization should be fixing localizability issues. They are truly core development team issues that should be resolved there. The developer needs to write localizable code, and after separating code and localizable strings, the next item of importance is to have complete sentences submitted to localization. 
> 
> My take on the proposal is that Xliff is the wrong place to fix the problem.
> Cheers,
> -Gérard
> Families are living sanctuaries
> 
> 
> -----Original Message-----
> From: Andrzej Zydron [mailto:azydron@xml-intl.com] 
> Sent: Monday, April 12, 2004 12:00 PM
> To: xliff@lists.oasis-open.org
> Subject: [xliff] Proposal to allow a translator to indicate that a translation has had to be grouped across more than one trans-unit
> 
> LIGHTWEIGHT REQUEST FOR COMMENT
> 
> 
> Date Submitted:   04 / 15 / 2004
> 
> Author(s),  Contributor(s) with affiliation(s):
> 
> Andrzej Zydron
> 
> 1. STATEMENT OF PURPOSE
> 
> In a situation where due to incorrect presentation of the text for translation a 
> translator has had to group the translation for one or more trans-units into one 
> trans-unit a mechanism should exist that allows the translator to indicate what 
> he has done.
> 
> An example might be a badly authored source document where for example a table 
> heading has been split using a "paragraph" mechanism so as to split the source 
> text into a number of distinct elements. An example which most of us will be 
> familiar with might be as follows:
> 
> <table>
>   <heading>A heading</heading>
>   <heading>
>    <para>This is an</para>
>    <para>example of badly</para>
>    <para>authored material for</para>
>    <para>translation</para>
>    <para>purposes</para>
>   </heading>
> </table>
> 
> In this instance the resultant translated XLIFF file may look like this:
> 
> <trans-unit id="1">
>    <source>A Heading</source>
>    <target>Nadglowek</target>
> </trans-unit>
> <trans-unit id="2">
>    <source>This is an</source>
>    <target>Oto przyklad zle przygotowanego materialu na tlumaczenie</target>
> </trans-unit>
> <trans-unit id="3">
>    <source>example of badly</source>
>    <target/>
> </trans-unit>
> <trans-unit id="4">
>    <source>authored material for</source>
>    <target/>
> </trans-unit>
> <trans-unit id="5">
>    <source>translation</source>
>    <target/>
> </trans-unit>
> <trans-unit id="6">
>    <source>purposes</source>
>    <target/>
> </trans-unit>
> 
> Faced with the inability to render the text correctly in the target language the 
> translator has had to put the translation against the first trans-unit and left 
> the other ones empty.
> 
> 2. STATEMENT OF REQUIREMENTS
> 
> It would be very useful in the above circumstance to be able to explicitly state 
> in the XLIFF file that the text for the empty <target> elements has been merged 
> with the first trans-unit. This allows for explicit checking to prevent empty 
> translations.
> 
> An example of such a mechanism could be to add a "merged" value to the 
> trans-unit "translate" attribute - e.g.
> 
> <trans-unit id="1">
>    <source>A Heading</source>
>    <target>Nadglowek</target>
> </trans-unit>
> <trans-unit id="2">
>    <source>This is an</source>
>    <target>Oto przyklad zle przygotowanego materialu na tlumaczenie</target>
> </trans-unit>
> <trans-unit id="3" translate="merged">
>    <source>example of badly</source>
>    <target/>
> </trans-unit>
> <trans-unit id="4" translate="merged">
>    <source>authored material for</source>
>    <target/>
> </trans-unit>
> <trans-unit id="5" translate="merged">
>    <source>translation</source>
>    <target/>
> </trans-unit>
> <trans-unit id="6" translate="merged">
>    <source>purposes</source>
>    <target/>
> </trans-unit>
> 
> This is only an example of a possible mechanism. It could well be that an 
> existing mechanism already exists to render this information but I could not see 
> anything obvious.
> 
> 3. PROPOSAL
> 
> Adding an extra attribute value to indicate that the translation for a given 
> trans-unit has had to be merged with a preceding trans-unit.
> 
> 4. IMPLEMENTATION
> 
> Possibly adding an extra "merged" value to the trans-unit translate attribute.
> 
> 5. SCHEMA/DTD
> 
> Possibly adding an extra "merged" value to the trans-unit translate attribute.
> 
> 6. BACKWARDS COMPATIBILITY
> 
> There should be no backward compatibility effect.
> 
> Best Regards,
> 
> 
> Andrzej Zydron
> 

-- 


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]