OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-comment message

[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]