Bug 43762 - inappropriate LANG (i18n locale) settings for servers
inappropriate LANG (i18n locale) settings for servers
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.1
All Linux
medium Severity low
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-06-06 23:01 EDT by Adam Thompson
Modified: 2007-04-18 12:33 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-06-06 23:01:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Thompson 2001-06-06 23:01:54 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Description of problem:
en_US is not an appropriate locale setting for servers.
"C" is a good choice.  Otherwise, you better provide an easy, WELL 
DOCUMENTED, way to change that.  [Editing /etc/rc.d/init.d/xinetd doesn't 
count as "easy"!]

One customer of mine was *VERY* pissed off when a localized daemon started 
answering in English instead of in French.

Guys, I appreciate the fact that you're trying to add locale support 
throughout, but HARDCODING IT TO en_US MADE THINGS WORSE, NOT BETTER!

You *DO* have non-American clients, after all.  On most systems, I use 
en_CA.  Which I cannot find any way to fix after installing 7.1, except by 
editing /etc/sysconfig/i18n directly.  This is annoying enough for me, 
when en_CA and en_US are almost identical.

It almost cost me a customer who doesn't like en_anything.  Ever.

BTW: how *am* I *supposed* to change default locales after installation?  
I can't find any tool to do so.


How reproducible:
Always

Steps to Reproduce:
1.  Install a daemon with localized French messages (fr_CA)
2.  Add LANG=fr_CA somewhere in the rc scripts to set the default LANG
3.  Set said daemon up to run out of xinetd.
4.  Watch it not pick up the default LANG setting because the xinetd start 
script OVERRIDES the locale setting.
5.  Watch consultant be accused of helping to promote American 
Imperialism.  *sigh*


Actual Results:  I almost got fired as a consultant.

Expected Results:  Language settings should
 a) default to "C", not "en_US" for the entire system
 b) **NEVER** be overridden based on American cultural assumptions.


Additional info:
Comment 1 Trond Eivind Glomsrxd 2001-06-06 23:12:18 EDT
en_US is "C", with working character order and 8 bit characters. It's set this
way to avoid locale settings being used: For externally accesible services like
ftp etc, using the local language is confusing for users and may destroy the
infromation in informational and error messages. Note that this obviously does
not affect content in the server - if the content was French, it will continue
to be so.
Comment 2 Adam Thompson 2001-06-06 23:31:41 EDT
Nonetheless, you've successfully broken historical behaviour.  There is no 
reason servers shouldn't use LANG settings.  For standard services like ftp, 
sendmail, etc... the "data" is the numeric response code, and the server 
*should* respond with cleartext messages of whatever the system's DEFAULT 
LOCALE IS.

Setting LANG=fr_CA at the end of rc scripts is not a _wrong_ way to set the 
system default language in prior versions of RedHat.  There may have been 
better ways (dunno) but it is certainly accepted practice among other unices.

My point is that you are OVERRIDING the administrator's locale preference.  
Protecting UNIX admins from themselves is NOT appropriate behaviour here.
Comment 3 Trond Eivind Glomsrxd 2001-06-06 23:38:49 EDT
ncftp / > get foobar
get foobar: server said: foobar: No such file or directory.
ncftp / >

There are very few circumstances where a non-English response is appropriate
there. I'm Norwegian myself, and my systems have the Norwegian locale as the
default - with the exception of external services like this. Why? Because the
message needs to be understood by whoever connects to it - and English is the
language the net is built upon for better or for worse.
Comment 4 Paul Gear 2003-08-13 05:39:12 EDT
See bug 91403 for an update on this issue.  It would be good if this bug were
updated to reflect the new solution.

Note You need to log in before you can comment on or make changes to this bug.