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

Nguyen Thai Ngoc Duy [off-list ref] writes:

Should I interpret the silence as "I don't care, if you want it, go
for it" or "not acceptable, but no reasons given"?

I do not speak for the others, but the reason I didn't respond is
none of the above. It is somewhere between "Meh" and "Anything that
says 'local language' and 'English' cannot be worth looking at."

I _think_ the patch was inspired by $gmane/204979, where I said:

    Or "LC_ALL=C LANG=C git format-patch ...".

    It does not bother me (even though I do not read Vietnamese), but
    this has been brought up a few times, and we may want to revert the
    i18n of the diffstat summary.  It does not seem to add much value to
    the system but annoys people.  After all, the "upstream" diffstat
    does not localizes this string (I just checked diffstat-1.55 with
    Jan 2012 timestamp).

and I have been waiting to see what others think.  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.

It is bad enough having to decide where the boundary between 'local
language' and 'C locale' should be drawn in the mixture.  I am not
enthused by an attempt to make the boundary tweakable, and worse
yet, to do so per command.

IMHO, we should just decide where to draw the line and be done with
it.  The users already know or can be trained to know to choose the
greatest common denominator when interacting with others.

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

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.

Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
 On Thu, Sep 13, 2012 at 8:28 PM, Jeff King [off-list ref] wrote:
 >   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.

 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.

 >   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.

 diff.c                        | 10 ++++------
 t/t4006-diff-mode.sh          |  8 ++++----
 t/t4202-log.sh                |  2 +-
 t/t4205-log-pretty-formats.sh |  4 ++--
 t/t7508-status.sh             |  2 +-
 5 files changed, 12 insertions(+), 14 deletions(-)

diff --git a/diff.c b/diff.c
index e6846ca..8c23b9c 100644
--- a/diff.c
+++ b/diff.c

@@ -1398,11 +1398,11 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
 
 	if (!files) {
 		assert(insertions == 0 && deletions == 0);
-		return fprintf(fp, "%s\n", _(" 0 files changed"));
+		return fprintf(fp, "%s\n", " 0 files changed");
 	}
 
 	strbuf_addf(&sb,
-		    Q_(" %d file changed", " %d files changed", files),
+		    files ? " %d files changed" : " %d file changed",
 		    files);
 
 	/*

@@ -1419,8 +1419,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
 		 * do not translate it.
 		 */
 		strbuf_addf(&sb,
-			    Q_(", %d insertion(+)", ", %d insertions(+)",
-			       insertions),
+			    insertions ? ", %d insertions(+)" : ", %d insertion(+)",
 			    insertions);
 	}
 

@@ -1430,8 +1429,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
 		 * do not translate it.
 		 */
 		strbuf_addf(&sb,
-			    Q_(", %d deletion(-)", ", %d deletions(-)",
-			       deletions),
+			    deletions ? ", %d deletions(-)" : ", %d deletion(-)",
 			    deletions);
 	}
 	strbuf_addch(&sb, '\n');

diff --git a/t/t4006-diff-mode.sh b/t/t4006-diff-mode.sh
index 3d4b1ba..7a3e1f9 100755
--- a/t/t4006-diff-mode.sh
+++ b/t/t4006-diff-mode.sh

@@ -36,24 +36,24 @@ test_expect_success '--stat output after text chmod' '
 	test_chmod -x rezrov &&
 	echo " 0 files changed" >expect &&
 	git diff HEAD --stat >actual &&
-	test_i18ncmp expect actual
+	test_cmp expect actual
 '
 
 test_expect_success '--shortstat output after text chmod' '
 	git diff HEAD --shortstat >actual &&
-	test_i18ncmp expect actual
+	test_cmp expect actual
 '
 
 test_expect_success '--stat output after binary chmod' '
 	test_chmod +x binbin &&
 	echo " 0 files changed" >expect &&
 	git diff HEAD --stat >actual &&
-	test_i18ncmp expect actual
+	test_cmp expect actual
 '
 
 test_expect_success '--shortstat output after binary chmod' '
 	git diff HEAD --shortstat >actual &&
-	test_i18ncmp expect actual
+	test_cmp expect actual
 '
 
 test_done

diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index 924ba53..b3ac6be 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh

@@ -813,7 +813,7 @@ sanitize_output () {
 test_expect_success 'log --graph with diff and stats' '
 	git log --graph --pretty=short --stat -p >actual &&
 	sanitize_output >actual.sanitized <actual &&
-	test_i18ncmp expect actual.sanitized
+	test_cmp expect actual.sanitized
 '
 
 test_expect_success 'dotdot is a parent directory' '

diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 2c45de7..4afd778 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh

@@ -88,7 +88,7 @@ test_expect_success 'NUL separation with --stat' '
 	stat1_part=$(git diff --stat --root HEAD^) &&
 	printf "add bar\n$stat0_part\n\0initial\n$stat1_part\n" >expected &&
 	git log -z --stat --pretty="format:%s" >actual &&
-	test_i18ncmp expected actual
+	test_cmp expected actual
 '
 
 test_expect_failure 'NUL termination with --stat' '

@@ -96,7 +96,7 @@ test_expect_failure 'NUL termination with --stat' '
 	stat1_part=$(git diff --stat --root HEAD^) &&
 	printf "add bar\n$stat0_part\n\0initial\n$stat1_part\n\0" >expected &&
 	git log -z --stat --pretty="tformat:%s" >actual &&
-	test_i18ncmp expected actual
+	test_cmp expected actual
 '
 
 test_done

diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index e313ef1..c206f47 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh

@@ -80,7 +80,7 @@ test_expect_success 'status --column' '
 #	dir1/untracked dir2/untracked untracked
 #	dir2/modified  output
 EOF
-	test_i18ncmp expect output
+	test_cmp expect output
 '
 
 cat >expect <<\EOF

-- 
1.7.12.396.g87e837f.dirty

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