Junio C Hamano venit, vidit, dixit 14.03.2016 18:47: > Junio C Hamano <gitster@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html