This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: CYGWIN=codepage? Or LC_CTYPE=foo?


Corinna Vinschen wrote:

> Should the tool just print "en_AU", or should it print "en_AU.UTF-8" to
> make UTF-8 the default?  Or should that be an option of the tool?  Just
> as a sidenote, some languages don't have a ANSI or OEM codepage attached
> and are always running in UNICODE mode.  For these the choice is clear.

For those locales where it's a choice, it should be configurable
somehow.  The worry that I have is that if we set UTF-8 unconditionally
in LANG that will also cause the effective value of LC_MESSAGES to
inherit that setting if LC_MESSAGES and LC_ALL are empty.  This in turn
will cause programs that use gettext to try to output UTF-8 localized
messages, and we embarrassingly don't have a UTF-8 capable terminal in
the distro so they will look like garbage.

Or perhaps what I'm saying is that if we set LANG=en_US.UTF-8 we also
need to set LC_MESSAGES=C.

Ironically, I always found it a little strange that there are so many
packages in the distro built with --enable-nls and loads of
/usr/share/locale/*/*.mo files, yet Cygwin has only ever shipped with
the C locale supported, so they are extraneous and unused in 99.99% of
cases unless somebody manually sets LC_MESSAGES.  And here we are
finally moving ahead to be able to change that and still we must use C
locale for messages due to lack of UTF-8 terminal.

> What about calling this tool only once in a postinstall script and
> creating a file /etc/sysconfig/i18n from the output which then gets
> evaluated in /etc/profile.d/lang.sh or lang.csh?

I assume the desire here is to minimize login shell startup time
penalty?  It's still an extra file to find/stat/source, and I doubt the
runtime of the tool would be more than a couple of w32api calls.  Doing
it once would also fail to catch cases where the user changes their
Windows locale.

I think we can keep the performance in check by adding the logic to the
base-files' 'profile' rather than adding a new file to profile.d, since
that must be executed anyway regardless.

Brian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]