[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stary, Tomas
Subject: Re: [ESD-translators] state of the template manager -- kitchen
Date: Sun, 27 Mar 2016 09:15:59 +0100

Hi Thérèse, everyone,

I'm new in the translations, so I don't exactly know how does it work
in other projects.

The system you suggest seems quite convenient to me. If I understand
it correctly it can not only deal with the text repeated on multiple
pages, but also addresses the updates in the original page, which
would be great for the translations of the future updates of the
original text.

Is it an automatic procedure to generate the POT files for the
project? I have found that xgettext can be used to get the strings to
be translated from the programs source files, but xgettext does not
support html.

In my previous comment I was only the concerned about the text
repeated on multiple pages, which complicates the translation and
corrections of translated text.

In my naive view this could be solved simply by splitting the
documents into a number of template pages based on the criteria of
text repetitions. The template files could be then concatenated
together to generate the target page, such that the files with the
repeated text would be reused.

I would probably choose to do this task using Makefile script as it is
what I am most familiar with. However, regarding the splitting into
template pages, I can only think of a manual way of doing it.



On Wed, Mar 23, 2016 at 11:35:08AM +0100, Thérèse Godefroy wrote:
> 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 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's translation system) a
> baby brother? WDYT?
> Best,
> Thérèse
> [0]
> [1]
> _______________________________________________
> ESD-translators mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]