On Thu, Sep 13, 2012 at 09:16:26PM +0700, Nguyen Thai Ngoc Duy wrote: > This reverts the i18n part of 7f81463 (Use correct grammar in diffstat > summary line - 2012-02-01) but still keeps the grammar correctness for > English. It also reverts b354f11 (Fix tests under GETTEXT_POISON on > diffstat - 2012-08-27). The result is diffstat always in English > for all commands. > > This helps stop users from accidentally sending localized > format-patch'd patches. Yeah, this is exactly what I had in mind for now. Thanks. > The "for now" sounds reasonable. Minimum annoyance is always good > especially in a (largely?) volunteer-driven development environment > like git. So I revert the i18n effect. Note that I don't optimize the > changes for English only. The i18n might come back some day if we > find a good way to do it. > > Git is still partly i18n-ized, turning a few strings back does not > seem a big regression. I wonder if it would ever be fully so. Diffs will always have "diff" in them. Git-checkout will always be called "checkout". It seems like learning a little bit of the original language is always necessary for command-line tools and machine-readable formats. > > 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. > > If you mean projectlang vs a local language, I looked into that and I > don't think we could support two non-C languages using standard > gettext interface. So it's either "C vs another", or make use of > unofficial gettext features, or roll your own. Yeah, I saw in your original message that it gets hairy. My statement was more about what we would want if there were no implementation obstacles. I'd leave it to later to decide the details. -Peff -- 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