{"thread":{"id":"31360","subject":"[PATCH 1/2] Allow to print diffstat in English regardless current locale","startedAt":"2012-08-25T19:26:54Z","lastAt":"2012-09-15T02:41:23Z","messageCount":28,"participants":["Nguyễn Thái Ngọc Duy","Nguyen Thai Ngoc Duy","Junio C Hamano","Jeff King","Michael J Gruber"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"197847","messageId":"1345922816-20616-1-git-send-email-pclouds@gmail.com","threadId":"31360","inReplyTo":null,"subject":"[PATCH RFC 0/2] Mixing English and a local language","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-08-25T19:26:54Z","receivedAt":"2012-08-25T19:26:54Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"The l10n effort leads to a situation where a contributor can submit a\npatch with some auto-generated information in his language, which may\nnot be the team's language. We need to make sure exchange medium like\npatch is always in a common language that the team understands.\n\nNow this team language may not necessarily be English. However there\nare technical difficulties involved in switching between two\nlanguages. The only way I can think of, on top of gettext, is provide\ngit translations in multiple domains. Say diff machinery uses\n\"git-diff\" domain while the rest is in \"git\". We can drive gettext to\nuse language X for diff machinery, and Y for the rest. For that, we\nreplace gettext() with dgettext().\n\nIt's cumbersome. And there has not been any sign that there will be\na real user for it. So I assume that the \"team language\" will always\nbe English. It's simpler and should cover 90% of the user base. If\nsomeday people ask for that, supporting it is simply a matter of\nrewriting C_() and CQ_() macros in the first patch to use dgettext()\ninstead.\n\nSwitching between a language and English is easier. We just need an\nif/else to decide whether to call gettext(). Which is what the first\npatch does, just for certain parts of diff machinery. Error messages\nwill alway be in native language.\n\nThe second patch puts format-patch output in English unconditionally.\nAgain I'm partly lazy and not so sure that there will be needs for\nformat-patch to produce in native language. If someone needs it, we\ncan introduce a new config key that flip no_l10n flag back to 0.\n\nMore commands may follow format-patch. I think that 'apply' should also\nuse English for non-tty output, unless users request it to be in local\nlanguage. IOW local language is treated pretty much like coloring.\n\nNguyễn Thái Ngọc Duy (2):\n Allow to print diffstat in English regardless current locale\n format-patch: always print diffstat in English\n\n builtin/apply.c | 2 +-\n builtin/log.c | 1 +\n diff.c | 19 ++++++++++++-------\n diff.h | 3 ++-\n 4 files changed, 16 insertions(+), 9 deletions(-)\n\n-- \n1.7.12.rc1.27.g6d3049b.dirty\n"},{"id":"197845","messageId":"1345922816-20616-2-git-send-email-pclouds@gmail.com","threadId":"31360","inReplyTo":"1345922816-20616-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 1/2] Allow to print diffstat in English regardless current locale","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-08-25T19:26:55Z","receivedAt":"2012-08-25T19:26:55Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n builtin/apply.c | 2 +-\n diff.c | 19 ++++++++++++-------\n diff.h | 2 +-\n 3 files changed, 14 insertions(+), 9 deletions(-)\n\ndiff --git a/builtin/apply.c b/builtin/apply.c\nindex d453c83..3f2779f 100644\n--- a/builtin/apply.c\n+++ b/builtin/apply.c\n@@ -3627,7 +3627,7 @@ static void stat_patch_list(struct patch *patch)\n \t\tshow_stats(patch);\n \t}\n \n-\tprint_stat_summary(stdout, files, adds, dels);\n+\tprint_stat_summary(stdout, 0, files, adds, dels);\n }\n \n static void numstat_patch_list(struct patch *patch)\ndiff --git a/diff.c b/diff.c\nindex 95706a5..47d7e50 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -1390,18 +1390,21 @@ static void fill_print_name(struct diffstat_file *file)\n \tfile->print_name = pname;\n }\n \n-int print_stat_summary(FILE *fp, int files, int insertions, int deletions)\n+int print_stat_summary(FILE *fp, int no_l10n, int files,\n+\t\t int insertions, int deletions)\n {\n+#define C_(s) (no_l10n ? s : _(s))\n+#define CQ_(s1, s2, num) (no_l10n ? (num == 1 ? s1 : s2) : Q_(s1, s2, num))\n \tstruct strbuf sb = STRBUF_INIT;\n \tint ret;\n \n \tif (!files) {\n \t\tassert(insertions == 0 && deletions == 0);\n-\t\treturn fprintf(fp, \"%s\\n\", _(\" 0 files changed\"));\n+\t\treturn fprintf(fp, \"%s\\n\", C_(\" 0 files changed\"));\n \t}\n \n \tstrbuf_addf(&sb,\n-\t\t Q_(\" %d file changed\", \" %d files changed\", files),\n+\t\t CQ_(\" %d file changed\", \" %d files changed\", files),\n \t\t files);\n \n \t/*\n@@ -1418,7 +1421,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)\n \t\t * do not translate it.\n \t\t */\n \t\tstrbuf_addf(&sb,\n-\t\t\t Q_(\", %d insertion(+)\", \", %d insertions(+)\",\n+\t\t\t CQ_(\", %d insertion(+)\", \", %d insertions(+)\",\n \t\t\t insertions),\n \t\t\t insertions);\n \t}\n@@ -1429,7 +1432,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)\n \t\t * do not translate it.\n \t\t */\n \t\tstrbuf_addf(&sb,\n-\t\t\t Q_(\", %d deletion(-)\", \", %d deletions(-)\",\n+\t\t\t CQ_(\", %d deletion(-)\", \", %d deletions(-)\",\n \t\t\t deletions),\n \t\t\t deletions);\n \t}\n@@ -1437,6 +1440,8 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)\n \tret = fputs(sb.buf, fp);\n \tstrbuf_release(&sb);\n \treturn ret;\n+#undef C_\n+#undef CQ_\n }\n \n static void show_stats(struct diffstat_t *data, struct diff_options *options)\n@@ -1682,7 +1687,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)\n \t\textra_shown = 1;\n \t}\n \tfprintf(options->file, \"%s\", line_prefix);\n-\tprint_stat_summary(options->file, total_files, adds, dels);\n+\tprint_stat_summary(options->file, 0, total_files, adds, dels);\n }\n \n static void show_shortstats(struct diffstat_t *data, struct diff_options *options)\n@@ -1711,7 +1716,7 @@ static void show_shortstats(struct diffstat_t *data, struct diff_options *option\n \t\t\t\toptions->output_prefix_data);\n \t\tfprintf(options->file, \"%s\", msg->buf);\n \t}\n-\tprint_stat_summary(options->file, total_files, adds, dels);\n+\tprint_stat_summary(options->file, 0, total_files, adds, dels);\n }\n \n static void show_numstat(struct diffstat_t *data, struct diff_options *options)\ndiff --git a/diff.h b/diff.h\nindex e027650..eec79ef 100644\n--- a/diff.h\n+++ b/diff.h\n@@ -329,7 +329,7 @@ extern struct userdiff_driver *get_textconv(struct diff_filespec *one);\n \n extern int parse_rename_score(const char **cp_p);\n \n-extern int print_stat_summary(FILE *fp, int files,\n+extern int print_stat_summary(FILE *fp, int no_l10n, int files,\n \t\t\t int insertions, int deletions);\n \n #endif /* DIFF_H */\n-- \n1.7.12.rc1.27.g6d3049b.dirty\n"},{"id":"197846","messageId":"1345922816-20616-3-git-send-email-pclouds@gmail.com","threadId":"31360","inReplyTo":"1345922816-20616-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 2/2] format-patch: always print diffstat in English","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-08-25T19:26:56Z","receivedAt":"2012-08-25T19:26:56Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n builtin/log.c | 1 +\n diff.c | 4 ++--\n diff.h | 1 +\n 3 files changed, 4 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/log.c b/builtin/log.c\nindex ecc2793..62f4b7e 100644\n--- a/builtin/log.c\n+++ b/builtin/log.c\n@@ -1225,6 +1225,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)\n \n \t/* Always generate a patch */\n \trev.diffopt.output_format |= DIFF_FORMAT_PATCH;\n+\trev.diffopt.no_l10n = 1;\n \n \tif (!DIFF_OPT_TST(&rev.diffopt, TEXT) && !no_binary_diff)\n \t\tDIFF_OPT_SET(&rev.diffopt, BINARY);\ndiff --git a/diff.c b/diff.c\nindex 47d7e50..a20cfcc 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -1687,7 +1687,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)\n \t\textra_shown = 1;\n \t}\n \tfprintf(options->file, \"%s\", line_prefix);\n-\tprint_stat_summary(options->file, 0, total_files, adds, dels);\n+\tprint_stat_summary(options->file, options->no_l10n, total_files, adds, dels);\n }\n \n static void show_shortstats(struct diffstat_t *data, struct diff_options *options)\n@@ -1716,7 +1716,7 @@ static void show_shortstats(struct diffstat_t *data, struct diff_options *option\n \t\t\t\toptions->output_prefix_data);\n \t\tfprintf(options->file, \"%s\", msg->buf);\n \t}\n-\tprint_stat_summary(options->file, 0, total_files, adds, dels);\n+\tprint_stat_summary(options->file, options->no_l10n, total_files, adds, dels);\n }\n \n static void show_numstat(struct diffstat_t *data, struct diff_options *options)\ndiff --git a/diff.h b/diff.h\nindex eec79ef..ea4075d 100644\n--- a/diff.h\n+++ b/diff.h\n@@ -125,6 +125,7 @@ struct diff_options {\n \tint dirstat_permille;\n \tint setup;\n \tint abbrev;\n+\tint no_l10n;\n \tconst char *prefix;\n \tint prefix_length;\n \tconst char *stat_sep;\n-- \n1.7.12.rc1.27.g6d3049b.dirty\n"},{"id":"198844","messageId":"CACsJy8CG72PzvndV7C4a9hspxhprKn2tcb49HxeZ14pmEDycGQ@mail.gmail.com","threadId":"31360","inReplyTo":"1345922816-20616-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH RFC 0/2] Mixing English and a local language","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-09-12T14:05:33Z","receivedAt":"2012-09-12T14:05:33Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Should I interpret the silence as \"I don't care, if you want it, go\nfor it\" or \"not acceptable, but no reasons given\"? I'd like some form\nof it in. Reverting the i18n diffstat patch is the last resort that I\nreally don't want to do.\n\nOn Sun, Aug 26, 2012 at 2:26 AM, Nguyễn Thái Ngọc Duy wrote:\n> The l10n effort leads to a situation where a contributor can submit a\n> patch with some auto-generated information in his language, which may\n> not be the team's language. We need to make sure exchange medium like\n> patch is always in a common language that the team understands.\n>\n> Now this team language may not necessarily be English. However there\n> are technical difficulties involved in switching between two\n> languages. The only way I can think of, on top of gettext, is provide\n> git translations in multiple domains. Say diff machinery uses\n> \"git-diff\" domain while the rest is in \"git\". We can drive gettext to\n> use language X for diff machinery, and Y for the rest. For that, we\n> replace gettext() with dgettext().\n>\n> It's cumbersome. And there has not been any sign that there will be\n> a real user for it. So I assume that the \"team language\" will always\n> be English. It's simpler and should cover 90% of the user base. If\n> someday people ask for that, supporting it is simply a matter of\n> rewriting C_() and CQ_() macros in the first patch to use dgettext()\n> instead.\n>\n> Switching between a language and English is easier. We just need an\n> if/else to decide whether to call gettext(). Which is what the first\n> patch does, just for certain parts of diff machinery. Error messages\n> will alway be in native language.\n>\n> The second patch puts format-patch output in English unconditionally.\n> Again I'm partly lazy and not so sure that there will be needs for\n> format-patch to produce in native language. If someone needs it, we\n> can introduce a new config key that flip no_l10n flag back to 0.\n>\n> More commands may follow format-patch. I think that 'apply' should also\n> use English for non-tty output, unless users request it to be in local\n> language. IOW local language is treated pretty much like coloring.\n>\n> Nguyễn Thái Ngọc Duy (2):\n> Allow to print diffstat in English regardless current locale\n> format-patch: always print diffstat in English\n>\n> builtin/apply.c | 2 +-\n> builtin/log.c | 1 +\n> diff.c | 19 ++++++++++++-------\n> diff.h | 3 ++-\n> 4 files changed, 16 insertions(+), 9 deletions(-)\n>\n> --\n> 1.7.12.rc1.27.g6d3049b.dirty\n>\n\n\n\n-- \nDuy\n"},{"id":"198866","messageId":"7vligfcdgh.fsf@alter.siamese.dyndns.org","threadId":"31360","inReplyTo":"CACsJy8CG72PzvndV7C4a9hspxhprKn2tcb49HxeZ14pmEDycGQ@mail.gmail.com","subject":"Re: [PATCH RFC 0/2] Mixing English and a local language","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-12T18:18:06Z","receivedAt":"2012-09-12T18:18:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy writes:\n\n> Should I interpret the silence as \"I don't care, if you want it, go\n> for it\" or \"not acceptable, but no reasons given\"?\n\nI do not speak for the others, but the reason I didn't respond is\nnone of the above. It is somewhere between \"Meh\" and \"Anything that\nsays 'local language' and 'English' cannot be worth looking at.\"\n\nI _think_ the patch was inspired by $gmane/204979, where I said:\n\n Or \"LC_ALL=C LANG=C git format-patch ...\".\n\n It does not bother me (even though I do not read Vietnamese), but\n this has been brought up a few times, and we may want to revert the\n i18n of the diffstat summary. It does not seem to add much value to\n the system but annoys people. After all, the \"upstream\" diffstat\n does not localizes this string (I just checked diffstat-1.55 with\n Jan 2012 timestamp).\n\nand I have been waiting to see what others think. I am so far\ntaking the silence in the thread to mean they do not mind seeing the\ndiffstat summary untranslated and they do not mind seeing it in\nKlingon, as long as the three numbers are there with (+) and (-)\nmarkings.\n\nIt is bad enough having to decide where the boundary between 'local\nlanguage' and 'C locale' should be drawn in the mixture. I am not\nenthused by an attempt to make the boundary tweakable, and worse\nyet, to do so per command.\n\nIMHO, we should just decide where to draw the line and be done with\nit. The users already know or can be trained to know to choose the\ngreatest common denominator when interacting with others.\n"},{"id":"198915","messageId":"20120913132847.GD4287@sigill.intra.peff.net","threadId":"31360","inReplyTo":"7vligfcdgh.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC 0/2] Mixing English and a local language","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-13T13:28:47Z","receivedAt":"2012-09-13T13:28:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 12, 2012 at 11:18:06AM -0700, Junio C Hamano wrote:\n\n> I am so far taking the silence in the thread to mean they do not mind\n> seeing the diffstat summary untranslated and they do not mind seeing\n> it in Klingon, as long as the three numbers are there with (+) and (-)\n> markings.\n\nActually, I have found the \"Klingon\" appearing in the diffstat of recent\nmessages to the list to be mildly annoying. I can decipher it, of\ncourse, but in some cases I do not even have the glyphs in my font to\nrender the string, and it is quite ugly.\n\nI think in an ideal world each repo could specify a \"project language\"\nand, and diffstat, Signed-off-by, and [PATCH] would all be in that\nlanguage. Practically speaking, I'm not sure how much effort that is\nworth; it seems like non-English speakers adapt to a few English phrases\n(for example, email headers and date formats are all in English; I\nimagine many clients localize them behind the scenes, but certainly the\n\"git format-patch && $EDITOR && git send-email\" workflow does not and\nshould not).\n\nI think I'd prefer:\n\n 1. Revert diffstat to always be in English/C locale for now. For all\n commands. People too frequently end up showing the output of things\n besides format-patch. It means they will have to read the English\n when they are just running locally, but since format-patch is\n generating it, it is something that they would need to\n understand anyway.\n\n 2. If people on non-English projects find that too cumbersome, then we\n can switch the \"English/C\" above for `i18n.projectlang` or\n something. But it should not be per-command, but per-message, and\n should include all output that is not diagnostic and is not\n machine-parseable (e.g., what I mentioned above, request-pull\n output, etc). If it is the project's language, then the team\n members will need to know it anyway, so it should not be too big a\n burden to have a potentially different language there than in the\n diagnostic messages.\n\nBut take my opinion with a grain of salt. English is my first language,\nso I have zero first-hand experience with these issues. For most open\nsource projects that operate in English, I think just (1) will be fine.\nThe real test for needing (2) would not be a project like git, but a\nproject conducted solely in another language, where some of the\nparticipants do not speak English at all.\n\n-Peff\n"},{"id":"198925","messageId":"1347545786-936-1-git-send-email-pclouds@gmail.com","threadId":"31360","inReplyTo":"20120913132847.GD4287@sigill.intra.peff.net","subject":"[PATCH] Revert diffstat back to English","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-09-13T14:16:26Z","receivedAt":"2012-09-13T14:16:26Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"This reverts the i18n part of 7f81463 (Use correct grammar in diffstat\nsummary line - 2012-02-01) but still keeps the grammar correctness for\nEnglish. It also reverts b354f11 (Fix tests under GETTEXT_POISON on\ndiffstat - 2012-08-27). The result is diffstat always in English\nfor all commands.\n\nThis helps stop users from accidentally sending localized\nformat-patch'd patches.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n On Thu, Sep 13, 2012 at 8:28 PM, Jeff King wrote:\n > 1. Revert diffstat to always be in English/C locale for now. For all\n > commands. People too frequently end up showing the output of things\n > besides format-patch. It means they will have to read the English\n > when they are just running locally, but since format-patch is\n > generating it, it is something that they would need to\n > understand anyway.\n\n The \"for now\" sounds reasonable. Minimum annoyance is always good\n especially in a (largely?) volunteer-driven development environment\n like git. So I revert the i18n effect. Note that I don't optimize the\n changes for English only. The i18n might come back some day if we\n find a good way to do it.\n\n Git is still partly i18n-ized, turning a few strings back does not\n seem a big regression.\n\n > 2. If people on non-English projects find that too cumbersome, then we\n > can switch the \"English/C\" above for `i18n.projectlang` or\n > something. But it should not be per-command, but per-message, and\n > should include all output that is not diagnostic and is not\n > machine-parseable (e.g., what I mentioned above, request-pull\n > output, etc). If it is the project's language, then the team\n > members will need to know it anyway, so it should not be too big a\n > burden to have a potentially different language there than in the\n > diagnostic messages.\n\n If you mean projectlang vs a local language, I looked into that and I\n don't think we could support two non-C languages using standard\n gettext interface. So it's either \"C vs another\", or make use of\n unofficial gettext features, or roll your own.\n\n diff.c | 10 ++++------\n t/t4006-diff-mode.sh | 8 ++++----\n t/t4202-log.sh | 2 +-\n t/t4205-log-pretty-formats.sh | 4 ++--\n t/t7508-status.sh | 2 +-\n 5 files changed, 12 insertions(+), 14 deletions(-)\n\ndiff --git a/diff.c b/diff.c\nindex e6846ca..8c23b9c 100644\n--- a/diff.c\n+++ b/diff.c\n@@ -1398,11 +1398,11 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)\n \n \tif (!files) {\n \t\tassert(insertions == 0 && deletions == 0);\n-\t\treturn fprintf(fp, \"%s\\n\", _(\" 0 files changed\"));\n+\t\treturn fprintf(fp, \"%s\\n\", \" 0 files changed\");\n \t}\n \n \tstrbuf_addf(&sb,\n-\t\t Q_(\" %d file changed\", \" %d files changed\", files),\n+\t\t files ? \" %d files changed\" : \" %d file changed\",\n \t\t files);\n \n \t/*\n@@ -1419,8 +1419,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)\n \t\t * do not translate it.\n \t\t */\n \t\tstrbuf_addf(&sb,\n-\t\t\t Q_(\", %d insertion(+)\", \", %d insertions(+)\",\n-\t\t\t insertions),\n+\t\t\t insertions ? \", %d insertions(+)\" : \", %d insertion(+)\",\n \t\t\t insertions);\n \t}\n \n@@ -1430,8 +1429,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)\n \t\t * do not translate it.\n \t\t */\n \t\tstrbuf_addf(&sb,\n-\t\t\t Q_(\", %d deletion(-)\", \", %d deletions(-)\",\n-\t\t\t deletions),\n+\t\t\t deletions ? \", %d deletions(-)\" : \", %d deletion(-)\",\n \t\t\t deletions);\n \t}\n \tstrbuf_addch(&sb, '\\n');\ndiff --git a/t/t4006-diff-mode.sh b/t/t4006-diff-mode.sh\nindex 3d4b1ba..7a3e1f9 100755\n--- a/t/t4006-diff-mode.sh\n+++ b/t/t4006-diff-mode.sh\n@@ -36,24 +36,24 @@ test_expect_success '--stat output after text chmod' '\n \ttest_chmod -x rezrov &&\n \techo \" 0 files changed\" >expect &&\n \tgit diff HEAD --stat >actual &&\n-\ttest_i18ncmp expect actual\n+\ttest_cmp expect actual\n '\n \n test_expect_success '--shortstat output after text chmod' '\n \tgit diff HEAD --shortstat >actual &&\n-\ttest_i18ncmp expect actual\n+\ttest_cmp expect actual\n '\n \n test_expect_success '--stat output after binary chmod' '\n \ttest_chmod +x binbin &&\n \techo \" 0 files changed\" >expect &&\n \tgit diff HEAD --stat >actual &&\n-\ttest_i18ncmp expect actual\n+\ttest_cmp expect actual\n '\n \n test_expect_success '--shortstat output after binary chmod' '\n \tgit diff HEAD --shortstat >actual &&\n-\ttest_i18ncmp expect actual\n+\ttest_cmp expect actual\n '\n \n test_done\ndiff --git a/t/t4202-log.sh b/t/t4202-log.sh\nindex 924ba53..b3ac6be 100755\n--- a/t/t4202-log.sh\n+++ b/t/t4202-log.sh\n@@ -813,7 +813,7 @@ sanitize_output () {\n test_expect_success 'log --graph with diff and stats' '\n \tgit log --graph --pretty=short --stat -p >actual &&\n \tsanitize_output >actual.sanitized expected &&\n \tgit log -z --stat --pretty=\"format:%s\" >actual &&\n-\ttest_i18ncmp expected actual\n+\ttest_cmp expected actual\n '\n \n test_expect_failure 'NUL termination with --stat' '\n@@ -96,7 +96,7 @@ test_expect_failure 'NUL termination with --stat' '\n \tstat1_part=$(git diff --stat --root HEAD^) &&\n \tprintf \"add bar\\n$stat0_part\\n\\0initial\\n$stat1_part\\n\\0\" >expected &&\n \tgit log -z --stat --pretty=\"tformat:%s\" >actual &&\n-\ttest_i18ncmp expected actual\n+\ttest_cmp expected actual\n '\n \n test_done\ndiff --git a/t/t7508-status.sh b/t/t7508-status.sh\nindex e313ef1..c206f47 100755\n--- a/t/t7508-status.sh\n+++ b/t/t7508-status.sh\n@@ -80,7 +80,7 @@ test_expect_success 'status --column' '\n #\tdir1/untracked dir2/untracked untracked\n #\tdir2/modified output\n EOF\n-\ttest_i18ncmp expect output\n+\ttest_cmp expect output\n '\n \n cat >expect <<\\EOF\n-- \n1.7.12.396.g87e837f.dirty\n"},{"id":"198926","messageId":"20120913145708.GA32523@sigill.intra.peff.net","threadId":"31360","inReplyTo":"1347545786-936-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] Revert diffstat back to English","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-13T14:57:09Z","receivedAt":"2012-09-13T14:57:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 13, 2012 at 09:16:26PM +0700, Nguyen Thai Ngoc Duy wrote:\n\n> This reverts the i18n part of 7f81463 (Use correct grammar in diffstat\n> summary line - 2012-02-01) but still keeps the grammar correctness for\n> English. It also reverts b354f11 (Fix tests under GETTEXT_POISON on\n> diffstat - 2012-08-27). The result is diffstat always in English\n> for all commands.\n> \n> This helps stop users from accidentally sending localized\n> format-patch'd patches.\n\nYeah, this is exactly what I had in mind for now. Thanks.\n\n> The \"for now\" sounds reasonable. Minimum annoyance is always good\n> especially in a (largely?) volunteer-driven development environment\n> like git. So I revert the i18n effect. Note that I don't optimize the\n> changes for English only. The i18n might come back some day if we\n> find a good way to do it.\n> \n> Git is still partly i18n-ized, turning a few strings back does not\n> seem a big regression.\n\nI wonder if it would ever be fully so. Diffs will always have \"diff\" in\nthem. Git-checkout will always be called \"checkout\". It seems like\nlearning a little bit of the original language is always necessary for\ncommand-line tools and machine-readable formats.\n\n> > 2. If people on non-English projects find that too cumbersome, then we\n> > can switch the \"English/C\" above for `i18n.projectlang` or\n> > something. But it should not be per-command, but per-message, and\n> > should include all output that is not diagnostic and is not\n> > machine-parseable (e.g., what I mentioned above, request-pull\n> > output, etc). If it is the project's language, then the team\n> > members will need to know it anyway, so it should not be too big a\n> > burden to have a potentially different language there than in the\n> > diagnostic messages.\n> \n> If you mean projectlang vs a local language, I looked into that and I\n> don't think we could support two non-C languages using standard\n> gettext interface. So it's either \"C vs another\", or make use of\n> unofficial gettext features, or roll your own.\n\nYeah, I saw in your original message that it gets hairy. My statement\nwas more about what we would want if there were no implementation\nobstacles. I'd leave it to later to decide the details.\n\n-Peff\n"},{"id":"198939","messageId":"7v4nn1akz7.fsf@alter.siamese.dyndns.org","threadId":"31360","inReplyTo":"20120913132847.GD4287@sigill.intra.peff.net","subject":"Re: [PATCH RFC 0/2] Mixing English and a local language","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-13T17:30:52Z","receivedAt":"2012-09-13T17:30:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think I'd prefer:\n>\n> 1. Revert diffstat to always be in English/C locale for now. For all\n> commands. People too frequently end up showing the output of things\n> besides format-patch. It means they will have to read the English\n> when they are just running locally, but since format-patch is\n> generating it, it is something that they would need to\n> understand anyway.\n>\n> 2. If people on non-English projects find that too cumbersome, then we\n> can switch the \"English/C\" above for `i18n.projectlang` or\n> something.\n\nThat part I sort-of understand.\n\n> But it should not be per-command, but per-message, and\n> should include all output that is not diagnostic and is not\n> machine-parseable (e.g., what I mentioned above, request-pull\n> output, etc). If it is the project's language, then the team\n> members will need to know it anyway, so it should not be too big a\n> burden to have a potentially different language there than in the\n> diagnostic messages.\n\nNo matter what the project languages is, machine parseable part will\nnot be localized but fixed to \"C\" anyway, so I do not think it comes\ninto the picture.\n\nMy take on this is, if there is the project language, it should\napply to _everything_. Please do not introduce any per-command,\nper-message, per-anything mess. Just set LANG/LC_ALL up and be done\nwith it.\n\nAnd I think you justified why that is the right thing to do very\nwell in the second sentence in the above paragraph I quoted from\nyou.\n"},{"id":"198940","messageId":"7vzk4t960y.fsf@alter.siamese.dyndns.org","threadId":"31360","inReplyTo":"1347545786-936-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] Revert diffstat back to English","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-13T17:39:09Z","receivedAt":"2012-09-13T17:39:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> Git is still partly i18n-ized, turning a few strings back does not\n> seem a big regression.\n\nMore than one people explicitly said that they do not want to see\nthis in Klingon. Even if the system is fully internationalized,\nthese \"... (+), ... (-)\" should never be localized, just like we\nwill never localize \"diff --git\", \"index f00f..abcd\", etc.\n\nIn other words, it is not a \"regression\" to begin with. Turning\nthis back to \"C\" is a bugfix. We shouldn't have had marked it with\n_() in the first place.\n\n> If you mean projectlang vs a local language, I looked into that and I\n> don't think we could support two non-C languages using standard\n> gettext interface. So it's either \"C vs another\", or make use of\n> unofficial gettext features, or roll your own.\n\nYeah, that is true, too.\n"},{"id":"198942","messageId":"7vr4q595fb.fsf@alter.siamese.dyndns.org","threadId":"31360","inReplyTo":"7v4nn1akz7.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC 0/2] Mixing English and a local language","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-13T17:52:08Z","receivedAt":"2012-09-13T17:52:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> But it should not be per-command, but per-message, and\n>> should include all output that is not diagnostic and is not\n>> machine-parseable (e.g., what I mentioned above, request-pull\n>> output, etc). If it is the project's language, then the team\n>> members will need to know it anyway, so it should not be too big a\n>> burden to have a potentially different language there than in the\n>> diagnostic messages.\n>\n> No matter what the project languages is, machine parseable part will\n> not be localized but fixed to \"C\" anyway, so I do not think it comes\n> into the picture.\n>\n> My take on this is, if there is the project language, it should\n> apply to _everything_. Please do not introduce any per-command,\n> per-message, per-anything mess. Just set LANG/LC_ALL up and be done\n> with it.\n>\n> And I think you justified why that is the right thing to do very\n> well in the second sentence in the above paragraph I quoted from\n> you.\n\nYou seem to be saying that diagnostic does not have to be in project\nlanguage, but I do not think it is the right thing to do. The first\nresponse to \"Frotz does not work\" is often \"What do you exactly\nmean? How did you run Frotz? What error message are you getting\nfrom it?\", and you do not want to get back the diagnostics in\nKlingon.\n"},{"id":"198943","messageId":"20120913180056.GA1696@sigill.intra.peff.net","threadId":"31360","inReplyTo":"7v4nn1akz7.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC 0/2] Mixing English and a local language","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-13T18:00:56Z","receivedAt":"2012-09-13T18:00:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 13, 2012 at 10:30:52AM -0700, Junio C Hamano wrote:\n\n> > But it should not be per-command, but per-message, and\n> > should include all output that is not diagnostic and is not\n> > machine-parseable (e.g., what I mentioned above, request-pull\n> > output, etc). If it is the project's language, then the team\n> > members will need to know it anyway, so it should not be too big a\n> > burden to have a potentially different language there than in the\n> > diagnostic messages.\n> \n> No matter what the project languages is, machine parseable part will\n> not be localized but fixed to \"C\" anyway, so I do not think it comes\n> into the picture.\n\nBut there are parts that are neither machine-parseable nor diagnostics.\nThe diffstat is one, but I mentioned others. Are those going to be\nforever fixed to LANG=C?\n\nThat does not bother me, but for a project whose team works entirely in\nJapanese (both individually, and when sharing code), they will still be\nstuck with these English-language snippets, and no way to localize them.\nEven though they may not speak a word of it.\n\nI have no idea if such a team is a strawman or not; that is why I\nseparated points 1 and 2. We can wait on point 2 until such a team shows\nup and complains (of course, they would have to come here and complain\nin English, so...).\n\n> My take on this is, if there is the project language, it should\n> apply to _everything_. Please do not introduce any per-command,\n> per-message, per-anything mess. Just set LANG/LC_ALL up and be done\n> with it.\n\nBut isn't that arguing for localizing diffstat? It is not\nmachine-parseable, so an all-Japanese team would want to localize it\nalong with their diagnostics.\n\n-Peff\n"},{"id":"198944","messageId":"20120913180445.GB1696@sigill.intra.peff.net","threadId":"31360","inReplyTo":"7vr4q595fb.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH RFC 0/2] Mixing English and a local language","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-13T18:04:45Z","receivedAt":"2012-09-13T18:04:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 13, 2012 at 10:52:08AM -0700, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> >> But it should not be per-command, but per-message, and\n> >> should include all output that is not diagnostic and is not\n> >> machine-parseable (e.g., what I mentioned above, request-pull\n> >> output, etc). If it is the project's language, then the team\n> >> members will need to know it anyway, so it should not be too big a\n> >> burden to have a potentially different language there than in the\n> >> diagnostic messages.\n> >\n> > No matter what the project languages is, machine parseable part will\n> > not be localized but fixed to \"C\" anyway, so I do not think it comes\n> > into the picture.\n> >\n> > My take on this is, if there is the project language, it should\n> > apply to _everything_. Please do not introduce any per-command,\n> > per-message, per-anything mess. Just set LANG/LC_ALL up and be done\n> > with it.\n> >\n> > And I think you justified why that is the right thing to do very\n> > well in the second sentence in the above paragraph I quoted from\n> > you.\n> \n> You seem to be saying that diagnostic does not have to be in project\n> language, but I do not think it is the right thing to do. The first\n> response to \"Frotz does not work\" is often \"What do you exactly\n> mean? How did you run Frotz? What error message are you getting\n> from it?\", and you do not want to get back the diagnostics in\n> Klingon.\n\nBy that line of reasoning, wouldn't all git developers be required to\nset LANG=C? Fine by me as an English speaker, but I get the impression\nthat other developers are using the localization. I don't think there is\nanything wrong with primarily working in your native language, but\nmaking the effort to switch for communicating with teammates (either\nwhen writing them emails, or using LANG=C when showing them output from\nyour terminal).\n\nIf the \"switch to LANG=C\" thing is a relatively rare thing, I don't see\na problem. The issue with the diffstat is that it is too easy to\naccidentally send out a localized one.\n\n-Peff\n"},{"id":"198953","messageId":"7va9wt9377.fsf@alter.siamese.dyndns.org","threadId":"31360","inReplyTo":"7vzk4t960y.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Revert diffstat back to English","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-13T18:40:12Z","receivedAt":"2012-09-13T18:40:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Nguyễn Thái Ngọc Duy writes:\n>\n>> Git is still partly i18n-ized, turning a few strings back does not\n>> seem a big regression.\n>\n> More than one people explicitly said that they do not want to see\n> this in Klingon. Even if the system is fully internationalized,\n> these \"... (+), ... (-)\" should never be localized, just like we\n> will never localize \"diff --git\", \"index f00f..abcd\", etc.\n\nNah, I was being silly. People complaining on Klingon on _this_\nlist does not argue for this to be in \"C\"; it just means the\ni18n.projectlang for this project is \"C\".\n\nHow about _not_ reverting it and doing something like this instead?\nI suspect that we may need to delay the call to git_setup_gettext()\nin a similar way that we delay the call to commit_pager_choice(),\nbut that is a minor detail people smarter than I can surely figure\nout ;-)\n\n git.c | 10 ++++++++++\n 1 file changed, 10 insertions(+)\n\ndiff --git i/git.c w/git.c\nindex 8788b32..a2cb9c8 100644\n--- i/git.c\n+++ w/git.c\n@@ -51,6 +51,15 @@ int check_pager_config(const char *cmd)\n \treturn c.want;\n }\n \n+static int project_lang_config(const char *var, const char *value, void *cb_data)\n+{\n+\tif (!strcmp(var, \"i18n.projectlang\")) {\n+\t\tsetenv(\"LANG\", val, 1);\n+\t\tsetenv(\"LC_ALL\", val, 1);\n+\t}\n+\treturn 0;\n+}\n+\n static void commit_pager_choice(void) {\n \tswitch (use_pager) {\n \tcase 0:\n@@ -538,6 +547,7 @@ int main(int argc, const char **argv)\n \tif (!cmd)\n \t\tcmd = \"git-help\";\n \n+\tgit_config(project_lang_config, NULL);\n \tgit_setup_gettext();\n \n \t/*\n"},{"id":"198965","messageId":"20120913210111.GA16956@sigill.intra.peff.net","threadId":"31360","inReplyTo":"7va9wt9377.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Revert diffstat back to English","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-13T21:01:11Z","receivedAt":"2012-09-13T21:01:11Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 13, 2012 at 11:40:12AM -0700, Junio C Hamano wrote:\n\n> > More than one people explicitly said that they do not want to see\n> > this in Klingon. Even if the system is fully internationalized,\n> > these \"... (+), ... (-)\" should never be localized, just like we\n> > will never localize \"diff --git\", \"index f00f..abcd\", etc.\n> \n> Nah, I was being silly. People complaining on Klingon on _this_\n> list does not argue for this to be in \"C\"; it just means the\n> i18n.projectlang for this project is \"C\".\n\nRight, I think that is the case.\n\n> How about _not_ reverting it and doing something like this instead?\n> [...]\n> +static int project_lang_config(const char *var, const char *value, void *cb_data)\n> +{\n> +\tif (!strcmp(var, \"i18n.projectlang\")) {\n> +\t\tsetenv(\"LANG\", val, 1);\n> +\t\tsetenv(\"LC_ALL\", val, 1);\n> +\t}\n> +\treturn 0;\n> +}\n\nDoesn't that mean that anyone working on git.git will never get to see\ntheir localized language, even when it is not likely to be communicated\nto the rest of the project? I am OK with that as a native speaker, but I\nwonder what others would have to say.\n\nI suspect we will end up with people not setting i18n.projectlang, and\ngetting Klingon diffstats on the list.\n\n-Peff\n"},{"id":"198966","messageId":"7v627h7hny.fsf@alter.siamese.dyndns.org","threadId":"31360","inReplyTo":"20120913210111.GA16956@sigill.intra.peff.net","subject":"Re: [PATCH] Revert diffstat back to English","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-13T21:10:41Z","receivedAt":"2012-09-13T21:10:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I suspect we will end up with people not setting i18n.projectlang, and\n> getting Klingon diffstats on the list.\n\nYes, but when our starting point is that the diffstat summary is not\nmeant for machine consumption, which I tend to agree, that is a\nlogical consequence no matter how you cut it, no? After all, they\nwant to be careless when running format-patch meant for _this_\nproject whose project language is C locale, but still want to be\nable to see output that is not meant for machine consumption in\ntheir native language, and these are incompatible goals.\n\nGiving them a mechanism so that they do not have to remember setting\nLANG/LC_ALL every time they context switch into this project would\nbe the best we can do, I am afraid.\n\nUnless somebody has a better design that does not involve three\nlanguages (always C, project language and Klingon), that is.\n"},{"id":"198972","messageId":"20120913212043.GB16968@sigill.intra.peff.net","threadId":"31360","inReplyTo":"7v627h7hny.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Revert diffstat back to English","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-13T21:20:43Z","receivedAt":"2012-09-13T21:20:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 13, 2012 at 02:10:41PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I suspect we will end up with people not setting i18n.projectlang, and\n> > getting Klingon diffstats on the list.\n> \n> Yes, but when our starting point is that the diffstat summary is not\n> meant for machine consumption, which I tend to agree, that is a\n> logical consequence no matter how you cut it, no? After all, they\n> want to be careless when running format-patch meant for _this_\n> project whose project language is C locale, but still want to be\n> able to see output that is not meant for machine consumption in\n> their native language, and these are incompatible goals.\n\nI do not think they are incompatible if you separate it into three\ncategories: machine readable (must never be translated), for the current\nuser right now (current i18n), and for sharing with other humans\n(i18n.projectlang).\n\nWhether the maintenance of that three-way split is worthwhile, I don't\nknow (and that is why I said \"in an ideal world...\" in my original\nmail, and left the implementation for people who care more). In the\nmeantime, before we have a working i18n.projectlang solution, which slot\nshould we put those messages in?\n\nI'd argue for putting them in the machine-readable category, because it\nis less likely to cause interoperability annoyances (and since git is\nnot fully translated anyway, we kind of assume at this point that people\nknow some basic phrases in the C locale).\n\nAnd of course it is not fool-proof. The \"for the current user right now\"\nmessages may bleed into conversation with other people. But that cannot\nbe helped if we are to do any localization at all, and it does not seem\nto be a big problem in practice. The only practical problem so far is\nwith certain meant-to-be-shared messages.\n\n-Peff\n"},{"id":"198975","messageId":"7vr4q562cg.fsf@alter.siamese.dyndns.org","threadId":"31360","inReplyTo":"20120913212043.GB16968@sigill.intra.peff.net","subject":"Re: [PATCH] Revert diffstat back to English","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-13T21:26:55Z","receivedAt":"2012-09-13T21:26:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I do not think they are incompatible if you separate it into three\n> categories: machine readable (must never be translated), for the current\n> user right now (current i18n), and for sharing with other humans\n> (i18n.projectlang).\n\nAnything you see as a user is potentially useful to other project\nparticipants, so I do not think there is a bright line that\ndelineates the latter two classes. The output of format-patch is\nobviously meant as the latter, but how about the output from show or\nlog? Is it worth trying to define the bright line somewhere, only\nto annoy users who may want to draw the line differently?\n\n> Whether the maintenance of that three-way split is worthwhile, I don't\n> know (and that is why I said \"in an ideal world...\" in my original\n> mail, and left the implementation for people who care more). In the\n> meantime, before we have a working i18n.projectlang solution, which slot\n> should we put those messages in?\n>\n> I'd argue for putting them in the machine-readable category, because it\n> is less likely to cause interoperability annoyances (and since git is\n> not fully translated anyway, we kind of assume at this point that people\n> know some basic phrases in the C locale).\n>\n> And of course it is not fool-proof. The \"for the current user right now\"\n> messages may bleed into conversation with other people. But that cannot\n> be helped if we are to do any localization at all, and it does not seem\n> to be a big problem in practice. The only practical problem so far is\n> with certain meant-to-be-shared messages.\n>\n> -Peff\n"},{"id":"198977","messageId":"20120913213121.GA31426@sigill.intra.peff.net","threadId":"31360","inReplyTo":"7vr4q562cg.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Revert diffstat back to English","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-13T21:31:21Z","receivedAt":"2012-09-13T21:31:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 13, 2012 at 02:26:55PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I do not think they are incompatible if you separate it into three\n> > categories: machine readable (must never be translated), for the current\n> > user right now (current i18n), and for sharing with other humans\n> > (i18n.projectlang).\n> \n> Anything you see as a user is potentially useful to other project\n> participants, so I do not think there is a bright line that\n> delineates the latter two classes. The output of format-patch is\n> obviously meant as the latter, but how about the output from show or\n> log? Is it worth trying to define the bright line somewhere, only\n> to annoy users who may want to draw the line differently?\n\nI agree that the line is not bright. I do not know if it is worthwhile\nor not. I think it will solve some practical problems, but it may also\nintroduce others. But basically having a per-repo LANG setting (which\nis what the projectlang you are talking about would do) also does not\nseem like a solution that people will use, because they will not get any\nlocalization benefit at all.\n\nSo again, I'd rather err on the side of pushing those things that are\nnear the line into the \"do not translate\" side, letting people use LANG\nto localize the rest, and accepting that occasionally people are going\nto accidentally show you output in a language you don't understand. But\nhopefully that keeps it to \"occasionally\" and not \"every time you send\nout a patch\".\n\n-Peff\n"},{"id":"198979","messageId":"7vehm561eq.fsf@alter.siamese.dyndns.org","threadId":"31360","inReplyTo":"20120913213121.GA31426@sigill.intra.peff.net","subject":"Re: [PATCH] Revert diffstat back to English","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-13T21:47:09Z","receivedAt":"2012-09-13T21:47:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Sep 13, 2012 at 02:26:55PM -0700, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>> \n>> > I do not think they are incompatible if you separate it into three\n>> > categories: machine readable (must never be translated), for the current\n>> > user right now (current i18n), and for sharing with other humans\n>> > (i18n.projectlang).\n>> \n>> Anything you see as a user is potentially useful to other project\n>> participants, so I do not think there is a bright line that\n>> delineates the latter two classes. The output of format-patch is\n>> obviously meant as the latter, but how about the output from show or\n>> log? Is it worth trying to define the bright line somewhere, only\n>> to annoy users who may want to draw the line differently?\n>\n> I agree that the line is not bright. I do not know if it is worthwhile\n> or not. I think it will solve some practical problems, but it may also\n> introduce others. But basically having a per-repo LANG setting (which\n> is what the projectlang you are talking about would do) also does not\n> seem like a solution that people will use, because they will not get any\n> localization benefit at all.\n>\n> So again, I'd rather err on the side of pushing those things that are\n> near the line into the \"do not translate\" side, letting people use LANG\n> to localize the rest, and accepting that occasionally people are going\n> to accidentally show you output in a language you don't understand. But\n> hopefully that keeps it to \"occasionally\" and not \"every time you send\n> out a patch\".\n\nI am confused asto what you really want. In a Klingon-only project,\nI think it is perfectly fine to localize the diffstat summary line\nto Klingon. It is not machine readble, and it is not personal, but\nit is to be shared with project members, who all speak Klingon.\n\nPushing more things to \"do not translate\" side of the line means\nrobbing the benefit of i18n from people, no?\n"},{"id":"198984","messageId":"20120914001117.GA31647@sigill.intra.peff.net","threadId":"31360","inReplyTo":"7vehm561eq.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Revert diffstat back to English","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-09-14T00:11:17Z","receivedAt":"2012-09-14T00:11:17Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 13, 2012 at 02:47:09PM -0700, Junio C Hamano wrote:\n\n> > I agree that the line is not bright. I do not know if it is worthwhile\n> > or not. I think it will solve some practical problems, but it may also\n> > introduce others. But basically having a per-repo LANG setting (which\n> > is what the projectlang you are talking about would do) also does not\n> > seem like a solution that people will use, because they will not get any\n> > localization benefit at all.\n> >\n> > So again, I'd rather err on the side of pushing those things that are\n> > near the line into the \"do not translate\" side, letting people use LANG\n> > to localize the rest, and accepting that occasionally people are going\n> > to accidentally show you output in a language you don't understand. But\n> > hopefully that keeps it to \"occasionally\" and not \"every time you send\n> > out a patch\".\n> \n> I am confused asto what you really want. In a Klingon-only project,\n> I think it is perfectly fine to localize the diffstat summary line\n> to Klingon. It is not machine readble, and it is not personal, but\n> it is to be shared with project members, who all speak Klingon.\n> \n> Pushing more things to \"do not translate\" side of the line means\n> robbing the benefit of i18n from people, no?\n\nYes. But you cannot please both sides without creating a third category,\nas you noted. If you do not translate diffstat, then Klingon-only projects are\nunhappy. If you do translate, then projects run in LANG=C will either\nget public Klingon, or the project members will turn off all translation\nand lose all benefit of i18n.\n\nSo for the time being, I would rather choose LANG=C as a lingua franca\nand err on the side of interoperability with other people and not\ntranslating. And then if and when somebody feels like putting the effort\ninto doing i18n.projectlang by splitting out a third category, they are\nwelcome to. I just do not see much point in doing i18n.projectlang any\nother way.\n\nBut again, please don't take my input with too much force. I am\npersonally perfectly happy to live in LANG=C the rest of my life. I\nreally started on this topic just by responding to your \"I guess nobody\nminds the Klingon...\" statement. I do find it a little annoying, but I\ncan learn to live with it if that is significantly easier.\n\n-Peff\n"},{"id":"199021","messageId":"505309EC.8040400@drmicha.warpmail.net","threadId":"31360","inReplyTo":"20120913180056.GA1696@sigill.intra.peff.net","subject":"Re: [PATCH RFC 0/2] Mixing English and a local language","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-09-14T10:41:48Z","receivedAt":"2012-09-14T10:41:48Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jeff King venit, vidit, dixit 13.09.2012 20:00:\n> On Thu, Sep 13, 2012 at 10:30:52AM -0700, Junio C Hamano wrote:\n> \n>>> But it should not be per-command, but per-message, and\n>>> should include all output that is not diagnostic and is not\n>>> machine-parseable (e.g., what I mentioned above, request-pull\n>>> output, etc). If it is the project's language, then the team\n>>> members will need to know it anyway, so it should not be too big a\n>>> burden to have a potentially different language there than in the\n>>> diagnostic messages.\n>>\n>> No matter what the project languages is, machine parseable part will\n>> not be localized but fixed to \"C\" anyway, so I do not think it comes\n>> into the picture.\n> \n> But there are parts that are neither machine-parseable nor diagnostics.\n> The diffstat is one, but I mentioned others. Are those going to be\n> forever fixed to LANG=C?\n> \n> That does not bother me, but for a project whose team works entirely in\n> Japanese (both individually, and when sharing code), they will still be\n> stuck with these English-language snippets, and no way to localize them.\n> Even though they may not speak a word of it.\n> \n> I have no idea if such a team is a strawman or not; that is why I\n> separated points 1 and 2. We can wait on point 2 until such a team shows\n> up and complains (of course, they would have to come here and complain\n> in English, so...).\n> \n>> My take on this is, if there is the project language, it should\n>> apply to _everything_. Please do not introduce any per-command,\n>> per-message, per-anything mess. Just set LANG/LC_ALL up and be done\n>> with it.\n> \n> But isn't that arguing for localizing diffstat? It is not\n> machine-parseable, so an all-Japanese team would want to localize it\n> along with their diagnostics.\n> \n> -Peff\n> \n\nThe basic assumption is that we have people who are proficient in at\nleast 2 languages. In fact, the initial i18n efforts were targeted at\npeople who are much more comfortable in their $LANG than with LANG=C.\nFor this category, being able to localize everything(*) is important.\nThey will mostly work with $LANG projects. I don't think they're strawmen.\n\nFor those proficient in 2 languages it's desirable to switch per project\nbecause it's likely they participate in projects with different $LANG\npreferences. Again, that means localizing everything(*). Additionally,\nsetting core.i18n in global config is probably the better choice\n(compared to NO_GETTEXT=y) for those who are frustrated by git's\ntranslation in their usual $LANG.\n\n[git svn should pass that LANG to svn also etc.]\n\nThe question is whether we have people who prefer to work with git in\ntheir $LANG even though project interaction requires a different\nlanguage. They would probably run log/gitk/commit... in their $LANG but\nneed format-patch and the like in project-lang.\n\nI do think we have people in this category here on the list, so they\nshould speak up ;) Could they alias their format-patch to use \"-c\ncore.i18n=C\" or such? Or have .i18n on top? per-command config\nagain ;)\n\nMichael\n"},{"id":"199023","messageId":"CACsJy8DKUdn-eY1P1d6vFz34SvEbUBm07ZR3xy5xLaKxE+Wnqg@mail.gmail.com","threadId":"31360","inReplyTo":"505309EC.8040400@drmicha.warpmail.net","subject":"Re: [PATCH RFC 0/2] Mixing English and a local language","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-09-14T11:35:20Z","receivedAt":"2012-09-14T11:35:20Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Sep 14, 2012 at 5:41 PM, Michael J Gruber\n wrote:\n> For those proficient in 2 languages it's desirable to switch per project\n> because it's likely they participate in projects with different $LANG\n> preferences. Again, that means localizing everything(*). Additionally,\n> setting core.i18n in global config is probably the better choice\n> (compared to NO_GETTEXT=y) for those who are frustrated by git's\n> translation in their usual $LANG.\n>\n> [git svn should pass that LANG to svn also etc.]\n\nWe should honor LINGUAS variable on installation. Only languages\nlisted in that variable are installed. Many if not most of projects do\nthat already. That's probably better than yet another switch.\n\n> The question is whether we have people who prefer to work with git in\n> their $LANG even though project interaction requires a different\n> language. They would probably run log/gitk/commit... in their $LANG but\n> need format-patch and the like in project-lang.\n>\n> I do think we have people in this category here on the list, so they\n> should speak up ;) Could they alias their format-patch to use \"-c\n> core.i18n=C\" or such? Or have .i18n on top? per-command config\n> again ;)\n\nProbably not needed, but probably won't hurt repeating: I do :) And\nthings should just work, at least most of the time. When I set LANG, I\nprefer to have everything in $LANG unless required otherwise (sending\nto English speaking teams is one of them). But the exceptions should\nbe limited.\n\nOn Fri, Sep 14, 2012 at 12:52 AM, Junio C Hamano wrote:\n> You seem to be saying that diagnostic does not have to be in project\n> language, but I do not think it is the right thing to do. The first\n> response to \"Frotz does not work\" is often \"What do you exactly\n> mean? How did you run Frotz? What error message are you getting\n> from it?\", and you do not want to get back the diagnostics ints\n> Klingon.\n\nWhether you like it or not, all localized software has this problem.\nPerhaps the only difference with commercial software is that they have\nsupport line that also understands Klingon. I don't see any problems\nwith asking the reporter to translate error messages back to English,\nassume that they report in English so they do know English. Given a\nspecific context, Klingon illiterates can even manually revert Klingon\ntext back to English because we have the all the translations. But\nit's probably faster to just ask the reporter.\n-- \nDuy\n"},{"id":"199024","messageId":"CACsJy8DnrrB8Fp6xhL8reUgB8-KaQ4Hb9OrEKMupaH70mUqzOw@mail.gmail.com","threadId":"31360","inReplyTo":"20120914001117.GA31647@sigill.intra.peff.net","subject":"Re: [PATCH] Revert diffstat back to English","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-09-14T11:56:24Z","receivedAt":"2012-09-14T11:56:24Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Sep 14, 2012 at 7:11 AM, Jeff King wrote:\n> On Thu, Sep 13, 2012 at 02:47:09PM -0700, Junio C Hamano wrote:\n>\n>> > I agree that the line is not bright. I do not know if it is worthwhile\n>> > or not. I think it will solve some practical problems, but it may also\n>> > introduce others. But basically having a per-repo LANG setting (which\n>> > is what the projectlang you are talking about would do) also does not\n>> > seem like a solution that people will use, because they will not get any\n>> > localization benefit at all.\n>> >\n>> > So again, I'd rather err on the side of pushing those things that are\n>> > near the line into the \"do not translate\" side, letting people use LANG\n>> > to localize the rest, and accepting that occasionally people are going\n>> > to accidentally show you output in a language you don't understand. But\n>> > hopefully that keeps it to \"occasionally\" and not \"every time you send\n>> > out a patch\".\n>>\n>> I am confused asto what you really want. In a Klingon-only project,\n>> I think it is perfectly fine to localize the diffstat summary line\n>> to Klingon. It is not machine readble, and it is not personal, but\n>> it is to be shared with project members, who all speak Klingon.\n>>\n>> Pushing more things to \"do not translate\" side of the line means\n>> robbing the benefit of i18n from people, no?\n>\n> Yes. But you cannot please both sides without creating a third category,\n> as you noted. If you do not translate diffstat, then Klingon-only projects are\n> unhappy. If you do translate, then projects run in LANG=C will either\n> get public Klingon, or the project members will turn off all translation\n> and lose all benefit of i18n.\n\nI agree with Jeff on this. And \"everything in $projectlang\" is just\nlike \"everything in C\", the problem remains. Suppose Chinese becomes a\nvery popular language (if it has not been so), projects with dominant\nChinese people would prefer Chinese. But large enough projects will\ninvolve non-Chinese people who prefer their native non-Chinese\nlanguage as UI.\n\nI'm not pushing \"do not translate\" side. I just postpone it until a\nproper approach is found (preferably by Klingon teams who are upset\nabout this \"do not translate\" patch). Supporting two non-C languages\nat the same time could be done (not very elegantly) by forking a\nprocess with the second language, which serves as gettext source for\nfirst process via pipes.\n\nThe problem is drawing a line between team strings and local strings\nwithout butchering git source code. We're going through sort of the\nsame process already, separating machine-readable strings and\ntranslatable strings. Maybe we can learn something before deciding\nwhether to add the team string class.\n\n> So for the time being, I would rather choose LANG=C as a lingua franca\n> and err on the side of interoperability with other people and not\n> translating. And then if and when somebody feels like putting the effort\n> into doing i18n.projectlang by splitting out a third category, they are\n> welcome to. I just do not see much point in doing i18n.projectlang any\n> other way.\n-- \nDuy\n"},{"id":"199027","messageId":"1347626418-14032-1-git-send-email-pclouds@gmail.com","threadId":"31360","inReplyTo":"CACsJy8DKUdn-eY1P1d6vFz34SvEbUBm07ZR3xy5xLaKxE+Wnqg@mail.gmail.com","subject":"[PATCH] Makefile: respect $LINGUAS variable on selecting .mo files to install","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-09-14T12:40:18Z","receivedAt":"2012-09-14T12:40:18Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n On Fri, Sep 14, 2012 at 6:35 PM, Nguyen Thai Ngoc Duy wrote:\n > We should honor LINGUAS variable on installation. Only languages\n > listed in that variable are installed. Many if not most of projects do\n > that already.\n\n And here is a try.\n\n Makefile | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/Makefile b/Makefile\nindex 56301dc..eeba645 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -2437,7 +2437,11 @@ po/git.pot: $(LOCALIZED_C)\n \n pot: po/git.pot\n \n+ifdef LINGUAS\n+POFILES := $(shell sh -c \"ls $(patsubst %,po/%.po,$(LINGUAS)) 2>/dev/null\")\n+else\n POFILES := $(wildcard po/*.po)\n+endif\n MOFILES := $(patsubst po/%.po,po/build/locale/%/LC_MESSAGES/git.mo,$(POFILES))\n \n ifndef NO_GETTEXT\n-- \n1.7.12.403.gce5cf6f.dirty\n"},{"id":"199030","messageId":"50532BCE.6070009@drmicha.warpmail.net","threadId":"31360","inReplyTo":"1347626418-14032-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] Makefile: respect $LINGUAS variable on selecting .mo files to install","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-09-14T13:06:22Z","receivedAt":"2012-09-14T13:06:22Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Nguyễn Thái Ngọc Duy venit, vidit, dixit 14.09.2012 14:40:\n> \n> Signed-off-by: Nguyễn Thái Ngọc Duy \n> ---\n> On Fri, Sep 14, 2012 at 6:35 PM, Nguyen Thai Ngoc Duy wrote:\n> > We should honor LINGUAS variable on installation. Only languages\n> > listed in that variable are installed. Many if not most of projects do\n> > that already.\n> \n> And here is a try.\n> \n> Makefile | 4 ++++\n> 1 file changed, 4 insertions(+)\n> \n> diff --git a/Makefile b/Makefile\n> index 56301dc..eeba645 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -2437,7 +2437,11 @@ po/git.pot: $(LOCALIZED_C)\n> \n> pot: po/git.pot\n> \n> +ifdef LINGUAS\n> +POFILES := $(shell sh -c \"ls $(patsubst %,po/%.po,$(LINGUAS)) 2>/dev/null\")\n> +else\n> POFILES := $(wildcard po/*.po)\n> +endif\n> MOFILES := $(patsubst po/%.po,po/build/locale/%/LC_MESSAGES/git.mo,$(POFILES))\n> \n> ifndef NO_GETTEXT\n> \n\nWhile that may be worthwhile if LINGUAS is some sort of standard I don't\nthink it relates to the discussion at hand. The problem is not the set\nto choose from but the choice and the specificity of the choice (which\nparts of the code does it affect).\n\nMichael\n"},{"id":"199042","messageId":"7vvcfg5yvo.fsf@alter.siamese.dyndns.org","threadId":"31360","inReplyTo":"1347545786-936-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH] Revert diffstat back to English","fromName":"Junio C Hamano","fromEmail":"junio@pobox.com","sentAt":"2012-09-14T16:54:03Z","receivedAt":"2012-09-14T16:54:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Nguyễn Thái Ngọc Duy writes:\n>\n>> This reverts the i18n part of 7f81463 (Use correct grammar in diffstat\n>> summary line - 2012-02-01) but still keeps the grammar correctness for\n>> English. It also reverts b354f11 (Fix tests under GETTEXT_POISON on\n>> diffstat - 2012-08-27). The result is diffstat always in English\n>> for all commands.\n>>\n>> This helps stop users from accidentally sending localized\n>> format-patch'd patches.\n>>\n>> Signed-off-by: Nguyễn Thái Ngọc Duy \n\nWhy am I getting this from t3300?\n\n --- expected 2012-09-14 16:43:09.000000000 +0000\n +++ current 2012-09-14 16:43:09.000000000 +0000\n @@ -1,2 +1,2 @@\n \"tabs\\t,\\\" (dq) and spaces\"\n - 1 file changed, 0 insertions(+), 0 deletions(-)\n + 1 files changed, 0 insertion(+), 0 deletion(-)\n\nAh, your rewrite of Q_() is wrong. Will squash the attached in\nbefore queueing this for maint.\n\nThanks.\n\n diff.c | 6 +++---\n 1 file changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git c/diff.c w/diff.c\nindex 3ddf0e6..1d9783c 100644\n--- c/diff.c\n+++ w/diff.c\n@@ -1401,7 +1401,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)\n \t}\n \n \tstrbuf_addf(&sb,\n-\t\t files ? \" %d files changed\" : \" %d file changed\",\n+\t\t (files == 1) ? \" %d file changed\" : \" %d files changed\",\n \t\t files);\n \n \t/*\n@@ -1418,7 +1418,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)\n \t\t * do not translate it.\n \t\t */\n \t\tstrbuf_addf(&sb,\n-\t\t\t insertions ? \", %d insertions(+)\" : \", %d insertion(+)\",\n+\t\t\t (insertions == 1) ? \", %d insertion(+)\" : \", %d insertions(+)\",\n \t\t\t insertions);\n \t}\n \n@@ -1428,7 +1428,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)\n \t\t * do not translate it.\n \t\t */\n \t\tstrbuf_addf(&sb,\n-\t\t\t deletions ? \", %d deletions(-)\" : \", %d deletion(-)\",\n+\t\t\t (deletions == 1) ? \", %d deletion(-)\" : \", %d deletions(-)\",\n \t\t\t deletions);\n \t}\n \tstrbuf_addch(&sb, '\\n');\n"},{"id":"199086","messageId":"CACsJy8BeuQaMTPCTzsyZo8KqE1V9iLDxrYB8fWT8_enq0iAg_g@mail.gmail.com","threadId":"31360","inReplyTo":"7vvcfg5yvo.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Revert diffstat back to English","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-09-15T02:41:23Z","receivedAt":"2012-09-15T02:41:23Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Sep 14, 2012 at 11:54 PM, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> Nguyễn Thái Ngọc Duy writes:\n>>\n>>> This reverts the i18n part of 7f81463 (Use correct grammar in diffstat\n>>> summary line - 2012-02-01) but still keeps the grammar correctness for\n>>> English. It also reverts b354f11 (Fix tests under GETTEXT_POISON on\n>>> diffstat - 2012-08-27). The result is diffstat always in English\n>>> for all commands.\n>>>\n>>> This helps stop users from accidentally sending localized\n>>> format-patch'd patches.\n>>>\n>>> Signed-off-by: Nguyễn Thái Ngọc Duy \n>\n> Why am I getting this from t3300?\n>\n> --- expected 2012-09-14 16:43:09.000000000 +0000\n> +++ current 2012-09-14 16:43:09.000000000 +0000\n> @@ -1,2 +1,2 @@\n> \"tabs\\t,\\\" (dq) and spaces\"\n> - 1 file changed, 0 insertions(+), 0 deletions(-)\n> + 1 files changed, 0 insertion(+), 0 deletion(-)\n>\n> Ah, your rewrite of Q_() is wrong. Will squash the attached in\n> before queueing this for maint.\n\nArghhh I found that and fixed it, but probably sent an old version. Thanks.\n-- \nDuy\n"}]}