OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  RE: [xliff] XLIFF 2.0 Core

    Posted 04-09-2011 11:07
    >> I'm not sure #2 applies. If they keep their data within a unique >> toolset there is little advantage in using anything but some >> proprietary format it would seems. The only reason would if they >> want to be ready for #3. > > I use XLIFF format to keep the data used by my translation tools. > That's case #2 in David's list. > By using XLIFF as internal data format, there is no need to > export/import anything for exchanging data with another tool > (case #3), the data is ready to use. Like I said: "The only reason would be if they want to be ready for #3." A good reason certainly, and if a tool like Swordfish and Trados Studio can do it, more power to Rodolfo and Andrew :) But I still think #2 is not a good use case for designing XLIFF: XLIFF is an exchange format not an internal data format, or for native storage format. One potential issue with using any exchange format as an internal data format is that the exchange format may have to provide features or follow some structures that may not be the most efficient for internal data. In other words, there may be conflicts of interest between XLIFF as exchange format and XLIFF as internal format. Internal data need to be tailored for the feature set the tool provides, for speed, simplicity, etc. While the exchange formats should favor interoperability, which means possibly support for features not implemented by some tools, which means not necessarily the best structure for all tools. That is OK because exchange formats are normally converted/mapped to the tool-specific internal data format. So such tool pays the interoperability price only when it imports/exports, but its normal behavior is not affected. But when that conversion buffer is absent, the tool is constantly and directly exposed to any aspect of the format that can be an impediment for its internal workings. In other words, parts of the exchange format may become drawbacks and hindrances for the performance of the tool. And that, when working on defining the format, may lead to the danger of favoring the internal data aspect rather than the exchange format aspect, to favor some features over others, etc. That's why I think #3 is a good use case and #2 is not: XLIFF shouldn't care what happens within a specific tool, it should care only about working between tools. This said, I know people like Rodolfo and Andrew are perfectly capable of having the discipline to separate both aspects and always favor exchange/interoperability over internal data when working in the context of the TC. -ys


  • 2.  RE: [xliff] XLIFF 2.0 Core

    Posted 04-09-2011 20:24
    >
    Original Message


  • 3.  RE: [xliff] XLIFF 2.0 Core

    Posted 04-10-2011 13:54
    Hello,

    I am following these last emails with interest, thanks for making such an impressive progress.
    I totally agree with the structure you have proposed for the core elements.
    I have downloaded Rainbow and tried it with some files and it worked for me perfectly.

    I have being thinking about the proposed <match> and <matches> (the previous <alt-trans>).
    If we take them out of the core and consider them as a modular element, maybe this is also the momentum to work on them and exploit their possible uses to the full.
    Rodolfo differentiated <match> and <matches>:

    ><matches> : collection of matches retrieved from any system (MT, TM, etc.)
    >Contains:
    >- One or more <match> elements
    >------------------------------------------------------
    ><match> a potential translation suggested for the enclosing <segment> element
    >Contains:
    >- One <source> element followed by
    >- One <target> element

    I personally like this idea. I think the <matches> elements are providing pre-translation information that could help the translator in his job.
    However, the <match> property could also be used to store previous changes in the segments (this is currently done in the target element by adding the state attribute with workflow information and/or by making use of the phase mechanism) . I think this can be one of the most interesting uses. For example, if you can store there a translation that a translator has done but the proofreader has discarded. This would allow us to keep track of the changes of the document to a great granularity. Using Rodolfo ´s example:

    <unit id="ud1">
    <segment>
    <source> John D. Williams went to the park. </source>
    <target> </target>
    <match user="proofreader" name="Linda Spencer" date="2011-04-10T11:30:00Z"">
    <source> John D. Williams went to the park.
    </source>
    <target> John D. fue al parque.
    </target>
    </match>
    <match user="translator" name="James Lee" date="2011-04-09T09:30:00Z">
    <source> John D. Williams went to the park.
    </source>
    <target> John D. fue a el parque
    </target>
    </segment>
    </unit>

    In this example we have two options:
    a)To have the main target blank until a final translation is reached.
    B)To introduce in the target element the latest modification.


    Most of the things that I have just mentioned are already present in 1.2, but most tool makers do not make use of those possibilities. I think we can work on this modular <match> and give them a guide to keep track of the changes in the document.
    What do you think?

    Lucia





    Original Message


Related Content