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

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

[Nguyễn Thái Ngọc Duy]

The l10n effort leads to a situation where a contributor can submit a
patch with some auto-generated information in his language, which may
not be the team's language. We need to make sure exchange medium like
patch is always in a common language that the team understands.

Now this team language may not necessarily be English. However there
are technical difficulties involved in switching between two
languages. The only way I can think of, on top of gettext, is provide
git translations in multiple domains. Say diff machinery uses
"git-diff" domain while the rest is in "git". We can drive gettext to
use language X for diff machinery, and Y for the rest. For that, we
replace gettext() with dgettext().

It's cumbersome. And there has not been any sign that there will be
a real user for it. So I assume that the "team language" will always
be English. It's simpler and should cover 90% of the user base. If
someday people ask for that, supporting it is simply a matter of
rewriting C_() and CQ_() macros in the first patch to use dgettext()
instead.

Switching between a language and English is easier. We just need an
if/else to decide whether to call gettext(). Which is what the first
patch does, just for certain parts of diff machinery. Error messages
will alway be in native language.

The second patch puts format-patch output in English unconditionally.
Again I'm partly lazy and not so sure that there will be needs for
format-patch to produce in native language. If someone needs it, we
can introduce a new config key that flip no_l10n flag back to 0.

More commands may follow format-patch. I think that 'apply' should also
use English for non-tty output, unless users request it to be in local
language. IOW local language is treated pretty much like coloring.

Nguyễn Thái Ngọc Duy (2):
  Allow to print diffstat in English regardless current locale
  format-patch: always print diffstat in English

 builtin/apply.c |  2 +-
 builtin/log.c   |  1 +
 diff.c          | 19 ++++++++++++-------
 diff.h          |  3 ++-
 4 files changed, 16 insertions(+), 9 deletions(-)

-- 
1.7.12.rc1.27.g6d3049b.dirty

[PATCH 1/2] Allow to print diffstat in English regardless current locale

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/apply.c |  2 +-
 diff.c          | 19 ++++++++++++-------
 diff.h          |  2 +-
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/builtin/apply.c b/builtin/apply.c
index d453c83..3f2779f 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3627,7 +3627,7 @@ static void stat_patch_list(struct patch *patch)
 		show_stats(patch);
 	}
 
-	print_stat_summary(stdout, files, adds, dels);
+	print_stat_summary(stdout, 0, files, adds, dels);
 }
 
 static void numstat_patch_list(struct patch *patch)
diff --git a/diff.c b/diff.c
index 95706a5..47d7e50 100644
--- a/diff.c
+++ b/diff.c
@@ -1390,18 +1390,21 @@ static void fill_print_name(struct diffstat_file *file)
 	file->print_name = pname;
 }
 
-int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
+int print_stat_summary(FILE *fp, int no_l10n, int files,
+		       int insertions, int deletions)
 {
+#define C_(s) (no_l10n ? s : _(s))
+#define CQ_(s1, s2, num) (no_l10n ? (num == 1 ? s1 : s2) : Q_(s1, s2, num))
 	struct strbuf sb = STRBUF_INIT;
 	int ret;
 
 	if (!files) {
 		assert(insertions == 0 && deletions == 0);
-		return fprintf(fp, "%s\n", _(" 0 files changed"));
+		return fprintf(fp, "%s\n", C_(" 0 files changed"));
 	}
 
 	strbuf_addf(&sb,
-		    Q_(" %d file changed", " %d files changed", files),
+		    CQ_(" %d file changed", " %d files changed", files),
 		    files);
 
 	/*
@@ -1418,7 +1421,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(+)",
+			    CQ_(", %d insertion(+)", ", %d insertions(+)",
 			       insertions),
 			    insertions);
 	}
@@ -1429,7 +1432,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(-)",
+			    CQ_(", %d deletion(-)", ", %d deletions(-)",
 			       deletions),
 			    deletions);
 	}
@@ -1437,6 +1440,8 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
 	ret = fputs(sb.buf, fp);
 	strbuf_release(&sb);
 	return ret;
+#undef C_
+#undef CQ_
 }
 
 static void show_stats(struct diffstat_t *data, struct diff_options *options)
@@ -1682,7 +1687,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
 		extra_shown = 1;
 	}
 	fprintf(options->file, "%s", line_prefix);
-	print_stat_summary(options->file, total_files, adds, dels);
+	print_stat_summary(options->file, 0, total_files, adds, dels);
 }
 
 static void show_shortstats(struct diffstat_t *data, struct diff_options *options)
@@ -1711,7 +1716,7 @@ static void show_shortstats(struct diffstat_t *data, struct diff_options *option
 				options->output_prefix_data);
 		fprintf(options->file, "%s", msg->buf);
 	}
-	print_stat_summary(options->file, total_files, adds, dels);
+	print_stat_summary(options->file, 0, total_files, adds, dels);
 }
 
 static void show_numstat(struct diffstat_t *data, struct diff_options *options)
diff --git a/diff.h b/diff.h
index e027650..eec79ef 100644
--- a/diff.h
+++ b/diff.h
@@ -329,7 +329,7 @@ extern struct userdiff_driver *get_textconv(struct diff_filespec *one);
 
 extern int parse_rename_score(const char **cp_p);
 
-extern int print_stat_summary(FILE *fp, int files,
+extern int print_stat_summary(FILE *fp, int no_l10n, int files,
 			      int insertions, int deletions);
 
 #endif /* DIFF_H */
-- 
1.7.12.rc1.27.g6d3049b.dirty

[PATCH 2/2] format-patch: always print diffstat in English

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 builtin/log.c | 1 +
 diff.c        | 4 ++--
 diff.h        | 1 +
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/builtin/log.c b/builtin/log.c
index ecc2793..62f4b7e 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1225,6 +1225,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 
 	/* Always generate a patch */
 	rev.diffopt.output_format |= DIFF_FORMAT_PATCH;
+	rev.diffopt.no_l10n = 1;
 
 	if (!DIFF_OPT_TST(&rev.diffopt, TEXT) && !no_binary_diff)
 		DIFF_OPT_SET(&rev.diffopt, BINARY);
diff --git a/diff.c b/diff.c
index 47d7e50..a20cfcc 100644
--- a/diff.c
+++ b/diff.c
@@ -1687,7 +1687,7 @@ static void show_stats(struct diffstat_t *data, struct diff_options *options)
 		extra_shown = 1;
 	}
 	fprintf(options->file, "%s", line_prefix);
