Re: [ANNOUNCE] Git v2.8.0-rc2

[Michael J Gruber <git@drmicha.warpmail.net>]

Junio C Hamano venit, vidit, dixit 14.03.2016 18:47:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> But if it makes it easier for translations teams and the i18n
>> coordinator to work together if I also pulled the git.pot update
>> myself, I'll do so.  I just didn't know (and still don't know) if
>> that makes things easier for you guys, or if that risks making
>> things more confusing, having to or being able to pull from two
>> trees that are not necessarily in sync down to the minute.
> 
> So, please just tell me to pull it myself too, if it makes the life
> of i18n team and the coordinator easier.
> 
> Thanks.
> 

I don't know about the workflow in general. I'll write up what triggered
my question: I was looking at the FAQ "how do I display the current
branch in git" and into ways to provide some ui (think "git status -sb",
the "+"-line in "git branch"), when I found the problematic output. The
multiple parentheses looked suspicious to me, but given the many levels
of macro expansion I wasn't sure, and simply patching the parentheses
didn't help either. It needed a combination of "make pot" and "msgmerge
...", and the fact that the last merge of git.pot was from 2.7.0-rc
triggered my request to merge what we have.

In hindsight, what happened must have been like this:

"ahead " was marked properly for l10n and translated in the past.

7a76c28 (status: disable translation when --porcelain is used,
2014-03-20) introduced those extra parentheses. Matthieu probably didn't
rerun "make pot" and "msgmerge" so that he didn't notice the consequences.

When Jian ran "make pot" the "ahead "-entry got removed from git.pot:
5e078fc (l10n: git.pot: v2.0.0 round 1 (45 new, 28 removed), 2014-04-19)

When translators ran "msgmerge" with the new git.pot the existing "ahead
"-entry got commented out, for example here for de.po:
74c17bb (l10n: de.po: translate 45 new messages, 2014-04-01)

I'm actually wondering why I didn't notice this much earlier. I don't
know which workflow would have prevented this either. Maybe, since we
have "make pot", we should also have "make l10n" or something to make it
(even) easier for non-l10n-experts to check whether they introduced any
problems.

Strictly speaking, every source file with i18n markup should trigger a
"make pot" (and make l10n) when changed, but there's probably a good
reason why we don't do that.

Michael