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

Re: Are we going with X_LOCALE or not?

On Fri, Sep 11, 1998 at 12:54:52PM +0900, Kaz Sasayama wrote:
> I was surprised when a new version of X packages
> were released, because it defined X_LOCALE even with the
> libc6 version.  So I ask:
> Are we going with X_LOCALE for any later version of libc6,
> or just for a version that does not support full i18n?

I'm reversing this change for the next release of xlib6g, and will continue
to build xlib6g without X_LOCALE for the forseeable future.

At the time I added the flag, I mistakenly thought it could do no harm, and
would instead simply permit those using East Asian locales to use X more

But as you've observed, there is a binary compatibility issue.
Furthermore, I've heard complaints from some Russians, so apparently
glibc's locale handling is better for them than X's.

On top of everything else, WindowMaker appears to break if X_LOCALE is

> What is important, IMHO, is to choose one and keep it
> unchanged until another big change happens either in libc or
> in X.  Do you have any plan?

I guess the best thing to do is hope that glibc 2.1 supports East Asian
locales.  In the meantime, I'm considering suggesting that those who need
East Asian locales turn to the Debian-JP project, who already do their own
builds of X to support such things.

Owen Taylor of Red Hat, who originally made the suggestion to define
X_LOCALE even in the libc6 build, said he might be able to hack up the Xlib
source to rely on C locales where available, and fall back on X ones when
they weren't.  I haven't considered all the ramifications of such a hack.

Sorry about the confusion.

G. Branden Robinson                 |  Reality is what refuses to go away when
Purdue University                   |  I stop believing in it.
branden@purdue.edu                  |  -- Philip K. Dick
http://www.ecn.purdue.edu/~branden/ |

Attachment: pgp0kofXuacOJ.pgp
Description: PGP signature

Reply to: