I am with you Roman on po thing. It doesn't fit well with all translation work. My pet peeve is "<placeholder> Dialog" string when I was translating en to ru menus, because the word to go in the placeholder has to change in ru from just "<placeholder>" according to language grammar. I also found in po I lose context (e.g. "see previous step" when all po entries are not in order) Anyway, I agree with Nickolay about tracking changes. I wrote a perl script that picks up changes in en as they come. For that to work I needed a extra folder to compare against after svn update and a file to list all .xml files with the last svn revision that I looked at them. Seems to work for me. About new contributors. Is it possible to write a script that, given a language and an xml file/directory, takes all en elements and recreates them with a new language and en text. That way the new guy just searches for lang="his language" and translates en without worrying about xml markup? Once he is done, he turns on his language on the section level. Or is the docbook schema too complex to take care of every case? I also agree 30 languages won't fit in a single file. Vitaly. > > Heh, time to update the patch for xml2po, I'm afraid it won't even apply > > cleanly :) > > > > http://bugzilla.gnome.org/show_bug.cgi?id=369510 > > > > Anyhow, 30 languages won't fit into a single xml file. > Correct and I was thinking again about this issue from time to time. > IMHO the major problem is, that editing the XML scares away new authors > who want to translate the manual. We could split all the files into a > single file for each translation, but that sounds more scary to me, than > using the po approach. > As I already stated, we don't have an English reference (yet). Thinking > of the po approach means, that authors first have to create the English > reference paragraphs (or pages) and translate it. > > But as far as I know (and still knew if I remember the discussion to the > bug), if we use the xml2po patch, than we have to switch entirely to > xml2po. Is that correct? Does the updated xml file use the images > created for that translation? > > We've to make a decision here then. If the authors want to switch to > xml2po, we first need to: > > - set a reference language (which is probably English) > - a migration policy to not loose any of the translations, how do we > deal with special cases (like the glossary, etc) > - a migration date > > I fought always of the against-using-po side, but I'm getting tired of > this discussion. It still has a lot of advantages to gain but I still > fear we're loosing the collaboration, which we thought to have in our > manual, but never worked out very well.... > > Greetings, > -- > Roman Joost _______________________________________________ Gimp-docs mailing list Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
