Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Language dependent application defaults
Message-ID: <9002191915.AA01521@expire.lcs.mit.edu>
Date: 19 Feb 90 19:15:18 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 65


    From: Thomas Oeser
    The general issue should be to minimze the number of (language dependent)
    files that are necessary to run an application

The use of catgets does not reduce the number of files (compared with using
X resource files), it merely puts them in a different place.

    From: Erik M. van der Poel
    Basically, what I'm trying to say is that not everyone has catgets().

As far as I know, the X/Open messaging system has not yet been accepted by the
formal standards bodies (e.g. ANSI X3J11 (C) or IEEE 1003 (POSIX)).

    From: Erik M. van der Poel

    It would be nice if we could separate the task of the programmer from that
    of the language specialist, but unfortunately it is not easy to make a
    clean separation.

X Consortium folk believe it is generally quite possible.

    Clearly, the Xlib-level programmer needs
    to distinguish between XDrawText() and XDrawText16().

Wrong.  We will be much better off if the Xlib programmer does not have to
distinguish.  A basic goal of internationalization work is that the programmer
should not need specific knowledge of the language/culture in use.  This
includes details about the encoding of strings, and the mapping to fonts.

    It should be possible for the program to find out which language the user
    has chosen by looking up a certain environment variable.

Well, setlocale() (see the ANSI C standard or X/Open's XPG) is a bit more
complicated than this.  Yes, the program can find this information out, but
in general it shouldn't need to know.

    Of course the application writer would not have to worry about these things
    if they were neatly packaged in widgets.

The widget writer shouldn't have to worry very much either.

    What we need to do is to migrate towards conventions where text is
    read from app-defaults files into ANSI C wide character wchar_t
    strings, for example.

It need not be wchar_t, it could remain multi-byte strings.  The particular
choice of representation (multi-byte vs. wchar_t) is a space/time tradeoff.
Both forms of interface are probably required.  What is essential is that
X provide sufficient abstractions so that the programmer need not be concerned
with language/culture details; that is, extending the "locale" concept to
X specifics.

    Several organizations are working on standards in this area.
    Perhaps some of those individuals would like to comment?

The X Consortium is very active in the area of internationalization.  It is
probably the most active discussion group we have at present.  For example, I
just returned from chairing a 2.5 day Consortium meeting in Tokyo on the
subject.  We are working not just on resource files, but also on keyboard
input and text display, not just at the Xt level, but at the Xlib level.  We
have reasonable representation from and interaction with people working on
internationalization in X/Open, OSF, UI, etc.  "Harmony" with the existing ANSI
C standard and ongoing work in POSIX is an important aspect of our work.  We
hope to have specifications out for public review in a few months.