-	print_stat_summary(options->file, 0, total_files, adds, dels);
+	print_stat_summary(options->file, options->no_l10n, total_files, adds, dels);
 }
 
 static void show_shortstats(struct diffstat_t *data, struct diff_options *options)
@@ -1716,7 +1716,7 @@ static void show_shortstats(struct diffstat_t *data, struct diff_options *option
 				options->output_prefix_data);
 		fprintf(options->file, "%s", msg->buf);
 	}
-	print_stat_summary(options->file, 0, total_files, adds, dels);
+	print_stat_summary(options->file, options->no_l10n, total_files, adds, dels);
 }
 
 static void show_numstat(struct diffstat_t *data, struct diff_options *options)
diff --git a/diff.h b/diff.h
index eec79ef..ea4075d 100644
--- a/diff.h
+++ b/diff.h
@@ -125,6 +125,7 @@ struct diff_options {
 	int dirstat_permille;
 	int setup;
 	int abbrev;
+	int no_l10n;
 	const char *prefix;
 	int prefix_length;
 	const char *stat_sep;
-- 
1.7.12.rc1.27.g6d3049b.dirty

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

[Nguyen Thai Ngoc Duy]

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'd like some form
of it in. Reverting the i18n diffstat patch is the last resort that I
really don't want to do.

On Sun, Aug 26, 2012 at 2:26 AM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> The l10n effort leads to a situation where a contributor can submit a
> patch with some auto-generated information in his language, which may
> not be the team's language. We need to make sure exchange medium like
> patch is always in a common language that the team understands.
>
> Now this team language may not necessarily be English. However there
> are technical difficulties involved in switching between two
> languages. The only way I can think of, on top of gettext, is provide
> git translations in multiple domains. Say diff machinery uses
> "git-diff" domain while the rest is in "git". We can drive gettext to
> use language X for diff machinery, and Y for the rest. For that, we
> replace gettext() with dgettext().
>
> It's cumbersome. And there has not been any sign that there will be
> a real user for it. So I assume that the "team language" will always
> be English. It's simpler and should cover 90% of the user base. If
> someday people ask for that, supporting it is simply a matter of
> rewriting C_() and CQ_() macros in the first patch to use dgettext()
> instead.
>
> Switching between a language and English is easier. We just need an
> if/else to decide whether to call gettext(). Which is what the first
> patch does, just for certain parts of diff machinery. Error messages
> will alway be in native language.
>
> The second patch puts format-patch output in English unconditionally.
> Again I'm partly lazy and not so sure that there will be needs for
> format-patch to produce in native language. If someone needs it, we
> can introduce a new config key that flip no_l10n flag back to 0.
>
> More commands may follow format-patch. I think that 'apply' should also
> use English for non-tty output, unless users request it to be in local
> language. IOW local language is treated pretty much like coloring.
>
> Nguyễn Thái Ngọc Duy (2):
>   Allow to print diffstat in English regardless current locale
>   format-patch: always print diffstat in English
>
>  builtin/apply.c |  2 +-
>  builtin/log.c   |  1 +
>  diff.c          | 19 ++++++++++++-------
>  diff.h          |  3 ++-
>  4 files changed, 16 insertions(+), 9 deletions(-)
>
> --
> 1.7.12.rc1.27.g6d3049b.dirty
>



-- 
Duy

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

[Junio C Hamano]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> 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.

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

[Jeff King]

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

[PATCH] Revert diffstat back to English

[Nguyễn Thái Ngọc Duy]

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 <pclouds@gmail.com>
---
 On Thu, Sep 13, 2012 at 8:28 PM, Jeff King <peff@peff.net> 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

Re: [PATCH] Revert diffstat back to English

[Jeff King]

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

Re: [PATCH] Revert diffstat back to English

[Junio C Hamano]

Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:

>  Git is still partly i18n-ized, turning a few strings back does not
>  seem a big regression.

More than one people explicitly said that they do not want to see
this in Klingon.  Even if the system is fully internationalized,
these "... (+), ... (-)" should never be localized, just like we
will never localize "diff --git", "index f00f..abcd", etc.

In other words, it is not a "regression" to begin with.  Turning
this back to "C" is a bugfix.  We shouldn't have had marked it with
_() in the first place.

>  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, that is true, too.

Re: [PATCH] Revert diffstat back to English

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>>  Git is still partly i18n-ized, turning a few strings back does not
>>  seem a big regression.
>
> More than one people explicitly said that they do not want to see
> this in Klingon.  Even if the system is fully internationalized,
> these "... (+), ... (-)" should never be localized, just like we
> will never localize "diff --git", "index f00f..abcd", etc.

Nah, I was being silly.  People complaining on Klingon on _this_
list does not argue for this to be in "C"; it just means the
i18n.projectlang for this project is "C".

How about _not_ reverting it and doing something like this instead?
I suspect that we may need to delay the call to git_setup_gettext()
in a similar way that we delay the call to commit_pager_choice(),
but that is a minor detail people smarter than I can surely figure
out ;-)

 git.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git i/git.c w/git.c
