Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Chris Cannam <cannam@al...> - 2007-06-25 08:51:38
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...
From: Pedro Lopez-Cabanillas <pedro.cabanillas@gm...> - 2007-06-25 15:37:36
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/
> 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.