Re: [Rosegarden-devel] Translation against svn

[Pedro Lopez-C. <ped...@gm...>]

On Monday, 25 June 2007 10:52, Chris Cannam wrote:
> On Sunday 24 June 2007 03:03, D. Michael McIntyre wrote:
> > On Saturday 23 June 2007, Heikki Johannes Junes wrote:
> > > Is it ok to update translation in such a way, against svn ?
> >
> > Wait for Chris to answer this, but I *think* so.
>
> Um, I *think* so too.  I say wait for Pedro...

It depends. It may be done with safety... 

> I have just noticed that
>
> svn update
> cd po/
> ./messages.sh
>
> updates all the translations against the current source.

This procedure does several things, summarily:

1. It extracts strings from sources and several resources, using a version of 
xgettext modified by KDE that is included in out SVN tree. Please, doble 
check that the script uses this executable instead any other one installed in 
your system. The extracted strings are used to build a new 
"rosegarden.pot" (the mother of all the translations). The process uses also 
a file "kde.pot" (from /usr/include...) containing strings from the KDE libs.

2. The new "rosegarden.pot" is merged with all the existing translations 
("*.po" files) appending to them the new strings, removing deprecated ones, 
and marking as "fuzzy" some automatically matched pairs. 

If you use this process (with care) to update the translations because you 
want to update your own translation, and then you commit only the updated 
"fi.po" alone, it should be OK. Of course, this will generate a mismatch with 
the number of messages of other translations, as shown by "scripts/po-stats",  
but this may be fixed later.

The problem comes if there are some people working on other translations and  
you commit the whole set of updated "*.po" files. Their local working copies 
become outdated. With program sources, Subversion does usually a good merging 
job, and when it fails the programmer usually knows how to solve the 
conflicts. On the other hand, a conflict in .po files is harder to manage,  
and it may be confusing or even unattainable for a translator.

IMHO, we should follow a serious release plan, then declare (with enough  
anticipation) a "string freeze", and then use the "messages.sh" program to 
update and commit the whole set of translations. After that, announce the 
update to the translators team, and avoid doing another mass update before 
the final release. 

Regards,
Pedro