index 8788b32..a2cb9c8 100644
--- i/git.c
+++ w/git.c
@@ -51,6 +51,15 @@ int check_pager_config(const char *cmd)
 	return c.want;
 }
 
+static int project_lang_config(const char *var, const char *value, void *cb_data)
+{
+	if (!strcmp(var, "i18n.projectlang")) {
+		setenv("LANG", val, 1);
+		setenv("LC_ALL", val, 1);
+	}
+	return 0;
+}
+
 static void commit_pager_choice(void) {
 	switch (use_pager) {
 	case 0:
@@ -538,6 +547,7 @@ int main(int argc, const char **argv)
 	if (!cmd)
 		cmd = "git-help";
 
+	git_config(project_lang_config, NULL);
 	git_setup_gettext();
 
 	/*

Re: [PATCH] Revert diffstat back to English

[Jeff King]

On Thu, Sep 13, 2012 at 11:40:12AM -0700, Junio C Hamano wrote:

> > More than one people explicitly said that they do not want to see
> > this in Klingon.  Even if the system is fully internationalized,
> > these "... (+), ... (-)" should never be localized, just like we
> > will never localize "diff --git", "index f00f..abcd", etc.
> 
> Nah, I was being silly.  People complaining on Klingon on _this_
> list does not argue for this to be in "C"; it just means the
> i18n.projectlang for this project is "C".

Right, I think that is the case.

> How about _not_ reverting it and doing something like this instead?
> [...]
> +static int project_lang_config(const char *var, const char *value, void *cb_data)
> +{
> +	if (!strcmp(var, "i18n.projectlang")) {
> +		setenv("LANG", val, 1);
> +		setenv("LC_ALL", val, 1);
> +	}
> +	return 0;
> +}

Doesn't that mean that anyone working on git.git will never get to see
their localized language, even when it is not likely to be communicated
to the rest of the project? I am OK with that as a native speaker, but I
wonder what others would have to say.

I suspect we will end up with people not setting i18n.projectlang, and
getting Klingon diffstats on the list.

-Peff

Re: [PATCH] Revert diffstat back to English

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I suspect we will end up with people not setting i18n.projectlang, and
> getting Klingon diffstats on the list.

Yes, but when our starting point is that the diffstat summary is not
meant for machine consumption, which I tend to agree, that is a
logical consequence no matter how you cut it, no?  After all, they
want to be careless when running format-patch meant for _this_
project whose project language is C locale, but still want to be
able to see output that is not meant for machine consumption in
their native language, and these are incompatible goals.

Giving them a mechanism so that they do not have to remember setting
LANG/LC_ALL every time they context switch into this project would
be the best we can do, I am afraid.

Unless somebody has a better design that does not involve three
languages (always C, project language and Klingon), that is.

Re: [PATCH] Revert diffstat back to English

[Jeff King]

On Thu, Sep 13, 2012 at 02:10:41PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > I suspect we will end up with people not setting i18n.projectlang, and
> > getting Klingon diffstats on the list.
> 
> Yes, but when our starting point is that the diffstat summary is not
> meant for machine consumption, which I tend to agree, that is a
> logical consequence no matter how you cut it, no?  After all, they
> want to be careless when running format-patch meant for _this_
> project whose project language is C locale, but still want to be
> able to see output that is not meant for machine consumption in
> their native language, and these are incompatible goals.

I do not think they are incompatible if you separate it into three
categories: machine readable (must never be translated), for the current
user right now (current i18n), and for sharing with other humans
(i18n.projectlang).

Whether the maintenance of that three-way split is worthwhile, I don't
know (and that is why I said "in an ideal world..." in my original
mail, and left the implementation for people who care more). In the
meantime, before we have a working i18n.projectlang solution, which slot
should we put those messages in?

I'd argue for putting them in the machine-readable category, because it
is less likely to cause interoperability annoyances (and since git is
not fully translated anyway, we kind of assume at this point that people
know some basic phrases in the C locale).

And of course it is not fool-proof. The "for the current user right now"
messages may bleed into conversation with other people. But that cannot
be helped if we are to do any localization at all, and it does not seem
to be a big problem in practice. The only practical problem so far is
with certain meant-to-be-shared messages.

-Peff

Re: [PATCH] Revert diffstat back to English

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I do not think they are incompatible if you separate it into three
> categories: machine readable (must never be translated), for the current
> user right now (current i18n), and for sharing with other humans
> (i18n.projectlang).

Anything you see as a user is potentially useful to other project
participants, so I do not think there is a bright line that
delineates the latter two classes.  The output of format-patch is
obviously meant as the latter, but how about the output from show or
log?  Is it worth trying to define the bright line somewhere, only
to annoy users who may want to draw the line differently?

> Whether the maintenance of that three-way split is worthwhile, I don't
> know (and that is why I said "in an ideal world..." in my original
> mail, and left the implementation for people who care more). In the
> meantime, before we have a working i18n.projectlang solution, which slot
> should we put those messages in?
>
> I'd argue for putting them in the machine-readable category, because it
> is less likely to cause interoperability annoyances (and since git is
> not fully translated anyway, we kind of assume at this point that people
> know some basic phrases in the C locale).
>
> And of course it is not fool-proof. The "for the current user right now"
> messages may bleed into conversation with other people. But that cannot
> be helped if we are to do any localization at all, and it does not seem
> to be a big problem in practice. The only practical problem so far is
> with certain meant-to-be-shared messages.
>
> -Peff

Re: [PATCH] Revert diffstat back to English

[Jeff King]

On Thu, Sep 13, 2012 at 02:26:55PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > I do not think they are incompatible if you separate it into three
> > categories: machine readable (must never be translated), for the current
> > user right now (current i18n), and for sharing with other humans
> > (i18n.projectlang).
> 
> Anything you see as a user is potentially useful to other project
> participants, so I do not think there is a bright line that
> delineates the latter two classes.  The output of format-patch is
> obviously meant as the latter, but how about the output from show or
> log?  Is it worth trying to define the bright line somewhere, only
> to annoy users who may want to draw the line differently?

I agree that the line is not bright. I do not know if it is worthwhile
or not. I think it will solve some practical problems, but it may also
introduce others.  But basically having a per-repo LANG setting (which
is what the projectlang you are talking about would do) also does not
seem like a solution that people will use, because they will not get any
localization benefit at all.

So again, I'd rather err on the side of pushing those things that are
near the line into the "do not translate" side, letting people use LANG
to localize the rest, and accepting that occasionally people are going
to accidentally show you output in a language you don't understand. But
hopefully that keeps it to "occasionally" and not "every time you send
out a patch".

-Peff

Re: [PATCH] Revert diffstat back to English

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Thu, Sep 13, 2012 at 02:26:55PM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> > I do not think they are incompatible if you separate it into three
>> > categories: machine readable (must never be translated), for the current
>> > user right now (current i18n), and for sharing with other humans
>> > (i18n.projectlang).
>> 
>> Anything you see as a user is potentially useful to other project
>> participants, so I do not think there is a bright line that
>> delineates the latter two classes.  The output of format-patch is
>> obviously meant as the latter, but how about the output from show or
>> log?  Is it worth trying to define the bright line somewhere, only
>> to annoy users who may want to draw the line differently?
>
> I agree that the line is not bright. I do not know if it is worthwhile
> or not. I think it will solve some practical problems, but it may also
> introduce others.  But basically having a per-repo LANG setting (which
> is what the projectlang you are talking about would do) also does not
> seem like a solution that people will use, because they will not get any
> localization benefit at all.
>
> So again, I'd rather err on the side of pushing those things that are
> near the line into the "do not translate" side, letting people use LANG
> to localize the rest, and accepting that occasionally people are going
> to accidentally show you output in a language you don't understand. But
> hopefully that keeps it to "occasionally" and not "every time you send
> out a patch".

I am confused asto what you really want.  In a Klingon-only project,
I think it is perfectly fine to localize the diffstat summary line
to Klingon.  It is not machine readble, and it is not personal, but
it is to be shared with project members, who all speak Klingon.

Pushing more things to "do not translate" side of the line means
robbing the benefit of i18n from people, no?

Re: [PATCH] Revert diffstat back to English

[Jeff King]

On Thu, Sep 13, 2012 at 02:47:09PM -0700, Junio C Hamano wrote:

> > I agree that the line is not bright. I do not know if it is worthwhile
> > or not. I think it will solve some practical problems, but it may also
> > introduce others.  But basically having a per-repo LANG setting (which
> > is what the projectlang you are talking about would do) also does not
> > seem like a solution that people will use, because they will not get any
> > localization benefit at all.
> >
> > So again, I'd rather err on the side of pushing those things that are
> > near the line into the "do not translate" side, letting people use LANG
> > to localize the rest, and accepting that occasionally people are going
> > to accidentally show you output in a language you don't understand. But
> > hopefully that keeps it to "occasionally" and not "every time you send
> > out a patch".
> 
> I am confused asto what you really want.  In a Klingon-only project,
> I think it is perfectly fine to localize the diffstat summary line
> to Klingon.  It is not machine readble, and it is not personal, but
> it is to be shared with project members, who all speak Klingon.
> 
> Pushing more things to "do not translate" side of the line means
> robbing the benefit of i18n from people, no?

Yes. But you cannot please both sides without creating a third category,
as you noted. If you do not translate diffstat, then Klingon-only projects are
unhappy. If you do translate, then projects run in LANG=C will either
get public Klingon, or the project members will turn off all translation
and lose all benefit of i18n.

So for the time being, I would rather choose LANG=C as a lingua franca
and err on the side of interoperability with other people and not
translating. And then if and when somebody feels like putting the effort
into doing i18n.projectlang by splitting out a third category, they are
welcome to. I just do not see much point in doing i18n.projectlang any
other way.

But again, please don't take my input with too much force. I am
personally perfectly happy to live in LANG=C the rest of my life. I
really started on this topic just by responding to your "I guess nobody
minds the Klingon..." statement. I do find it a little annoying, but I
can learn to live with it if that is significantly easier.

-Peff

Re: [PATCH] Revert diffstat back to English

[Nguyen Thai Ngoc Duy]

On Fri, Sep 14, 2012 at 7:11 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Sep 13, 2012 at 02:47:09PM -0700, Junio C Hamano wrote:
>
>> > I agree that the line is not bright. I do not know if it is worthwhile
>> > or not. I think it will solve some practical problems, but it may also
>> > introduce others.  But basically having a per-repo LANG setting (which
>> > is what the projectlang you are talking about would do) also does not
>> > seem like a solution that people will use, because they will not get any
>> > localization benefit at all.
>> >
>> > So again, I'd rather err on the side of pushing those things that are
>> > near the line into the "do not translate" side, letting people use LANG
>> > to localize the rest, and accepting that occasionally people are going
>> > to accidentally show you output in a language you don't understand. But
>> > hopefully that keeps it to "occasionally" and not "every time you send
>> > out a patch".
>>
>> I am confused asto what you really want.  In a Klingon-only project,
>> I think it is perfectly fine to localize the diffstat summary line
>> to Klingon.  It is not machine readble, and it is not personal, but
>> it is to be shared with project members, who all speak Klingon.
>>
>> Pushing more things to "do not translate" side of the line means
>> robbing the benefit of i18n from people, no?
>
> Yes. But you cannot please both sides without creating a third category,
> as you noted. If you do not translate diffstat, then Klingon-only projects are
> unhappy. If you do translate, then projects run in LANG=C will either
> get public Klingon, or the project members will turn off all translation
> and lose all benefit of i18n.

I agree with Jeff on this. And "everything in $projectlang" is just
like "everything in C", the problem remains. Suppose Chinese becomes a
very popular language (if it has not been so), projects with dominant
Chinese people would prefer Chinese. But large enough projects will
involve non-Chinese people who prefer their native non-Chinese
language as UI.

I'm not pushing "do not translate" side. I just postpone it until a
proper approach is found (preferably by Klingon teams who are upset
about this "do not translate" patch). Supporting two non-C languages
at the same time could be done (not very elegantly) by forking a
process with the second language, which serves as gettext source for
first process via pipes.

The problem is drawing a line between team strings and local strings
without butchering git source code. We're going through sort of the
same process already, separating machine-readable strings and
translatable strings. Maybe we can learn something before deciding
whether to add the team string class.

> So for the time being, I would rather choose LANG=C as a lingua franca
> and err on the side of interoperability with other people and not
> translating. And then if and when somebody feels like putting the effort
> into doing i18n.projectlang by splitting out a third category, they are
> welcome to. I just do not see much point in doing i18n.projectlang any
> other way.
-- 
Duy

Re: [PATCH] Revert diffstat back to English

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
>
>> 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 <pclouds@gmail.com>

Why am I getting this from t3300?

    --- expected    2012-09-14 16:43:09.000000000 +0000
    +++ current     2012-09-14 16:43:09.000000000 +0000
    @@ -1,2 +1,2 @@
      "tabs\t,\" (dq) and spaces"
    - 1 file changed, 0 insertions(+), 0 deletions(-)
    + 1 files changed, 0 insertion(+), 0 deletion(-)

Ah, your rewrite of Q_() is wrong. Will squash the attached in
before queueing this for maint.

Thanks.

 diff.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git c/diff.c w/diff.c
index 3ddf0e6..1d9783c 100644
--- c/diff.c
+++ w/diff.c
@@ -1401,7 +1401,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
 	}
 
 	strbuf_addf(&sb,
-		    files ? " %d files changed" : " %d file changed",
+		    (files == 1) ? " %d file changed" : " %d files changed",
 		    files);
 
 	/*
@@ -1418,7 +1418,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
 		 * do not translate it.
 		 */
 		strbuf_addf(&sb,
-			    insertions ? ", %d insertions(+)" : ", %d insertion(+)",
+			    (insertions == 1) ? ", %d insertion(+)" : ", %d insertions(+)",
 			    insertions);
 	}
 
@@ -1428,7 +1428,7 @@ int print_stat_summary(FILE *fp, int files, int insertions, int deletions)
 		 * do not translate it.
 		 */
 		strbuf_addf(&sb,
-			    deletions ? ", %d deletions(-)" : ", %d deletion(-)",
+			    (deletions == 1) ? ", %d deletion(-)" : ", %d deletions(-)",
 			    deletions);
 	}
 	strbuf_addch(&sb, '\n');

