[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-comment] using xliff to translate html -- (From Nico)
On the behalf of Nico: -----Original Message----- From: Nico van de Water [mailto:nicovdwater@planet.nl] Sent: Fri, September 05, 2003 12:06 AM To: ysavourel@translate.com Cc: itia-members@yahoogroups.com Subject: Re: [xliff-comment] using xliff to translate html Hello Brian and Yves, First, Yves, thanks for your very lucid explanation of these aspects of XLIFF. Although I did a bit of reading up on XLIFF, your examples are brilliant. However, ideal as an XML / XLIFF environment may seem (especially from a productivity point of view), as someone with nearly 25 years in translation and 17 in localisation, I must emphasise that in most cases an XML / XLIFF environment strips away the translator's most vital aspect of his job, namely the context of the element / sentence / string to translate. [snip] > Keep also in mind that, like for other formats, only the inline elements of > HTML (<b>, <em>, img>, etc.) will be in the source/target content, not any > of the structural elements (<table>, <li>, <tr>, etc.). From a translation > tool viewpoint there is no reason to treat them differently from other > format. A string like "Set the parameters" in a table header will probably be translated differently from the same string as the first in a list of instructions at, let us say, table row level. Context, and structural context at that, is essential. Especially when translating Help and software, a correct interpretation of the intended use of the string is crucial. In the "good old days", the format of the .C, .H, and .RC files would provide such a context, as would the .RTF files for the Help. Pouring all the strings together in an XML / XLIFF environment robs the localiser / translator of such essential information as where does one menu end and the next start (required to avoid duplicate mnemonics), is it a header or instruction (usually found out by looking at the print-out of the .RTF file), etc. I agree with many of you that the uniform presentation of the strings to be translated may lead to more consistency and thus a higher quality in translation. The downside, I am afraid, is that Project Managers will be more busy than ever answering questions like 'Is this an instruction or a header?', etc. Localising software in itself is already difficult enough; incorporating strings and Help text in one big XML / XLIFF corpus will at times be a nightmare. I have been using XML-based corpuses for translation for well over a year now, and so far the lack of context (often because the source texts were devoid of a printable context) outweighs the advantages of uniformity and consistency. Even worse, the very absence of context may lead to more translation errors ... I do recognise the vast advantages of both XML and XLIFF in their own specific ways (XML for processing and transferring data, and XLIFF for terminology management and maintenance), but combined use in a translation environment is, for the time being, not my favourite. With thanks for reading and kind regards, Nico van de Water ----------------------------------------------------- Nico van de Water, MITIA Technical communicator <pro_file> DocSolutions [t] +31-24-3234954 [e] nicovdwater@planet.nl
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]