OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xliff-comment] XLIFF 2.0 Comments - Language overrides for translatability and validation rules


Hi Ryan,

This sounds a lot like a use case for the ITS Locale Filter data category of ITS 2.0 (http://www.w3.org/TR/its20/#LocaleFilter).
There is a mapping ITS/XLIFF under construction, that, for XLIFF 2.0, should result in an official module.

See the Locale Filter row in this page http://www.w3.org/International/its/wiki/XLIFF_Mapping for an example. (Note: the info on
that page is being moved to separate pages for 1.2 and 2.0).

-yves


From: Ryan King [mailto:ryanki@microsoft.com] 
Sent: Wednesday, May 29, 2013 5:44 PM
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






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]