From: Junio C Hamano <hidden> Date: 2016-06-15 22:54:44
Jeff King [off-list ref] 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.
From: Jeff King <hidden> Date: 2016-06-15 22:54:44
On Thu, Sep 13, 2012 at 10:30:52AM -0700, Junio C Hamano wrote:
quoted
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
From: Michael J Gruber <hidden> Date: 2016-06-15 22:54:45
Jeff King venit, vidit, dixit 13.09.2012 20:00:
On Thu, Sep 13, 2012 at 10:30:52AM -0700, Junio C Hamano wrote:
quoted
quoted
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...).
quoted
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
On Fri, Sep 14, 2012 at 5:41 PM, Michael J Gruber
[off-list ref] 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 [off-list ref] 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
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
On Fri, Sep 14, 2012 at 6:35 PM, Nguyen Thai Ngoc Duy [off-list ref] 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(+)
From: Michael J Gruber <hidden> Date: 2016-06-15 22:54:45
Nguyễn Thái Ngọc Duy venit, vidit, dixit 14.09.2012 14:40:
quoted hunk
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
---
On Fri, Sep 14, 2012 at 6:35 PM, Nguyen Thai Ngoc Duy [off-list ref] 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(+)
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