Hello Nickolay, Marco and All - > Probably you would like to read about gettext and po files > http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC161 Thank you! I'll take a look at it. I've been very curious about po files. I discovered them in the Gimp (C) source code tree and found them to be a great source for the exact command names and keyboard shortcuts, without having to start up Gimp and find the thing in question. It even works for finding foreign commands. :-) >For you as a content writer the tools will include only editors, >translators will use editors too, but will benefit from using many >translation tools like KBabel and poedit. Sounds good for me ... >1. Unexperienced content writer will checkout docbook from CVS, edit >files and send patches to experienced content writer. The same way as >now >2. Experienced content writer will accept patches, validate them and >commit. ... and other content writers, but ... >3. Unexperienced translator will checkout po files from CVS, translate >them in text editor and even in web-based tool like rosetta >https://launchpad.net/rosetta >4. Experienced translator will install python and libxml2-python, will >create po files, will add content and mark some sections for translation >with lang attribute. Will accept patches for po file and after >validation of the result will commit them. ... isn't this more work for the inexperienced translators? And a *LOT* more work for the experienced translators? And what if there is no experienced translator for a language? I just don't want to make it more difficult for the new translator of a "new" language to start to work. We shouldn't set the hurdles too high. (Though maybe xml is a pretty high hurdle, to begin with. :-) ) I have been concerned as I make changes to the English, though, that the languages which already have translations in my new file might not revisit it again for a while. I hate to mark every English paragraph with a revision date, but it almost seems necessary. From what I understand of your proposal, that might be a lot easier?? Now, regarding the glossary: >1) has not he same first letter than in english, so the order is different >2) sometimes a technical term exist only in one language >3) there was terms better explained in different languages than in english Even in the English files I just worked on, the English terms didn't seem to be in alphabetical order in all cases. I just left them that way for now. >The first problem could be resolved keeping the english definitions as a >reference, as I tried to propose in an old message, with the help of a >special xml tag like gloss_term_letter="f" (perhaps in a special comment) >and with the help of some (python?) scripting to compile a nationalized >glossary, ordered by that foreign letters. In my recent edits, I saw some MARK comments that already existed. They are at the top of the English definition and point to the definition in other languages, if they're not together with the English one. I added the MARK comments for *ALL* the other foreign terms, but it's not likely to stay up to date. And that isn't really a good tool for having an automatic script come through and re-order everything. >The second is simple. Erase the terms that exists in just one language or do >not exist in english. Perhaps this problem do not apply since such terms >does not exists in the glossary right now. Well, if doesn't exist in English, perhaps it should! I don't think I'd want to *exclude* all new definitons. But the proposed new term (and a rough translation of it to English) could be sent to an English editor for inclusion in the English text. (BTW, I just added new terms to the glossary: tile and parasite. :-) ) >The third is just a matter of asking the translators to contribute in the >english version of the manual. If they fear to write bad english, no >problem: some native english writer will apply the corrections. That works, too. Like you, I wish there were some way of keeping the terms together for all of the languages and sorting them alphabetically for each language when the files are processed. But I'm not prepared to write such a thing. :-( Anyway, we seem to be discussing two topics here, although they are related. Does anyone else have any input? Best, Sally _______________________________________________ Gimp-docs mailing list Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
