[Gimp-docs] Current status on migration to gettext/po

[Roman Joost]

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 at gimp.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /lists/gimp-docs/attachments/20080825/1aea38c4/attachment.bin