[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sensible-x-terminal and x-terminal-emulator


From: Robert Bihlmeyer <robbe@orcus.priv.at>
Subject: Re: sensible-x-terminal and x-terminal-emulator
Date: 27 Jun 2000 11:52:01 +0200

> > Did you install locales package?  And more, you know, for example, 
> > LANG=de is not a correct specifiaction.  LANG=de_DE is correct.
> Yes, that was the problem. Although e.g. zh_CN still brings the same
> message, even though /usr/share/local/zh_CN exists.

zh_CN.GB2312 is the correct locale name.  zh_CN is not.
And more, you need locale-zh package because GNU libc 2.1.x does
not support multibyte languages formally.

> > Though gettext works for LANG=de, I think the behavior of gettext
> > is against standard and it can be regarded as a bug.
> I don't think so. The Single Unix specification lists (in its
> "Environment Variables" chapter) a format of
>   language[_territory][.codeset]
> for these variables.

At first, though the format for variable is determined as you wrote,
which locale a system has to support is not determined.  GNU libc 2.1
(locale database [locales packages] is included in GNU libc.) supports
'de_DE' but doesn't support 'de'.  It is within discretion of GNU
libc developers.

Next, on condition that GNU libc supports 'de_DE' locale but doesn't
support 'de', gettext should obey the locale behavior of libc.

> > One problem.  s-x-t wants to fall into x-t-e if no $XTERMIAL is available
> > and no language-specific terminal is available.  If s-x-t calls x-t-e
> > and x-t-e is a link to s-x-t, it makes an infinite loop.
> s-x-t should not call x-t-e, but the original (diverted) version of
> x-t-e. For example, if you used
>   dpkg-divert --package sensible-x-terminal --divert \
>   /usr/bin/x-terminal-emulator.insensible /usr/bin/x-terminal-emulator
> you should call "/usr/bin/x-terminal-emulator.insensible".

I see.  However, I wonder what will occur if I installed some packages 
which provides /usr/bin/x-t-e after I installed s-x-t...

> > I think the best way is all X terminal emulators will be sensible
> > to LC_CTYPE locale and can display ASCII, ISO8859-*, ISO2022-*,
> > EUC-*, UTF-8, and so on.
> I don't think this will happen until the handling of those characters
> is made as easy by Xlib as the munging of ASCII. It's not for so long
> that 8-bit-cleanliness has been accepted as a virtue. Not even in
> theory I know what I have to care for to make my X apps work with
> non-8859 charsets.

I think this (what I said) will hardly happen...  Thus we need the
second best way, that is, s-x-t.

If you are interested in internationalizing your X apps, please read 
my document "Introduction to i18n" at Debian Documentation Project.
For usual X apps, use XFontSet-related functions such as XCreateFontSet
and XmbDrawString, instead of XFontStruct-related functions such
as XLoadQueryFont and XDrawString.  They are introduced since X11R5
and sensible to LC_CTYPE locale.  However, be careful that 
XFontSet-related functions use ASCII charset as a default
and 8-bit part is lost.  In short, at the beginning of your apps,
you should write:

    char *l = setlocale(LC_ALL, "");
    if (!l || !strcmp(l, "C") || !strcmp(l, "POSIX")) {
        useFontSet = False;
    } else {
        useFontSet = True;

and use XFontStruct-related functions if useFontSet=False.

However, X terminal emulators have more complicated problem because
it needs column-oriented process and needs to implement specific 
knowledge on each character set.

Tomohiro KUBOTA <kubota@debian.or.jp>

Reply to: