[Gimp-docs] Structural changes - gettext?

Joao S. O. Bueno gwidion at mpc.com.br
Tue Jun 3 06:18:59 PDT 2008


Hi Roman, and everyone.

Sorry for not commenting here earlier. I've been  at poland where 
Roman took the decision to change our trasnaltion proccess. 

I Surely welcome teh change. We have not been able to start a pt_BR 
version of the manual dual to the entry barriers cited before. (i.e. 
dealing with files with several languages)

The new system will separate the docbook files in several .xml files, 
and the current plans are using the egttext tool chain to make it 
possible to translate a master file in the reference language 
(English - any other would not make sense, since this is the common 
language to all trasnaltors/authors) to other langauges. As far as I 
know, te system that is easier to be put in place will then just 
convert the .po files tarsnalted in this way back to .po files.

But, in fact, there are more drawbacks in using gettext and .po's than 
just having a master language. The major  of them seens to be the 
need of an in order,  paragraph by paragraph translation that might 
not always be the best possible translation - and simply take too 
much freedom away from the translators.

However, if the gettext system generates xml files from the PO's for 
the other languages as  part of the build (Roman, can you confirm 
that?) I thib k that soon after we change the structure, we might 
figure out a tool chain to bypass the gettext->PO->xml steps, and do 
a en.xml -> target_language.xml translation that could preserve most 
of the freedom that existed before the change. We will need, for 
example, an editor that enables editing the [.en and target language]  
XML files side by side we could be better than using plain gettext.

Note that a  necessary step is the spliting of the files into diferent 
languages and the adoption of a "master language".  But in doing 
this, some freedom would remain, and the process of trasnaltion 
itself would flow better. Most .po editing tools only allow the 
transaltor to see one paragraph at a time, which, as Kolbjørn noted, 
is very inconveninent for translation. Editing the.PO file sin raw 
would have the inconvenient of requiring the translator to place teh 
quotes in eery line (for most editors). So we'd require a custom .po 
editor, and still be bound to the order of the paragraphs. Using 
straight XML for the translations would most likely require a custom 
editor anyway, however a lot of good editors  allow one to split 
windwos so he can see the two files at once - but most importantly, 
would not bind the tarnsaltors to the paragraph order.

This doe snot prevent us from first, changing the structure to a chain 
requiring gettext (because such a change might be easier to do), than 
on a second moemnt finding/creating an apropriate XML editor taht 
would allow us to bypass gettext->po, and work with a xml->xml chain.

What do you think?

	js
	-><-


More information about the Gimp-docs mailing list