From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Duy Nguyen <pclouds@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
Jiang Xin <worldhello.net@gmail.com>
Subject: Re: [ANNOUNCE] Git v2.8.0-rc2
Date: Thu, 17 Mar 2016 15:51:43 +0100 [thread overview]
Message-ID: <56EAC47F.6000708@drmicha.warpmail.net> (raw)
In-Reply-To: <xmqqmvpy5qru.fsf@gitster.mtv.corp.google.com>
Junio C Hamano venit, vidit, dixit 16.03.2016 17:30:
> Michael J Gruber <git@drmicha.warpmail.net> 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.]
I know why we have that. It's just unfortunate that we can't even
provide a default textconfig config easily - I know very well we can't
have that securely.
"Unfortunate" is meant in this context in the sense: I want to make it
easy and convenient for non-l10n-people to watch out for l10-affecting
changes.
>> 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"))?
Yes. That and similar ones.
> "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 ;-)
As I said: I assume there's a good reason we don't do that, and that's
why I'm not suggesting it.
On the other hand, it means that the in-tree git.pot does not correlate
with the in-tree source code at all, which feels really weird[*]. And it
makes it difficult to check the impact of your code changes: You can't
simply run "make pot" and check the diff - because the in-tree git.pot
does not reflect the state before your changes at all.
[*] It just feels wrong to me that a "make pot" in a clean checkout
leads to dirty index.
So, in short, I do believe there is a good reason for the "out of sync"
git.pot. That doesn't make the negative side effect that I describe any
less true, and I'm looking for ways to ammeliorate that. Something as
easy as "make check" or "make test-lint".
Michael
next prev parent reply other threads:[~2016-03-17 14:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 23:04 [ANNOUNCE] Git v2.8.0-rc2 Junio C Hamano
2016-03-12 9:11 ` Max Horn
2016-03-14 18:10 ` Junio C Hamano
2016-03-14 15:29 ` Michael J Gruber
2016-03-14 15:30 ` [PATCH] wt-status: allow "ahead " to be picked up by l10n Michael J Gruber
2016-03-14 15:57 ` Junio C Hamano
2016-03-14 15:56 ` [ANNOUNCE] Git v2.8.0-rc2 Junio C Hamano
2016-03-14 17:47 ` Junio C Hamano
2016-03-16 13:33 ` Michael J Gruber
2016-03-16 13:40 ` Duy Nguyen
2016-03-16 15:32 ` Michael J Gruber
2016-03-16 16:30 ` Junio C Hamano
2016-03-17 14:51 ` Michael J Gruber [this message]
2016-03-17 15:14 ` [RFC/PATCH] Makefile: allow po generation through po target Michael J Gruber
2016-03-17 22:42 ` Junio C Hamano
2016-03-17 16:15 ` [ANNOUNCE] Git v2.8.0-rc2 Junio C Hamano
2016-03-20 9:45 ` Jiang Xin
2016-03-20 15:11 ` Michael J Gruber
2016-03-21 20:01 ` Junio C Hamano
2016-03-22 10:00 ` Michael J Gruber
2016-03-22 17:43 ` Junio C Hamano
2016-03-15 16:42 ` Jiang Xin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56EAC47F.6000708@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=worldhello.net@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).