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

Re: 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 16:25:10 +0100

On Wed, Mar 18, 2009 at 03:54:58PM +0100, Arfrever Frehtes Taifersar Arahesis wrote:
> 2009-03-18 10:55 Jens Seidel <jensseidel_at_users.sf.net> napisał(a):
> > On Tue, Mar 17, 2009 at 11:13:19PM -0500, Hyrum K. Wright wrote:
> >
> > 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
>
> It was fixed some days ago in trunk.

Ah, good to know.
 
> >    $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).
>
> I prefer `svn di XX.po | less` in another terminal.

This works only if you are able to translate all new fuzzy strings at once
after updating the PO file. What if you want to update the file (or parts of
it) later? You have to dig into the history, use svn annotate, ...

--previous is the official and standard way to solve this kind of trouble.
It is supported by multiple graphical (and text based) PO editors, it
doesn't require access to the repository and it works offline. Sounds bad,
indeed.

Do you really want to force all people to follow your current work flow?
You can continue using "svn diff" even if some comments were added, right?
 
> > 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).
>
> pl.po before r36624 intentionally contained some strings present in the future.

And these strings are not lost. They can still be found as special comments at
the bottom of the file and will be automatically reused once they occur
after syncing with the source via po-update. Right?
 
> > 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?
>
> I don't see benefit in .po files with bigger number of fuzzy messages.

It clearly shows that there is work to do without comparing with the source
code and calling update-po again (which many people are not able to).

I don't see benefit in shipping outdated files, do you? (OK: one benefit:
the repository history is cleaner and backups of the repository are smaller,
but how often happens a release?)
 
> Please don't change pl.po in the future.
 
So you don't care having untranslated strings just because a typo in the
source was fixed and this wasn't unfuzzied in pl.po? Such as
s/effecient/efficient/ in r36585?

They priority should not be your ego but the users!

Jens
Received on 2009-03-18 16:53:42 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.