Re: [PATCH] Revert diffstat back to English

[Nguyen Thai Ngoc Duy]

On Fri, Sep 14, 2012 at 11:54 PM, Junio C Hamano <junio@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
>>
>>> 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 <pclouds@gmail.com>
>
> Why am I getting this from t3300?
>
>     --- expected    2012-09-14 16:43:09.000000000 +0000
>     +++ current     2012-09-14 16:43:09.000000000 +0000
>     @@ -1,2 +1,2 @@
>       "tabs\t,\" (dq) and spaces"
>     - 1 file changed, 0 insertions(+), 0 deletions(-)
>     + 1 files changed, 0 insertion(+), 0 deletion(-)
>
> Ah, your rewrite of Q_() is wrong. Will squash the attached in
> before queueing this for maint.

Arghhh I found that and fixed it, but probably sent an old version. Thanks.
-- 
Duy

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

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

That part I sort-of understand.

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

No matter what the project languages is, machine parseable part will
not be localized but fixed to "C" anyway, so I do not think it comes
into the picture.

My take on this is, if there is the project language, it should
apply to _everything_.  Please do not introduce any per-command,
per-message, per-anything mess.  Just set LANG/LC_ALL up and be done
with it.

And I think you justified why that is the right thing to do very
well in the second sentence in the above paragraph I quoted from
you.

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>>      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.
>
> No matter what the project languages is, machine parseable part will
> not be localized but fixed to "C" anyway, so I do not think it comes
> into the picture.
>
> My take on this is, if there is the project language, it should
> apply to _everything_.  Please do not introduce any per-command,
> per-message, per-anything mess.  Just set LANG/LC_ALL up and be done
> with it.
>
> And I think you justified why that is the right thing to do very
> well in the second sentence in the above paragraph I quoted from
> you.

