Hello Nickolay and All - I looked at the URL you cited about gettext. Since I have some previous exposure to the "message catalog" method, and since I've been peeking at the Gimp sources, it was not a complete surprise to me. Thanks again for the good resource. >In short, translations are committed to special text files in po subdir >and later merged into the source. When source is updated, po files can >be updated. New strings will be marked for translation and strings that >changed a bit will be invalidated. I see it as a real advantage, if changed lines in the English are automatically flagged in the .po files. But there is a caution. In doc files in particular, since they are more often in the form of paragraphs than short phrases, arbitrarily moving the line breaks (to fit within the max chars per line) would automatically flag all the translations as invalid, as would minor changes in xml tags or punctuation. >Until translator will update the po file, this paragraph >will simply hide. No need to mark revisions and worry about versions. Hmmm. I don't know if this is a good thing or not. English changes a single word in a paragraph and the whole thing disappears from the help files and web site until somebody fixes it in each language? It would be better to have a broken paragraph displayed than a "hole" in the middle of an explanation, I think. Axel said: >this looks to me like the birth of translation slaves. I don't like >slavery. I understand. I think Gimp docs have always allowed a certain amount of translator discretion. But the alternating paragraphs of the current docs do sort of follow this scheme, anyway, don't they? >You completely loose the context of what you are doing. Just single >lines of text to be translated without a context. The Clock example showed some whole paragraphs, not just single lines. And as for the context, it's certainly no worse than the current alternating paragraphs system. >What about images that are language specific. I see this as potentially being more of a difficulty. If the translator has to edit the xml file, as well as the po file, to deal with the picture -- then he's *really* likely to lose context. :-) Bill said: >I have always favored splitting the various languages into separate >files, because I couldn't imagine hand-editing an xml file with, say, >20 languages all mixed together. As long as I was editing the menus/ files with usually just en, de and fr, it wasn't too bad. Now that I'm looking at concepts/ with far more languages that that, even *I* am having trouble keeping the context. Since I don't build the files, they're always a surprise and a delight when I see them on the website. And I've often been surprised at how little English text some of these files actually contain! With all of the languages, it's hard to keep that perspective. Nickolay said: >current GNOME documentation is developed this way, it's also very huge. If there's already a doc project done this way, where can we find it? (OK, maybe everybody else knows the answer except me!) It would seem that we could at least look at how good or bad that one is. Regarding XML and PO hurdles, the translator would have to know both syntaxes, so he could edit the PO and also add XML tags (not to mention possibly updating the XML for images.) Pro: perhaps many translators already know PO format. Con: PO format may be fairly simple, but it's not just a straight text file, either. As Axel said: >as I see it this is a topic which is not solved within a couple of >posts. Before changing our technology we should consider the pros and >cons very carefully. True, I don't think it's a simple matter of "let's just accept Nickolay's files and check them in and start using them tomorrow." OK, this is an open source project and nobody really makes a top-down decision. But I'd still like to hear from Roman. Regards, Sally _______________________________________________ Gimp-docs mailing list Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
