Re: [PATCH 0/9] i18n: add PO files to po/

[Jonathan Nieder <jrnieder@gmail.com>]

Ævar Arnfjörð Bjarmason wrote:

> It's been a long time coming, but here's an initial submission of PO
> files to the po/ directory. This adds some initial and as of yet
> unused translations.

Neat.  I think it's good to figure out what we will do with these
anyway, and we don't have to wait for the infrastructure to do that.

So, basic questions:

 1. which branch will be translated?
 2. who keeps track of incoming translations?
 3. how can we avoid this making "git log -p" output unusable?

Some strawman answers:

1. I have two ideas (each pretty different from the other).

    If the gettext tools provide a way to take a union of po template
    files, it would be possible to keep the union of all maintained
    branches translated.  In other words, when a message changes,
    until that change propagates to "master" or "maint", translators
    would be able to translate _both_ the Before and After versions.

    Otherwise, I'd say, it's simplest to only take ordinary
    translation updates through the "master" branch (and to update
    translations of "maint" when important fixes come).

2. If there is a git-i18n.git tree, Junio could pull its "master"
branch from time to time.  An i18n coordinator could even take
advantage of zealous translators that want to translate topics in "pu"
if wanted, without having to bother Junio until it is time to pull the
cooked translations from 'master'.

3. Maybe some hero will implement

	git log -p --exclude=po/
	# or
	git log -p -- :(not)po/

to complement "git log -p -- po/". ;-)

If you wonder why I'm asking these questions, it's because I have
noticed that normal branching practice (fixes rippling up from more
stable branches to less stable ones) can fall apart in projects with
translations, since there is no tool that I am aware of that works
like rcs merge to combine changes.  Hence question (2), which puts the
burden to get things right on some other person who can experiment to
find a workflow that works well. :)

Two interesting patches (#2 and #9) didn't hit the mailing list
archive, probably because of length limits.