2016-03-16 21:33 GMT+08:00 Michael J Gruber <g...@drmicha.warpmail.net>:
> Junio C Hamano venit, vidit, dixit 14.03.2016 18:47:
>> Junio C Hamano <gits...@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.
How about this? We can make a website (host on github) to show i18n
changes. Homepage is just a markdown page, list no-merge commits
which introduced i18n changes. So we don't have to change the workflow.
1. A local git clone, keep update with upstream.
2. Give a starting point, and generate a no-merge commit list.
3. Scan through local git clone and generate a pot file for each
commit and its parent commit, and save them in cache (by hard
link to save disk space).
4. Generate diffs for each commit.
5. Generate the MarkDown web page through a template.
6. Commit the changes of the markdown page, and push to github.
--
Jiang Xin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