You seem to be saying that diagnostic does not have to be in project
language, but I do not think it is the right thing to do.  The first
response to "Frotz does not work" is often "What do you exactly
mean?  How did you run Frotz?  What error message are you getting
from it?", and you do not want to get back the diagnostics in
Klingon.

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

[Jeff King]

On Thu, Sep 13, 2012 at 10:52:08AM -0700, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> >>      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.
> >
> > No matter what the project languages is, machine parseable part will
> > not be localized but fixed to "C" anyway, so I do not think it comes
> > into the picture.
> >
> > My take on this is, if there is the project language, it should
> > apply to _everything_.  Please do not introduce any per-command,
> > per-message, per-anything mess.  Just set LANG/LC_ALL up and be done
> > with it.
> >
> > And I think you justified why that is the right thing to do very
> > well in the second sentence in the above paragraph I quoted from
> > you.
> 
> You seem to be saying that diagnostic does not have to be in project
> language, but I do not think it is the right thing to do.  The first
> response to "Frotz does not work" is often "What do you exactly
> mean?  How did you run Frotz?  What error message are you getting
> from it?", and you do not want to get back the diagnostics in
> Klingon.

By that line of reasoning, wouldn't all git developers be required to
set LANG=C? Fine by me as an English speaker, but I get the impression
that other developers are using the localization. I don't think there is
anything wrong with primarily working in your native language, but
making the effort to switch for communicating with teammates (either
when writing them emails, or using LANG=C when showing them output from
your terminal).

