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] To extend or not to extend. Was: [xliff] Definition of "core" and "modules"


Hi Arle,

 

In XLIFF 1.2 you are not able to use custom extensions inside <source> or <target>. These two elements must be supported by any tool that works with XLIFF files and introducing proprietary parts in them would have been a major interoperability disaster.

 

Not supporting custom extensions in the middle of translatable text is a basic principle that we should maintain.

 

Regards,

Rodolfo

--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms      
http://www.maxprograms.com

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Arle Lommel
Sent: Thursday, November 17, 2011 5:30 PM
To: Yves Savourel
Cc: 'XLIFF TC'
Subject: Re: [xliff] To extend or not to extend. Was: [xliff] Definition of "core" and "modules"

 

Hi Yves,



Not sure if I understand: XLIFF elements "can" support only what they are designed for. Anything else would be extensions. In other words: all use cases of extension should be cases of things the XLIFF specification does not provide for.

 

Let me use a more concrete example. That may help make my point clear (or show that I'm completely wrong). Suppose we want a “Variable Text XLIFF”. It might end up looking something like the following (where the module/extension-specific content is in red and I've ignored the need for namespaces):

 

   <?xml version="1.0" encoding="utf-8"?>
   <xliff version="2.0" segment="block">
      <file srclang="en" tgtlang="ru" original="variabletext">
         <unit id="item1">
             <source>

                <!-- source is something like "$1 kill{past} $2 with a sword" -->

                <textVariableSet var_id="A" number="sing" case="nominative">

                   <selector selectorID="1" gender="masc"><name/></selector>

                   <selector selectorID="2" gender="fem"><name/></selector>

                </textVariableSet>

                <textVariableSet var_id="B" agreesWith="A,C" tense="past">

                   <!-- The next line tries to show cases where the translation would apply.

                        In this case all of them apply since English doesn't care... -->

                   <selector selectorID="3" applicableCases="1-5,1-6,2-5,2-6">killed</selector>

                </textVariableSet>

                <textVariableSet var_id="A" number="sing" case="accusative">

                   <selector selectorID="5" gender="masc"><name/></selector>

                   <selector selectorID="6" gender="fem"><name/></selector>

                </textVariableSet>

                with a sword.

             </source>

             <target>

                <textVariableSet var_id="A" number="sing" case="nominative">

                   <selector selectorID="1" gender="masc"><name/></selector>

                   <selector selectorID="2" gender="fem"><name/></selector>

                </textVariableSet>

                <textVariableSet var_id="B" agreesWith="A,C" tense="past">

                   <!-- ...but in Russian, it does matter. In a language with complex

                        object incorporation you might have four options here! -->

                   <selector selectorID="3" applicableCases="1-5,1-6">убил</selector>

                   <selector selectorID="3" applicableCases="2-5,2-6">убила</selector>

                </textVariableSet>

                <textVariableSet var_id="A" number="sing" case="accusative">

                   <selector selectorID="5" gender="masc"><name/></selector>

                   <selector selectorID="6" gender="fem"><name/></selector>

                </textVariableSet>

                с мечом.

             </target>              

         </unit>
   </file>
   </xliff>

 

The core stuff is all fine, but if you attempt to translate the <source> element without the tool being aware of the constructs from the module/extension, you will get something wrong. In other words, for the tool to support the translator, it would need to know about the meaning of the module/extension and it could not process it as core only. Processing as core only would result in a bad construct. (And also note that I'm presuming that this stuff relates to a hypothetical variable text standard so it is not a tool-specific thing.)

 

So this is localization-related stuff that the core XLIFF specification does not provide for (and should not provide for, in my opinion), and would be an extension, but such an extension violates the idea that a core-only tool should be able to process it.

 

So maybe the answer is that this format would be treated like IDML, Word, or any other file format that is filtered and the markup stashed inside the appropriate metamarkup elements, despite the clear localization orientation in this case. It would be left up to the tool/user to figure out what to do with the markup, and would not be an XLIFF question at all.

 

I use this example because, at first blush, adding some information about variable text localization would seem like a good candidate for extension (and I think it might have been done like that in 1.2), but it looks like it would end up creating more problems than it's worth. So if the guidance is, as Rodolfo suggested, that information in a module/extension cannot interfere with processing in a core-only mode for 2.0, then this extension would be disallowed and one would be forced to treat the red stuff as native file-format code to be filtered.

 

If that's the answer, I'm fine with that. I simply wanted to understand how far one could go with extension/modules. The answer then is, not really very far, which is a fair answer.

 

-Arle



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