Thread (6 messages) flat view 6 messages, 4 authors, 2016-06-15

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

From: Nguyen Thai Ngoc Duy <hidden>
Date: 2016-06-15 22:54:45

Possibly related (same subject, not in this thread)

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help