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

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