В Птн, 22/09/2006 в 10:55 -0400, Sally C. Barry пишет: > Hello Nickolay, Marco and All - [snip] > > >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?? > I don't think so, translators are happy and very familar with their tools. For new language, one should just submit a new po file and make some corrections. Newbies for example can just use web site, much easier than editing docbook xml :) PO files are easier to review, so if there is no translator that can validate result, we can always ask gnome language team to look through it. That's all they are doing anyway. After that, po file can be committed as usual. About changes, when you change something in English, po files will be updated and translator will see that some message is changed and will update it too. Until translator will update the po file, this paragraph will simply hide. No need to mark revisions and worry about versions. > 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? > I am for the third way :) About sorting, I think it's docbook-xsl bug, glossary terms should be sorted and probably it's possible to make them sorted with little stylesheets tuning. We'll look later > Best, > > Sally > > _______________________________________________ > Gimp-docs mailing list > Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
Attachment:
signature.asc
Description: =?koi8-r?Q?=FC=D4=C1?= =?koi8-r?Q?_=DE=C1=D3=D4=D8?= =?koi8-r?Q?_=D3=CF=CF=C2=DD=C5=CE=C9=D1?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=C1=CE=C1?= =?koi8-r?Q?_=C3=C9=C6=D2=CF=D7=CF=CA?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=D8=C0?=
_______________________________________________ Gimp-docs mailing list Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
