|
List Info Thread: About Language.
[1-3]
|
||||||||||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||||||||||
About Language. |
|
List Info Thread: About Language.
[1-3]
|
||||||||||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||||||||||
gmail.com> wrote:
> Currently, there is an entry about letting the user to
decide
> about the Language. This is set to $LANG by default,
that means it
> will read the $LANG environment variable of the local
system (host).
>
> I am proposing to set it as default in C locale, for
three reasons.
I agree. I say set LANG=C. If anyone wants to take a chance
and format
messages in their language or something, they're free to
override
things with LC_*. But working with C sources when not in the
C locale
can have issues. See locale(7).
> I.
> Help us to narrow the errors. For example, and if I
remember correctly,
> the problem Dan had with the Dash shell, which
besides the bug, was
> causing because he was building from an en_US.UTF-8
locale. Dan
> correct me, if my memory fools me.
Right. The problem was that there was a script to generate a
btree of
builtins for dash. The script used sort, which is affected
by
LC_COLLATE. I had LANG=en_US.UTF-8 set and nothing else. The
result
was an improperly sorted binary tree, breaking dash. It was
not a fun
issue to track down, I promise you.
> II.
> Display of the messages, during the compilation.
> I have to say that, although it's hard for me to
express myself (sometimes)
> in English language, it makes absolutely no sense to
display the
> compiler messages in my native language. It's just
stupid.
> And not only the compiler messages, but all the
technical terms.
> English language is the standard in that regard and
should be used
> always.
IIRC, this is detrimental in the kernel, too. I believe
/proc/version
will end up localized, breaking scripts. This, I believe is
affected
by LC_MESSAGES. Alexander could fill in the details on that
one. He's
brought up before how not being in the C locale breaks the
kernel
build.
> It's the "Standard" C locale.
> By that alone, is enough reason for to recommend and
support only this
> locale.
In the context of compiling source code, I agree. Obviously,
you're
not saying that everyone should use the C locale at all
times. Then
when would I get to see all those fun Greek letters?
Maybe Alexander will drop a note in here, although I don't
know if he
reads alfs-discuss. I'm sure he would blast my level of
understanding
of locales, though 
--
Dan
--
