Re: [ESD-translators] state of the template manager -- kitchen

[Thérèse Godefroy]

Hello Stari, hello everyone,

Sorry for taking so long.

Le 18/03/2016 13:01, Tomas Stary a écrit :
[...]
>>> 1. do you translate the templates or the html files directly
>>
>> Right now, it is probably better to translate the html files directly,
>> but I also tried to use POs and that works. I made one big POT file with
>> all the strings in it, and regenerated all the pages from it with
>> po4a-translate. This method may be more convenient for new translations.
>> And for old ones too, once the translations are converted. I'll post it
>> here if anyone is interested.
>>
> 
> I would definitely be interested to know about anything which makes the
> translation of repeated text more automatic (kill-yank is boring and
> prone to errors).

This is one of the problems that needs to be addressed, but there are
several more:

* The language list is not standardized at all right now, as pointed out
by Zak [0].

* We don't have access to a test server anymore [1]. As a result, we
need to be extra careful with HTML tags.

* The format of the English version, with all those divs, tabs, spaces
and line feeds (or lack of them) makes it difficulty to identify paragraphs.

Switching to the PO system could help. I have a feeling that many ESD
translators are familiar with it, from gnu.org or otherwise. Here is the
principle, for those who are not.

POs are catalogs in which each original string of a document is followed
by its translation. The workflow looks like this:
- extraction of the English strings from the HTML is done by a script;
- the translator fills up the blanks;
- the translated page is generated by a script from the PO and the
original HTML;
- after an original string is modified in the HTML, the modification is
merged into the PO by a script, and the affected string is marked fuzzy;
- the translator fixes the fuzzy string without looking at the rest (if
a new string is added, it will be conspicuous in a PO editor).
- the updated translation is regenerated by a script.

Here is how it would help us:

* As mentioned before, a single PO can be used to generate all the
pages. For us, it would be equivalent to a templating system since each
string appears only once. The PO is rather big, but index.html accounts
for more than half of it.

* The language list doesn't need to be in the PO. It can be added
separately after the translated page is regenerated, and even customized
with the "current" class.

* There is be no need for a test server, since the translated page has
exactly the same structure as the original page.

* A comment above each original string shows which tag it comes from
(<p> or <li> for instance). Thus paragraphs are pretty well identified.

As you see, the only thing the translator does is translate. But there
is a cost:
- The original has to be strict XHTML (right now it is, and there are
automatic ways to make sure it stays that way).
- The PO format is rather strict (but PO editors take care of that).
- Any small change to an original string will make it fuzzy, even an
extra space.
- Conversion of an existing translation to the PO format can be rather
tedious if its structure doesn't exactly match the original. But this
happens only once.
- The extra tabs, spaces and line feeds shouldn't matter, but in fact
they make regeneration of the translated page unreliable. I use a script
to standardize the original HTML; it also makes it a lot more readable.
This script could be run systematically after each change.


To sum up: do we need to give GNUN (the gnu.org's translation system) a
baby brother? WDYT?

Best,
Thérèse

[0] http://lists.fsf.org/archive/html/esd-translators/2016-02/msg00011.html
[1] http://lists.fsf.org/archive/html/esd-translators/2016-02/msg00005.html