Re: [PATCH RFC 0/2] Mixing English and a local language

[Jeff King <peff@peff.net>]

On Wed, Sep 12, 2012 at 11:18:06AM -0700, Junio C Hamano wrote:

> I am so far taking the silence in the thread to mean they do not mind
> seeing the diffstat summary untranslated and they do not mind seeing
> it in Klingon, as long as the three numbers are there with (+) and (-)
> markings.

Actually, I have found the "Klingon" appearing in the diffstat of recent
messages to the list to be mildly annoying. I can decipher it, of
course, but in some cases I do not even have the glyphs in my font to
render the string, and it is quite ugly.

I think in an ideal world each repo could specify a "project language"
and, and diffstat, Signed-off-by, and [PATCH] would all be in that
language. Practically speaking, I'm not sure how much effort that is
worth; it seems like non-English speakers adapt to a few English phrases
(for example, email headers and date formats are all in English; I
imagine many clients localize them behind the scenes, but certainly the
"git format-patch && $EDITOR && git send-email" workflow does not and
should not).

I think I'd prefer:

  1. Revert diffstat to always be in English/C locale for now. For all
     commands. People too frequently end up showing the output of things
     besides format-patch. It means they will have to read the English
     when they are just running locally, but since format-patch is
     generating it, it is something that they would need to
     understand anyway.

  2. If people on non-English projects find that too cumbersome, then we
     can switch the "English/C" above for `i18n.projectlang` or
     something. But it should not be per-command, but per-message, and
     should include all output that is not diagnostic and is not
     machine-parseable (e.g., what I mentioned above, request-pull
     output, etc). If it is the project's language, then the team
     members will need to know it anyway, so it should not be too big a
     burden to have a potentially different language there than in the
     diagnostic messages.

But take my opinion with a grain of salt. English is my first language,
so I have zero first-hand experience with these issues. For most open
source projects that operate in English, I think just (1) will be fine.
The real test for needing (2) would not be a project like git, but a
project conducted solely in another language, where some of the
participants do not speak English at all.

-Peff