Friedel,
Thank you for the very comprehensive reply.
tags are escaped, and yes, if somebody does the work, going directly
from the XML help files to translation formats, could provide some
benefits.
Could you point where the files are ?
meta-information by means of the x-comment information. oo2po from the
translate toolkit will add those notes to the PO file (and oo2xliff
will
add it to note tags of XLIFF files).
Have you considered the "context" XLIFF tag ?
We also have a converter that goes directly from SDF to XLIFF. It
shipped with the current version of the toolkit, although a packaging
bug might hide it for some users. The packaging bug will be fixed in
the
next versions of the toolkit.
When do you plan to release it ?
can therefore be seen as being similar to compiling to binary
format. We
store our localisation formats in a version control system, and that
is
considered to be the stored translations. This way we also don't
need to
"retranslate with a TM" at the start of version update such as the
method is with OmegaT (according to my understanding).
Well, another way to look at OmegaT is to consider it as a CVS
specialised in translated strings.
There is no need to retranlate with a TM in the case of OOo since we
only get the non translated strings as source. NetBeans does that
differently. They release _all_ the strings so it looks more like what
you describe.
OLT with XLIFF files:
About OLT not being able to open our XLIFF files: our XLIFF files are
well formed as far as we know - please report any bugs to our mailing
list or bugzilla. We have validated some of our XLIFF files
according to
the XLIFF DTD, so I would be surprised if they are truly malformed.
OLT supports only XLIFF 1.0. From what I heard, OLT does not use an
XML parsing library to do that but has it all hardcoded. Which means
that support for more recent versions of XLIFF requires a lot of work.
A way to work around that would be to provide SDF filtering for OLT
directly.
Claims of mismatches between PO and TMX files:
My understanding is that this error is reported by users of OmegaT.
Not exclusively. People who manually edit the files have to add the
escapes missing in the TMX as provided by SUN.
Besides, it is not a "claim", it is a fact that the data contents of
the PO provided by coordinators who use oo2po and of the TMX provided
by SUN are not equivalent.
The "claim" is yours when you write below that such mismatching
"should" be properly interpreted.
It is also my understanding that OmegaT doesn't actually interpret PO
files, but only contains functionality to identify / highlight the
different parts of the PO file for translation. I salute the great
work
of the OmegaT community, but if the tool doesn't understand the
format,
the PO/TMX tools can't take the blame for it. To see the PO and TMX
files working well, I suggest people try using a TMX file with pot2po
(either the TMX file provided by Sun, or one created with po2tmx from
the translate toolkit).
Is there an official documentation regarding the PO format ?
The GNU pages do not refer to anything to "interpret" as far as escape
sequences are concerned. The only formal reference there is to find is
to C syntax for character strings, which means the escapes.
But I could not find any part of the GNU gettext manual that says how
PO parsing tools should interpret the format, except as textual data.
Can you give me links to recommanded implementation practices for PO
tools ?
I guess the point of Translation Memory _eXchange_ is the point that
it
should be exchangeable regardless of what it will be used for. If
tools
interpret the escaping differently, that does pose a problem and that
will need to be addressed.
TMX is XML and is parsed with XML parsers.
However, if the issue is that OmegaT is translating PO files as text
files without regard for the PO file format, I don't think we can
lay the blame on the TMX specification or something else.
Are there PO parsers provided by GNU or GPLed that OmegaT could use to
improve its parsing of PO files ?
Jean-Christophe Helary
------------------------------------
http://mac4translators.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
