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] Attributes for translation candidates

Hi Lucìa,

Interesting thoughts.

> For origin I would like to propose something more
> specific (author, project...) than simply “origin”.

Maybe we need both: a simple attribute that allows simple systems to provide some 'origin' information that could be used for example to differentiate the various sets of matches; and a more detail set of properties that we can attached to the <match>.

As we seems all to agree, such set of properties could probably be re-used for other features.

One thing we have to be careful with however is how much of such properties would really be interoperable. The parts that are not should probably not be in XLIFF. In 1.2 we made the mistake of having many attributes that nobody used. We want to avoid this in 2.0 and keep only things that are truly interoperable.

> About "source comparison”, you were proposing "The similarity 
> value is an integer between 0 and 100”. I would even say 
> between 0 and 101, because some tools are using that number 
> to highlight in-context translation matches, which are supposed
> to be more accurate.
> I think this idea is related to the quality attribute you 
> are proposing.

It may be more efficient to separate the different information: To me similarity simply states how similar the source of the match is from the content it applies to.
Quality indicates how sure you are about the linguistic quality of the translation, that is how much the target of the match is truly translating the source of the match.
A match that was found in context (ICE, perfect, or whatever it's called) is a third information that is about extra data the tool was able to use while doing a matching. One can imagine ICE matches that are not 100 similar but because they are in-context should be used before more similar matches that were found in a out-of-context TM for example.
I would link the 1 of 101 more to the 'type' attribute, but even that attribute may need to be split between: a) the nature of it (MT, TM, assembly, alignment etc.) and b) how it was found (in the same document, from previous version, etc.)


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