Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#96 NLS support

open
nobody
Program (79)
5
2003-12-29
2003-12-29
Joor Loohuis
No

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.

Discussion

  • Joor Loohuis
    Joor Loohuis
    2003-12-29

    NLS patch and example locales

     
    Attachments
  • Joor Loohuis
    Joor Loohuis
    2003-12-29

    Logged In: YES
    user_id=197101

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

     
  • Scott Tringali
    Scott Tringali
    2003-12-29

    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
    Joor Loohuis
    2003-12-30

    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
    Joor Loohuis
    2004-01-03

    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
    Scott Tringali
    2004-01-03

    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).