If the "switch to LANG=C" thing is a relatively rare thing, I don't see
a problem. The issue with the diffstat is that it is too easy to
accidentally send out a localized one.

-Peff

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

[Jeff King]

On Thu, Sep 13, 2012 at 10:30:52AM -0700, Junio C Hamano wrote:

> >      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.
> 
> No matter what the project languages is, machine parseable part will
> not be localized but fixed to "C" anyway, so I do not think it comes
> into the picture.

But there are parts that are neither machine-parseable nor diagnostics.
The diffstat is one, but I mentioned others. Are those going to be
forever fixed to LANG=C?

That does not bother me, but for a project whose team works entirely in
Japanese (both individually, and when sharing code), they will still be
stuck with these English-language snippets, and no way to localize them.
Even though they may not speak a word of it.

I have no idea if such a team is a strawman or not; that is why I
separated points 1 and 2. We can wait on point 2 until such a team shows
up and complains (of course, they would have to come here and complain
in English, so...).

> My take on this is, if there is the project language, it should
> apply to _everything_.  Please do not introduce any per-command,
> per-message, per-anything mess.  Just set LANG/LC_ALL up and be done
> with it.

But isn't that arguing for localizing diffstat? It is not
machine-parseable, so an all-Japanese team would want to localize it
along with their diagnostics.

