[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, Thanks for the example. It’s a good illustration of something that, I think, should not be allowed in 2.0 (just like it is not allowed in 1.2). You are correct: the extra markup in <source> prevents the core to work. So it shouldn’t be done. Like Rodolfo noted: it is a basic principal that we should maintain. If people want to have complex modules that do work in XLIFF (in <source> or elsewhere) they should be in the TC right now so their requirements can be taken into account. But there is another solution: technically all that can likely be represented with one or few extension attributes in a <ph> element of XLIFF and possibly a structure outside <source>. And that whole thing could then be an extension that would not prevent the core to be processed normally. Maybe it wouldn’t be pretty or elegant, but it would keep interoperability alive. I think there is nothing wrong for a specific vertical to come up with additional features for XLIFF, as long as they can be treated like an optional module and follow the requirements for that. For example: - Cannot break the core - Cannot represent features that are available in either the core or one of the official optional module. - Maybe other things… And, obviously, if anyone would like to see their module be part of the standard ones, I would encourage them to join the TC and work with us on that. Cheers, -yves From: Arle Lommel [mailto:alommel@gala-global.org] 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"?> <!-- 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> 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]