Ain,
So the question you seem to have with xliff:
On 19 janv. 07, at 19:48, Ain Vagula wrote:
> By the way, I noticed that xliff files are stored in packed format,
> xlz? It
> means that when using xliff as only intermdiate version, without
po-
> step,
> you'll not have any overview over changes in version control
system?
> Its only a question, not statement - I dont know almost anything
about
> deeper mechanism of version control.
Is basically: can we have the same level of vc information with xliff
files than with po files ?
(besides for the fact that OLT's xlz is not representative of
standard xliff files).
I don't know what is technically necessary in the current back-end,
but basically po and xliff are formats with the exact same purposes.
I'd say the only difference is historical: po came with GNU and
gettext while xliff came from the localization industry and XML and
is also much younger but integrates much better in xml workflows.
Sorry for misunderstanding what you meant by version control here. My
idea is whatever localization format you use it will be easy to
integrate it in the back-end, so we should not consider ourselves
limited to "only-po" or "only-whateverelse". But I fear that in the
long run, sticking to po will not contribute to improve the whole
system.
To me it would make much better sense to use a "vendor-neutral"
version control system where the controlled output file is the
closest possible to the original file (be it sfd or anything else the
process uses internally) and provide a number of "end-user" filters
to ease the life of would be translators: some would translate the
raw files, some would convert that to po for use in their po tools,
some would convert that to xliff etc...
So that we'd have a team leader who handles all the commits etc and
packages the data for the team according to the procedure the team
has chosen.
Whatever form this vc system takes it should be able to also output
"combined" updated packages on which to build reference glossaries
(CSV or TBX for ex) and translation memories (CSV or TMX for ex) by
automatically aligning the committed files.
The few FOSS I participated to have all very good vc systems but very
poor translation memory/glossary management, which means that the
translator usually has to find reference the hard way. The computer
aided translation tools that exist on the market today (FOSS or not)
don't seem to be fully used in most FOSS projects which means that a
lot of QA has to be done, and re-done and done yet again because
translators can't fully leverage older translations.
Jean-Christophe
VC is fine for some processes but I think it is a little too much for
our purposes. As long as you have past documents stored as
translation memories (TMX) you don't need to have VC at all anymore
(at least if you mean VC the way I mean it). If your text has already
been translated it will be there in the TMX and either you have a
system to automatically update it or you do that manually.
There are a number of issues related to TMX: do we store everything
as sentences, or as paragraphs etc. And if we leave translators free
to use the process they want, how do we guaranty that they deliver a
TMX with the final document.
That is where XLIFF comes in: as long as the delivered document is
XLIFF it is trivial to extract a TMX from it for recycling in the
next translation. etc.
Sorry, I think as I type and maybe that was not the kind of answer
you were looking for.
I mean version control as CVS, SVN etc. We keep currently po-files in
CVS repository. When someone with write-access commits something to
CVS, system automatically sends a notification with full diff to
projects cvs mailing lists. (po-format is very easy readable) So is
easy for all members to have overview whats happening, also it is easy
to write comments or questions about commits, reply to comments and
make proofreading immediately after commit.
This is the way how all free software projects where I participate are
functioning.
ain
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