-Peff

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

[Michael J Gruber]

Jeff King venit, vidit, dixit 13.09.2012 20:00:
> On Thu, Sep 13, 2012 at 10:30:52AM -0700, Junio C Hamano wrote:
> 
>>>      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.
>>
>> No matter what the project languages is, machine parseable part will
>> not be localized but fixed to "C" anyway, so I do not think it comes
>> into the picture.
> 
> But there are parts that are neither machine-parseable nor diagnostics.
> The diffstat is one, but I mentioned others. Are those going to be
> forever fixed to LANG=C?
> 
> That does not bother me, but for a project whose team works entirely in
> Japanese (both individually, and when sharing code), they will still be
> stuck with these English-language snippets, and no way to localize them.
> Even though they may not speak a word of it.
> 
> I have no idea if such a team is a strawman or not; that is why I
> separated points 1 and 2. We can wait on point 2 until such a team shows
> up and complains (of course, they would have to come here and complain
> in English, so...).
> 
>> My take on this is, if there is the project language, it should
>> apply to _everything_.  Please do not introduce any per-command,
>> per-message, per-anything mess.  Just set LANG/LC_ALL up and be done
>> with it.
> 
> But isn't that arguing for localizing diffstat? It is not
> machine-parseable, so an all-Japanese team would want to localize it
> along with their diagnostics.
> 
> -Peff
> 

The basic assumption is that we have people who are proficient in at
least 2 languages. In fact, the initial i18n efforts were targeted at
people who are much more comfortable in their $LANG than with LANG=C.
For this category, being able to localize everything(*) is important.
They will mostly work with $LANG projects. I don't think they're strawmen.

For those proficient in 2 languages it's desirable to switch per project
because it's likely they participate in projects with different $LANG
preferences. Again, that means localizing everything(*). Additionally,
setting core.i18n in global config is probably the better choice
(compared to NO_GETTEXT=y) for those who are frustrated by git's
translation in their usual $LANG.

[git svn should pass that LANG to svn also etc.]

