On Tue, Jun 03, 2008 at 10:18:59AM -0300, Joao S. O. Bueno wrote: > 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 was not away but I am late too.... > 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. Yes I agree. > 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. This drawback does not exist (IMHO) since a gettext string could fit easily more paragraphs at a time. If you go and look at the manual structure, for the largest part of it there _is_ a strict correspondence between the english parargraps (or grouped paragraphs) and the other languages sections. > 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 think 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. That freedom (IMHO) is not necessary nor desiderable. > 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. kbabel, poedit or even emacs in po-mode have planty of options so useful for translating that I really do not understand why should be desiderable to translate xml instead of po files... > 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. Kolbjørn (sorry hope this do not offend Kolbjørn) is not really aware about the workflow of gettext so do not take him as an example... > Editing the.PO file sin raw would have the inconvenient of requiring the > translator to place the quotes in every line (for most editors). Not .po files editors...and consider that using plain .po files you (potentially) open the door to much more friendly translation tools like rosetta or pootle > So we'd require a custom .po editor, and still be bound to the order of > the paragraphs. mmm I still think we do not need a custom .po editor... > 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 translators to the paragraph order. poedit, emacs, kbabel have all the possibility to show the piece of code that the string refers to...this shouldn't be enougth? > This does not 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 that > would allow us to bypass gettext->po, and work with a xml->xml chain. mmm > What do you think? I think that we should concentrate on how to ectract .po file from the xml to re-merge the strings onto the main .xml files. Using the .po files is _much_ more powerful and then we should consider only the problem(s) that refers to this approach. One real problem could be that a single correction in the english strings (a missing comma for example) invalidate (fuzzy) many languages strings. And the default behaviour is to use english when a string is fuzzy or missing. A solution could be to: 1. do not use the english strings when the string is missing but leaving simply a marker that eventually points to the english version to the paragraph(s) or using the default behaviour ... here I would like to know how you all think about this... 2. fuzzy strings are considered as missing and _this_ could be really a drag. One mechanism for avoiding this could be to consider fuzzy strings or all fuzzy strings older than, say 3 or 6 months, as valid for conversion in html. What do you think? -- Marco Ciampa +--------------------+ | Linux User #78271 | | FSFE fellow #364 | +--------------------+ _______________________________________________ Gimp-docs mailing list Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
