2016-03-20 10:45 GMT+01:00 Jiang Xin <worldhello.net@xxxxxxxxx>: > 2016-03-16 21:33 GMT+08:00 Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx>: >> 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. > > 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 I think this is a general question about how to track build products. The proper place may be in a tree that is referenced from a note or so. Maybe I shouldn't consider git.pot a build product - I don't know, as I honestly don't know why we treat it the way we do. I could understand if we don't track it all, or if we regnerate it from "make all" and track the result. We do track it but let it go stale. There must be a good reason for that, it's just that I don't know it. Maybe the problem that I'm trying to solve appears rare enough to not warrant a solution... The question of how to track build products (such as pdf compiled from LaTeX) properly may be a more general one, more deserving a solution.  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