OASIS XML Localisation Interchange File Format (XLIFF) TC

Back to discussions
Expand all | Collapse all

Re: [xliff] Proposal to allow a translator to indicate that a translationhas had to be grouped across more than one trans-unit

  • 1.  Re: [xliff] Proposal to allow a translator to indicate that a translationhas had to be grouped across more than one trans-unit

    Posted 04-16-2004 19:49 
     MHonArc v2.5.0b2 -->


















    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
> 
> 
>


Related Content