RE: [Freecats-Dev] early proof of concept implementations?

[Henri Chorand]

Hi,

> Summary:
> 1. Need for 'quick n dirty' implementation for translators to get going.

Sure.

A few weeks ago and after advice from Thierry Sourbier, I suggested a tagged
bilingual document file format derived from the .TMX format and that seemed
much in line with what Yves Champollion is doing with Wordfast.

The best solution seemed to me to implement this file format, but as long as
we've got nothing to put behind, there is no practical use.

Also note that Keith developed his own bilingual file format, but I don't
remember he provided its specification - a Java developer would be needed to
extract the relevant info in OmegaT's source code.

I wish it could be done rather soon, as it would enable us to examine both
options and probably to merge the two of them into a "best of breed".

I have to admit things have not gone far in this direction, and I must add
that I myself am very eager to provide specifications that would enable a
developer to quickly add a set of various resource file formats (.po Linux
resources, and also .rc / .h Windows resources, .hhp / .hhc / .hhk HTML Help
resources) into... well, into OmegaT framework.

I believe everybody will agree that once we have published such a bilingual
document file format, many developers will be able to add conversion scripts
in order to allow translators to localize various file formats. We
definitely need to see such a standard emerge. If if does not happen, it
means duplicated (wasted) efforts. Once it's done, the more conversion
filters are made available, the better for all of us.

Last, I consider that building these filters is not a very difficult job, at
least for all the resource file formats mentioned above (and similar ones),
and when compared to word processor & DTP documents.


> 2. Use scripts for this, keep work under FreeCATS ombrella.

As it is now, Free CATS definitely seems a good umbrella to coordinate work
between various teams working on different parts of the modular solution we
hope to see.


> 3. Get blessing/advice/feedback from this list.

Sure. See above.


Can anybody provide more details about OmegaT's present bilingual document
file format in order to allow developers to build up conversion filters?

> (...)
> An issue that is currently unsolved is how to maintain consistency
> between updates of the original document. One way to do it is to
> attach with the translated document the original document that it
> was based from.
> Thus, if changes in the original document take place, then they
> can be traced back through the different versions of the 'master'
> (english) document. Some advice on this would be appreciated.

If a translator works with a CAT software and an up-to-date translation
memory, then each time a new version of a given file is to be translator,
he/she will translate this new version with the help of the TM. The
translator will then be able to automatically retrieve existing
translations, edit them if necessary and add new translations, with the help
of fuzzy matching (so that if a string is slightly modified, he/she will
naturally produce a new translation based on the previous one).

This is how CAT presently works: as a flexible, assisted, interactive tool.
You don't need to implement a specific version control mechanism, but you
still need to review the whole document each time changes (even minor) are
brought.

You will also understand that you must not mix everything in the same TM,
but that you need to strictly define a TM's domain and stick to it, whether
for a small (e.g. Notepad) or a larger (e.g. Gnome, KDE) software
localization project.


Cheers,

Henri