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] 2.4. (S6) Resource Inheritance

Hi Rodolfo,


I tend to disagree with your position that language inheritance should belong to the application domain.


From my point-of-view, the (re)use of an existing approach (e.g. for language identification/language tags) should be as complete as possible in the sense that not just the namespace elements are being used but that also defaults, inheritance, processing expectations etc. are being applied.


As Steven points out, the situation wrt. language identification is somewhat tricky since at least two different approaches to handle fallback/generalization exist. One possible route to take would be mandate for XLIFF that either the CLDR or the BCP47 approach has to be implemented by XLIFF processors. Alternatively, one could introduce a data category that would allow one to specify which approach has been chosen (by the original/source language producer) or should be chosen (by the Localization Service Provider).


Here’s a real-world example why the overall situation needs attention:


                A translator receives a file with target language information such as en-UK.

                The translator only can work with a memory that has target language information en.

                The memory engine has not “fallback/generalization” – the translator cannot leverage the entries for en for his en-UK translation job.





From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Rodolfo M. Raya
Sent: Freitag, 14. September 2012 23:47
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] 2.4. (S6) Resource Inheritance


Hi Steven,


The problems with language inheritance belong to the application domain, not to XLIFF. The application processing the XLIFF file should know what to do with language codes and related data.


An application may choose to treat “zh-Han” as completely different from  “zh” and not inherit anything. The XLIFF standard should not attempt to dictate what to do.




Rodolfo M. Raya       rmraya@maxprograms.com


From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Steven R Loomis
Sent: Friday, September 14, 2012 2:23 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] 2.4. (S6) Resource Inheritance


Regarding: https://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/ResourceInheritance 

Hello, all. An update on one of the items I'm assigned to.

A couple of people on our team discussed this one, and we're not sure how it is relevant to XLIFF, at least at a core level.
If there was a tool or process which needed to specify some sort of inheritance, we would give guidelines such as this:

*  just chop the BCP47 subparts from the end forward  ( so  en-US falls back to en,  etc)
* however, STOP at the Script subpart.   So  zh-Hant-TW  falls back to zh-Hant, but does NOT fall back to just zh.   In CLDR we call this "prohibiting cross script inheritance", otherwise  zh ( which may be, for example, Simplified Chinese) and zh-Hant (which is, Traditional Chinese) would be intermixed.
* Note: CLDR has more complicated inheritance specifications, for example, es-CO (Spanish in Colombia) falls back to es-419 (Latin American Spanish -  419 is the UN M.49 code for Latin America).  However, these relations are data dependent and would not be recommended for XLIFF.

But, those guidelines are not relevant if this feature is not a core part of XLIFF.  

Does anyone else know how this feature is relevant to XLIFF? Otherwise we will recommend that it be withdrawn.

One somewhat related question is, do we use xliff to interchange speech related translation?


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