Structural changes - gettext?

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

 



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	-><-_______________________________________________Gimp-docs mailing listGimp-docs@xxxxxxxxxxxxxxxxxxxxxxxxxxx://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs

[Index of Archives]     [Video For Linux]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [Scanners]     [GEGL]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]     [Webcams]

  Powered by Linux