On 23 déc. 07, at 19:21, Yury Tarasievich wrote:
However, I do care about lack of meta-information which renders many
actual translation issues hard to resolve. Your scheme does not
address that matter and actually would postpone its resolvement.
No, it does not.
XLIFF is equivalent to SDF in terms of the possible availability of
"context information".
Besides, and that seems to totally go over the head of the l10n
engineers here, the best context is actually the source contents in
visual form.
The current processes are common in the industry where what is shown
to the translation is only a diff of the source file. So of course
there is a need for extra context... When it comes to UI files it is
of course a little tricky to offer visual context, we'd need
screenshots or things like this. But currently, most of the work is
not so much the UI than the help files, where source files _could_ be
provided to support the translator.
By the way, this "source+TM" process is adopted by NetBeans, another
of SUN's products.
In NetBeans, the l10n teams get _all_ the source (HTML for help and
Java properties for UI, only) and match it to _all_ of the previously
translated contents with TM files. That allows for much better
handling of context and contents. And they can use that because they
are not scared by the idea of using a single uniform process. They all
use OmegaT, standard TMX files and that's it. And that works.
The supposed flexibility given by the SDF files is non sense. Giving
diffs of files and adding meta information to make for the lost
context is non sense.
It may be elegant from the developer's point of view, and considering
that it comes from a client-vendor localization structure where the
client pays the vendor only for the non translated strings it used to
make some _economic_ sense but that is irrelevant now when the
"vendor" is a community of volunteers.
By the way, what is the workflow for StarOffice localization that is
not outsourced to the OOo l10n teams ? Can anybody answer that ? Do
they still use .xlz files ?
As I see it, it's not quite possible to "choose" XLIFF 1.0 or 1.1,
because some tools do 1.1 only (xliff<->po toolkit) and free visual
environments don't do 1.1 (Sun OLT - yet? Python XLIFF editor).
No it is not possible to "choose" but it is possible to create XLIFF
"core" files that would differ only by their headers (reference to a
DTD for 1.0, or to a schema for 1.1). For the rest, all the
differences in tags are clearly explained here:
http://www.oasis-open.org/committees/xliff/documents/cs-xliff-core-1.1-20030521.htm#AppChanges
I doubt that the actual output of standard tools _without_ any sort of
TM pre-processing would include exotic tags, so this "core XLIFF"
compatibility output would actually be most probably the norm than the
exception.
And btw, OmegaT does not care about the XLIFF version, it just
requires that the source information is copied in the target field
(lile Okapi outputs) and that happens to be _exactly_ the structure of
an SDF file...
Anyway, merry Christmas to all who'll read this post on time !
----------------------
Jean-Christophe Helary
http://mac4translators.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
