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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
