Re: [PATCH] Revert diffstat back to English
On Fri, Sep 14, 2012 at 7:11 AM, Jeff King p...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert diffstat back to English
On Fri, Sep 14, 2012 at 11:54 PM, Junio C Hamano ju...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Nguyễn Thái Ngọc Duy pclo...@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 pclo...@gmail.com Why am I getting this from t3300? --- expected2012-09-14 16:43:09.0 + +++ current 2012-09-14 16:43:09.0 + @@ -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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert diffstat back to English
On Thu, Sep 13, 2012 at 09:16:26PM +0700, Nguyen Thai Ngoc Duy wrote: This reverts the i18n part of 7f81463 (Use correct grammar in diffstat summary line - 2012-02-01) but still keeps the grammar correctness for English. It also reverts b354f11 (Fix tests under GETTEXT_POISON on diffstat - 2012-08-27). The result is diffstat always in English for all commands. This helps stop users from accidentally sending localized format-patch'd patches. Yeah, this is exactly what I had in mind for now. Thanks. The for now sounds reasonable. Minimum annoyance is always good especially in a (largely?) volunteer-driven development environment like git. So I revert the i18n effect. Note that I don't optimize the changes for English only. The i18n might come back some day if we find a good way to do it. Git is still partly i18n-ized, turning a few strings back does not seem a big regression. I wonder if it would ever be fully so. Diffs will always have diff in them. Git-checkout will always be called checkout. It seems like learning a little bit of the original language is always necessary for command-line tools and machine-readable formats. 2. If people on non-English projects find that too cumbersome, then we can switch the English/C above for `i18n.projectlang` or something. But it should not be per-command, but per-message, and should include all output that is not diagnostic and is not machine-parseable (e.g., what I mentioned above, request-pull output, etc). If it is the project's language, then the team members will need to know it anyway, so it should not be too big a burden to have a potentially different language there than in the diagnostic messages. If you mean projectlang vs a local language, I looked into that and I don't think we could support two non-C languages using standard gettext interface. So it's either C vs another, or make use of unofficial gettext features, or roll your own. Yeah, I saw in your original message that it gets hairy. My statement was more about what we would want if there were no implementation obstacles. I'd leave it to later to decide the details. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert diffstat back to English
Junio C Hamano gits...@pobox.com writes:
Nguyễn Thái Ngọc Duy pclo...@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();
/*
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert diffstat back to English
On Thu, Sep 13, 2012 at 02:10:41PM -0700, Junio C Hamano wrote: Jeff King p...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
