Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
> echo '*.po diff=po' >>.gitattributes
> echo '*.pot diff=po' >>.gitattributes
> git config diff.po.textconv "msgcat --indent --no-location"
>
> With or without the indent, that gives a pretty clean diff. [It's
> unfortunate that one half of that config is in-tree, one-half is not.]
That's a good tip. [By the way, it is not unfortunate that these are
separated to two places, but quite the opposite. Attributes define
"what kind of things" they are, and configuration defines "how" each
kind of things are handled. "msgcat" may have to be invoked
differently from yours on other people's systems, and one level of
indirection is a reasonable way to allow customizing "how" part
without forcing people to rewrite all of THIS in "for *.po do THIS,
for *.pot do THIS too". You should be thankful for this separation.]
> So, really, the "actual coders" know best whether their changes should
> affect l10n or not, so they should be made more aware of it. Forcing
> "make pot" (and maybe more) on everyone sounds a bit harsh, but what
> else can we do?
I am not sure what problem you are trying to solve. Do you want to
make sure mismarking such as N_(("foo")) is caught by the person who
changes "foo" into N_(("foo"))?
"make pot" alone would obviously not help, and you would definitely
need "maybe more" but I'd imagine that would involve checking the
diff in the code part i.e. "we have a new N_(...)" against the
differences in git.pot files you would obtain by running "make pot"
before the code change and after the code change, i.e. "there is no
new mention of "foo"".
I do not think you are suggesting to commit the result of "make pot"
along with code changes, but if you are, please don't ;-)
--
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