Forum: CAT Tools Technical Help
Topic: XLIFF mixed language -- any tool/process to input into a translation workflow?
Poster: Samuel Murray
Post title: Yes
[quote]Rodolfo Raya wrote:
In a translation unit like the one in your example, you start with the default attribute values. ... Any translation present in ‹target› is just a hint unless the "approved" attribute of ‹trans-unit› is added and set to "yes". If the attribute is missing, the segment needs review before the translation can be used. [/quote]
That is my interpretation as well (though I'm not an expert at this at all).
If the XLIFF file was created by a tool that implements the XLIFF specification correctly, or is to be edited by a tool that implements the specification correctly, then if ‹trans-unit› has no "approved" attribute, then the "approved" attribute's value is automatically "no". However, if the client's XLIFF tool does not implement the specification correctly, e.g. it uses some other way to determine if a segment is approved or not, then it may not matter what the XLIFF file itself declares about it.
An example (a poor example, perhaps, but an example nonetheless) is Virtaal. The XLIFF files created by the Virtaal utilities do not rely on the value of "approved" in the ‹trans-unit›, but instead relies on the "state" of the ‹target›. If the state is not mentioned, then Virtaal assumes the state is "needs work" (whatever that means), and if the segment is translated, then Virtaal sets the "state" of the ‹target› to e.g. "translated" or "reviewed", without making any edits to the "approved" in the ‹trans-unit›. This goes against the specification, but: as long as translators who work on XLIFF files that were created by the Virtaal utilities use Virtaal (or the Virtaal utilities) to work on those XLIFF files, everything will work out all right.
A pragmatic CAT tool might make assumptions behind the user's back. For example, in the absence of "approved" in the ‹trans-unit›, the developers may have decided not to assume "approved=no" (as specified in the specifications) but instead to assume things like: (a) if the ‹target› is empty, then the segment is untranslated, (b) if the ‹target› is the same as the ‹source›, then the segment is untranslated, and (c) if the ‹target› is different from the source, then it is translated.
One CAT tool might assume that if the source and target text are identical, then the target text is not translated but simply contains the untranslated source text, whereas another might assume the opposite: if the target text is not empty, then whatever is in the target text is considered the final translation upon delivery.
[quote]SoerenB wrote:
So when I only get thousands of files in such simple structure, and with obvious mix of already translated and requiring translation -- but no trace of state or approved attribute/value -- then I am surely missing something from the customer. [/quote]
Well, one of the first things you can do is to ask the client what XLIFF program they're using. You may be able to figure out what assumptions their system makes if you know what the client's XLIFF tool is. Another thing you can do is ask the client (assuming he is knowledgeable enough to know what you're asking), e.g. "how can I distinguish between segments that need no review and segments that do need review", etc. or ask questions that lead you to the answer, e.g. "do you want me to review existing translations".
You can also make some assumptions yourself, e.g. if I were given such a stateless file and I was asked to "translate" and not to review (e.g. ignore existing translations, or e.g. not getting paid for 100% matches), then I would have assumed that any segment that has either no ‹target› or an empty ‹target› or a ‹target› that is the same as the source text, must be translated by me, and that any other ‹target› should be considered to be in a final state, not to be touched by me.
Remember, the fact that text has a certain status in the XLIFF file does not necessarily mean that that is the state that the client believes the text has. If a client uses his XLIFF tool in an "incorrect" way, or if the client's XLIFF tool implements the specification in a non-standard way, then what matters is what the client says, and not what the XLIFF specification says.
[Edited at 2019-07-30 13:02 GMT]