#96 NLS support

[Joor Loohuis]

I've put together an example of (partial) National
Language Support (NLS) for NEdit, which I've tested on
Linux (glibc 2.2.5). The method I used (X/Open) only
requires basic support that should be part of any C
library. This example only internationalizes the
interface of the window title dialog (arbitratily
picked), and adds English and Dutch locales.

This first attempt is more a request for comments, and
will allow testing of the support for various
platforms. Please read the README.NLS in the tarball
for more information.

[Joor Loohuis]

NLS patch and example locales

[Joor Loohuis]

Logged In: YES
user_id=197101

I forgot to mention, the patch is against the nedit-5.4
source tree.

[Scott Tringali]

Logged In: YES
user_id=11321

Very cool. A few comments --

1) I think the locale files should live inside of ~/.nedit,
and we should automatically jigger NLSPATH as needed on
startup. This way users can just untar them into the right
spot and be done. One less thing for them to configure.

2) We could probably use some wrappers to the cagets calsl.
Mechanically translating them all makes the code a bit
uglier. A simple static function per module would probably
do the trick. Another one that returns an XmString would
also help.

[Joor Loohuis]

Logged In: YES
user_id=197101

Notice how the layout of the dialog changes when you switch
to the Dutch locale. That is something the Motif experts may
want to take a look at.

As for the location of the locales, we can even bypass
NLSPATH completely, since catopen can also be fed an
absolute path, so we can compile the path to the locales at
startup time.

Since my C coding skills are limited, I'd like to see an
example of the wrapper for the catgets calls. Is there
anything similar already in the code for another purpose?

[Joor Loohuis]

Logged In: YES
user_id=197101

One point in the current approach is that the locale in the
LC_MESSAGES env var is ignored, and the (supposedly)
deprecated LANG env var is used to determine the locale. A
little bit of experimentation shows that currently NEdit
doesn't use the LC_MESSAGES locale, but it does print a
warning if LANG contains a UTF8 locale. So, does this mean
that I don't need to support LC_MESSAGES? Is that a Motif
feature?

[Scott Tringali]

Logged In: YES
user_id=11321

1) The dialog constraints will need to looked at to make
sure they automatically resize properly when in another
"wordier" languages like German.

2) LANG and LC_ALL seem to feed the others, with LC_ALL
taking preference. Example:

[lid] tringali > echo $LANG
en_US.UTF-8

[lid] tringali > echo $LC_CTYPE
LC_CTYPE: Undefined variable.

[lid] tringali > locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

[lid] tringali > setenv LC_ALL en_US
[lid] tringali > locale
LANG=en_US.UTF-8
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=en_US

3) LC_MESSAGES should be set internally just fine, even if
the environmnet variable is missing. Run "locale" to see
what you get. The UTF warning only was a bug in LC_CTYPE,
so we only warn if it's found there (or fed by LC_ALL or
LANG).