[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Translation stuff to do before a release (Was: Re: svn commit: r36625 - in branches/1.6.x: . subversion/po subversion/svn)

From: Jens Seidel <jensseidel_at_users.sf.net>
Date: Wed, 18 Mar 2009 10:55:20 +0100

On Tue, Mar 17, 2009 at 11:13:19PM -0500, Hyrum K. Wright wrote:
> We are asking you to trust the rules of the community, and if there are
> inefficiencies, to help us find and correct them. For instance, would it
> be possible to script the merging of translations to the release branch?

This code exists already: It's mentioned in TRANSLATING:
"Maintenance on branches". This is not optimal as it mentions e.g. the
po-merge.py script but doesn't use the full paths in the example command.
Normally it is something I would just change but I always hesitated because
I don't have permission (OK, it's an obvious fix, but once I start updating
I'm not willing to stop until everything is perfect) ...

Merging translations is indeed not trivial but there exist tools such
as msgmerge (from the gettext package). I don't know why po-merge.py exists
and suspect it is just a msgmerge replacement for Windows people.

This po-merge.py gave me the last day the error message:

1.6.x/$ svn cat http://svn.collab.net/repos/svn/trunk/subversion/po/de.po |
tools/dev/po-merge.py subversion/po/de.po
Traceback (most recent call last):
  File "tools/dev/po-merge.py", line 171, in <module>
    main(sys.argv)
  File "tools/dev/po-merge.py", line 160, in main
    for m in msgstr:
TypeError: 'NoneType' object is not iterable

This needs to be analysed (and the script should be moved into tools/po/).

I used the following workaround (the non-trivial task, but every translator
should know at least the basic gettext commands) (in 1.6.x/):

$ svn revert subversion/po/de.po
$ tools/po/po-update.sh de
$ cp subversion/po/de.po subversion/po/de.po.updated
$ cp ../trunk/subversion/po/de.po subversion/po/
$ msgmerge -U subversion/po/de.po subversion/po/de.po.updated

Using the -C (compendia) option may be useful as well, to reuse strings
available in the release branch but absent in trunk.

All this should be done by po-merge.py and it worked in the past.

The document (TRANSLATING) misses also information about the new environment
variable SVN_LOCALE_DIR (I tested it with
export SVN_LOCALE_DIR=/home/jens/local/subversion1.6.old/share/locale/
and it worked well finding the translations after I moved the installed path
to ".old"). I also noticed that current i18n tools/scripts
assumes very old gettext versions. Example:
tools/po/po-update.sh:
    # In a display of truly bizarre behaviour, msgmerge (at least, the
    # GNU gettext-tools 0.14.6 implementation) inverts the order of obsolete
    # messages every time it is run. Therefore, run it twice, to invert and
    # then re-invert, to minimize spurious diffs.
    $MSGMERGE --sort-by-file --no-wrap --update $i subversion.pot
    $MSGMERGE --sort-by-file --no-wrap --update $i subversion.pot

A single call to $MSGMERGE should be sufficient and I would add the
--previous option (new since 2(?) years), as this adds information about
what changed to make a string fuzzy (so that the translation is outdated and
not used). This --previous option adds special comments which need to
be supported by some python scripts (because it's a reimplementation of some
gettext tools).

OK, this needs to be properly explained/tested/... and I should provide a
patch, I know.

But at least you can add the following to the release preparations:

Bring PO files in the release branch in sync with source (to match all
strings from source and not only the strings as present many years ago).
This can be done using
$ tools/po/po-update.sh

This is useful so that the final tar-ball ships current PO files. This are
made available to the world of translators by the Subversion repository
(or just a web frontend) but also by pages such as
http://www.debian.org/intl/l10n/po/de

And you don't want such pages to contain completely outdated files, right?

This is what I did in

r36624 | jensseidel | 2009-03-17 14:59:34 +0100 (Di, 17. Mär 2009) | 19 Zeilen

Update source references in PO files (no changes to context). This is useful
as some distributions (e.g. Debian) publish these released PO files and most
people don't try to update these themself and sometimes wrk on outdated files.
msgfmt gives now also proper statistics.

* subversion/po/pt_BR.po,
  subversion/po/es.po,
  subversion/po/fr.po,
  subversion/po/de.po,
  subversion/po/sv.po,
  subversion/po/ko.po,
  subversion/po/ja.po,
  subversion/po/pl.po,
  subversion/po/zh_TW.po,
  subversion/po/it.po,
  subversion/po/nb.po,
  subversion/po/zh_CN.po:
  Call tools/po/po-update.sh to sync PO files with the source.

Also add to the release preparations *at least* one call to translators
requesting updates and try to avoid changing strings during the live time
of a branch (or at least inform translators if it was necessary to change
something!).

> If so, it is something the RM could do prior to each release, thereby
> freeing translators to work on other things.

Updating PO files and sending update requests to translators can be done
by the RM.

> Anyway, I reverted r36625 on the release branch in r36647.

OK. Once you will revert it, revert r36647 and not the previous attempt
r36214 (I wasn't aware of it) as this missed the translation update.

Jens
Received on 2009-03-18 11:19:47 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.