Re: Work on a centralized infrastructure for i18n/l10n
Hello,
On Fri, Dec 23, 2005 at 02:15:28AM +0900, JC Helary wrote:
> >>Not po-reluctant. Some formats are better translated in tools that
> >>provide other functions: sentence segmentation (srx or not) for
> >>leveraging translation memories is not available in .po tools (as far
> >>as I know).
[...]
>
> maybe you want to look at these links besides for all the oasis pages:
> http://xliff-tools.freedesktop.org/snapshots/po-repr-guide/wd-xliff-profile-po.html
> http://xml.sys-con.com/read/121957_1.htm)
>
> there are a number of tools that handle documentation files in xliff
> while I don't see how an html manual could confortably (for the
> translator that is) be handled as a .po file.
I don't see in what way the XLIFF format is better for HTML translations.
I usually split the translation process as:
string
extraction translation
-----------> ------------>
Database Translator
<----------- <------------
displaying tool
translated
strings
* Some string extraction tools exist: xgettext, poxml, po4a, xml2po, some
tools generating XLIFF
* The database can be a PO file, an XLIFF file, or (why not) another
database.
* The translation tool is a tool able to deal with the format of the
database and help the translator (merging old translations, displaying
the strings that need to be updated, etc.)
* Displaying the translated strings is done by gettext or by generating
the documentation (this is usually done by the tool used for the string
extraction).
I don't exclude the manual translation: the extraction is done by an
human, who stores an original string in her brain, translate it and write
it in the translated document.
Thus IMO, advantages of the XLIFF format should be demonstrated by
considering XLIFF as the database.
I won't consider having good translation tools or string extraction tools
that deal with XLIFF files as an advantage of the XLIFF format.
My prefered translation tool is vi. Thus, as a translator, I prefer PO to
XLIFF or a mysql database.
It seems you like to have sentences separated. This is not related to
using XLIFF. This is a string extraction issue.
Note however that most of the complaints I receive for po4a (about its
strings extraction features) are that there is too few context in the
strings proposed to the translators, not that paragraphs should be split
in sentences.
It seems you prefer XLIFF for HTML translations. I don't know why, but it is
probably not related to the XLIFF format. Maybe it is just that the tool
you use with your XLIFF files is better than what a PO tool would have
done (at what step: string extraction, translation?).
One of the advantages of XLIFF could be for storing the old original and
translated strings (this is convenient to check what changed in the
original string; i.e. was the original string updated just to fix a typo,
or did the meaning changed?). With a PO, a versionning system can help to
check what changed; but this doesn't always work smoothly (e.g. when a
string move inside a PO).
This is not directly an advantage for the translator. It is just something
that can help the translation tool to propose another feature. With a
PO, this could be done by providing the old and new PO to a tool (I would
love to have such a tool).
One feature I don't like in XLIFF is having multiple languages in the same
XLIFF file. This was proved wrong with the debconf translations (multiple
translation updates can't be committed).
If you claim that XLIFF translation tools are better integrated to
translation memories, it is "just" a translation tool issue. And a PO
translation tool could also use TMX, or XLIFF memories could be converted
to gettext compendia.
Then if XLIFF based tools are really much better than PO based tools,
maybe these tools should be used (PO could be created temporarily if
needed). The links you provided did not convinced me.
Kind Regards
--
Nekral
Reply to: