On 11 juil. 07, at 15:29, Arthur Buijs wrote:
The overhead of using po-files in the translation process is minimal
(exept from the initial trying out).
It is not when you have to modify the tagged links to fit the source.
In OmegaT that is done automatically without you even noticing it.
Also, all the <emph> tags, if they need to be displaced or edited,
require more work in a text based editor than in OmegaT (if done the
way I suggested).
Of course, using the PO files in a PO editor or in OmegaT will not
make much difference in terms of editing the matches. The problem
_is_ which source file you choose to work with and what relation they
have to the original format (here: HTML->SDF->PO, almost no relation
anymore when you reach the PO stage.)
So I am really talking about not using PO because _that_ requires to
handle the files at text, while using the modified .sdf allows them
to be handled as HTML (which does considerably reduce the amount of
editing).
Ofcourse this is only true if a
useable tmx-file is available. My advise would be to find a better way
to generate tmx-files and use po-files for the translation-task.
The TMXs provided by Rafaella were similar to the ones provided by
the translate-toolkit processes (oo2po -> po2tmx) and neither
corresponded to the source po file in terms of number of "\"
characters for the escape sequences. They corresponded to the
original .sdf file, which is what originally prompted me to use the
original .sdf file as source. The rest of the hack I proposed on the
7/7 comes from that.
The general problem does not only come from the TMX, but from the
fact that .sdf is already an intermediate format (that you then
convert to yet another intermediate format -> po).
The original conversion requires escapes and _that_ is what requires
the files to be handled as text when they could just as well be
handled as pure and simple HTML which most translation tools support.
The TMX problem is yet another problem.
Here, we have the following structure for the TMXs:
(new source segment)
(old target translation, if present)
A _real_ TMX should be:
(old source segment)
(old target translation)
So the current process is very confusing and does not allow TMX
supporting tools (like OmegaT or even OLT) to fully leverage the
contents of the source. Which is the real function of the TMX file.
Plus, the fact that the TMX do not reflect the structure of the
actual source file (PO) makes them yet another problem.
Of course, I am commenting on the process only with the perspective
of allowing translation contributors to have access to a translation
workflow that supports the use of computer aided translation tools.
Right now the process that is suggested by the file formats available
for OOo's localization does not facilitate this at all.
Another of SUN's project, namely NetBeans, manages to fully leverage
legacy translations thanks to the use of simple source file formats
(the UI files are simple Java properties and the Help files are
simply HTML) and the whole source files are matched to the legacy
translations output to TMX for super easy translation (in OmegaT or
any other TMX supporting tool, even though OmegaT is the most used
tool there).
As long as OOo sticks to intermediate file formats (.sdf/.po/.xliff)
with the current unstable conversion processes, hack will be
necessary to reach the same level of efficiency other communities
have already reached. And _that_ is really too bad.
Cheers,
Jean-Christophe Helary (fr)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
