Hi Ulf, On Mon, Aug 25, 2008 at 08:42:00PM +0200, Ulf-D. Ehlert wrote: > Roman Joost (Sonntag, 24. August 2008, 15:22): > > Would that actually speed things a little bit up in comparison to > > merging the translations for every single po file? > > It would speed up translating. Okey - we should keep this in mind. I wonder how we will do this. This would certainly mean that we need to put the chapters into their own single files. Currently it's mostly split into sections... But I think this could be done after the migration into a cleanup process. There is one point still open though, the integration into autoconf of the Makefile. Ulf - you put a lot of effort in the Makefile. Do you think you could spent a bit more time on this? If you want to discuss this topic further, I think it'll make sense to do this in another threat. > > I spend a few hours on figuring out a possible solution to save the > > translations by studying various sources (Nickolays proposed patch > > (bug 369510), the Mail conversation with Ulf who already had a look > > at xml2po and xml2po itself). > > [...] > > > > The foo.po now contains the english original msgids and the German > > translation. Did someone tried this actually? Ulf maybe? > > Yes, I tried it for a sample file. It worked like expected, but ... > > > The only problem here is (of course), that the generated po file > > doesn't map 1:1 to the English original strings. This needs to be > > corrected by the author itself. > > That's the problem! > My sample file contained e.g. the following index entries: > > <indexterm lang="en"> > [...] > <indexterm lang="de"><primary>...</primary></indexterm> > > "en" and "de" don't match, and "xml2po -r" produces more or less useless > output. Yeh - I know. > Misssing sectinfo (revhistory) entries will certainly cause similar > problems. > > So IMHO we had to add one more step: > > 0. Check and edit every single source file... We have to do this manually unfortunately. There is no better way around this IMHO. A program would also only be able to just guess. Let's face the advantages: we do have some time for clean up ;) How do we want to proceed? Do the authors (please yell know ;) want to do a migration for themself, using a small script or should someone of us (Ulf or me probably) should do the migration? If no one of the authors votes for step 1, than I propose a migration using step 2 the next weekend. We do need a fixed date anyways, where we start the migration. That means, that after the date only the work and the cleanup on the po files continues. It's probably a good time to do another release before the migration (which would be 2.4.2), so we can start documenting GIMP 2.6 after our release and our cleanup (which would be 2.6.0 probably). But that's future sound... Cheers, -- Roman Joost www: http://www.romanofski.de email: romanofski@xxxxxxxx
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Gimp-docs mailing list Gimp-docs@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-docs