The question is whether we have people who prefer to work with git in
their $LANG even though project interaction requires a different
language. They would probably run log/gitk/commit... in their $LANG but
need format-patch and the like in project-lang.

I do think we have people in this category here on the list, so they
should speak up ;) Could they alias their format-patch to use "-c
core.i18n=C" or such? Or have <command>.i18n on top? per-command config
again ;)

Michael

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

[Nguyen Thai Ngoc Duy]

On Fri, Sep 14, 2012 at 5:41 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> For those proficient in 2 languages it's desirable to switch per project
> because it's likely they participate in projects with different $LANG
> preferences. Again, that means localizing everything(*). Additionally,
> setting core.i18n in global config is probably the better choice
> (compared to NO_GETTEXT=y) for those who are frustrated by git's
> translation in their usual $LANG.
>
> [git svn should pass that LANG to svn also etc.]

We should honor LINGUAS variable on installation. Only languages
listed in that variable are installed. Many if not most of projects do
that already. That's probably better than yet another switch.

> The question is whether we have people who prefer to work with git in
> their $LANG even though project interaction requires a different
> language. They would probably run log/gitk/commit... in their $LANG but
> need format-patch and the like in project-lang.
>
> I do think we have people in this category here on the list, so they
> should speak up ;) Could they alias their format-patch to use "-c
> core.i18n=C" or such? Or have <command>.i18n on top? per-command config
> again ;)

Probably not needed, but probably won't hurt repeating: I do :) And
things should just work, at least most of the time. When I set LANG, I
prefer to have everything in $LANG unless required otherwise (sending
to English speaking teams is one of them). But the exceptions should
be limited.

On Fri, Sep 14, 2012 at 12:52 AM, Junio C Hamano <gitster@pobox.com> wrote:
> You seem to be saying that diagnostic does not have to be in project
> language, but I do not think it is the right thing to do.  The first
> response to "Frotz does not work" is often "What do you exactly
> mean?  How did you run Frotz?  What error message are you getting
> from it?", and you do not want to get back the diagnostics ints
> Klingon.

Whether you like it or not, all localized software has this problem.
Perhaps the only difference with commercial software is that they have
support line that also understands Klingon. I don't see any problems
with asking the reporter to translate error messages back to English,
assume that they report in English so they do know English. Given a
specific context, Klingon illiterates can even manually revert Klingon
text back to English because we have the all the translations. But
it's probably faster to just ask the reporter.
-- 
Duy

[PATCH] Makefile: respect $LINGUAS variable on selecting .mo files to install

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 On Fri, Sep 14, 2012 at 6:35 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
 > We should honor LINGUAS variable on installation. Only languages
 > listed in that variable are installed. Many if not most of projects do
 > that already.

 And here is a try.

 Makefile | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Makefile b/Makefile
index 56301dc..eeba645 100644
--- a/Makefile
+++ b/Makefile
@@ -2437,7 +2437,11 @@ po/git.pot: $(LOCALIZED_C)
 
 pot: po/git.pot
 
+ifdef LINGUAS
+POFILES := $(shell sh -c "ls $(patsubst %,po/%.po,$(LINGUAS)) 2>/dev/null")
+else
 POFILES := $(wildcard po/*.po)
+endif
 MOFILES := $(patsubst po/%.po,po/build/locale/%/LC_MESSAGES/git.mo,$(POFILES))
 
 ifndef NO_GETTEXT
-- 
1.7.12.403.gce5cf6f.dirty

Re: [PATCH] Makefile: respect $LINGUAS variable on selecting .mo files to install

[Michael J Gruber]

Nguyễn Thái Ngọc Duy venit, vidit, dixit 14.09.2012 14:40:
> 
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
>  On Fri, Sep 14, 2012 at 6:35 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>  > We should honor LINGUAS variable on installation. Only languages
>  > listed in that variable are installed. Many if not most of projects do
>  > that already.
> 
>  And here is a try.
> 
>  Makefile | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index 56301dc..eeba645 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2437,7 +2437,11 @@ po/git.pot: $(LOCALIZED_C)
>  
>  pot: po/git.pot
>  
> +ifdef LINGUAS
> +POFILES := $(shell sh -c "ls $(patsubst %,po/%.po,$(LINGUAS)) 2>/dev/null")
> +else
>  POFILES := $(wildcard po/*.po)
> +endif
>  MOFILES := $(patsubst po/%.po,po/build/locale/%/LC_MESSAGES/git.mo,$(POFILES))
>  
>  ifndef NO_GETTEXT
> 

While that may be worthwhile if LINGUAS is some sort of standard I don't
think it relates to the discussion at hand. The problem is not the set
to choose from but the choice and the specificity of the choice (which
parts of the code does it affect).

Michael