RE: XLIFF 2.0 Comments - Language overrides for translatability and validation rules

[Josep Condal <pcondal@apsic.com>]

At first glance, it does not seem natural to add multilingual intelligence or capabilities into a format that by its own definition aims to be bilingual. 

 

But again, in my opinion the main focus on XLIFF should be on implementability, this time over legacy process convenience. I think that opening a door for encouraging polimorphism in XLIFF 2.0 can add a lot of complexity and hinder implementability. 

 

If this were added to the spec, next one would probably be adding language overrides for notes. After all, there might be language-specific instructions for translators on a given segment. And then this reasoning will move to virtually every single XLIFF tag available. 

 

For example, a requirement that I've seen implemented in tools (it was more noticeable when the world was only about monospaced fonts): it would be convenient that the <ignorable> tag can be polimorphic depending on language, because for some languages it is customary to put one space between phrases in the same paragraph and for other languages two spaces is a lot better. Therefore language overrides for <ignorable> serves a real-world need, so it would be a candidate for polimorphism if this door is open. 

 

Regards,

Josep.

 

---

From: Ryan King [mailto:ryanki@microsoft.com]
Sent: jueves, 30 de mayo de 2013 1:44
To: xliff-comment@lists.oasis-open.org
Cc: xliff@lists.oasis-open.org
Subject: [xliff-comment] XLIFF 2.0 Comments - Language overrides for translatability and validation rules

TC members, this feedback comes from non-TC internal implementers of the 1.2 standard at Microsoft. We’ve received feedback about the need to provide language overrides for the following:

 

·        Translate attribute in <segment> and <mrk>

·        <rules> in <val:validation>

 

Use Case:

 

A content provider can take one source and extract it to one skeleton and multiple XLIFF files per language being translated. In this case, the extractor can make decisions based on source properties or other business logic to either set the translate attribute in a particular language to “no” (for instance a product name should be localized in Russian but not the other languages) or choose not to include a certain rule (which may not apply to a specific language).

 

However, it may be more typical for a content provider to extract one skeleton and one XLIFF and rely on a localization supplier to duplicate the XLIFF for however many languages need to be localized. In this case, without specifying a mechanism in specification for overriding translatability or validation rules based on a specific language, which an editor could interpret, the Supplier would need to “hack” the XLIFF for that specific language, which may result in merge issues later.

 

Thanks,

Ryan