Re: why has mule gone all verbose?
Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes in xemacs-beta(a)xemacs.org:
>>>>> "sb" == SL Baur
<steve(a)xemacs.org> writes:
sb> GNU libc 2.0 does not support Asian
sb> locales, but GNU libc 2.1 reportedly does, though I haven't
sb> tested it yet.
I'm not sure I understand the ins and outs of Andy's problem,
but on
the Linux side this is a FAQ here in Japan. The problem is as you
say that XFree86 made a policy decision to disable the X11 locale
code.
This is not quite as dumb as forcing -rpath usage on linking X11
programs[1], but is right up there.
Since there are no Asian locales in glibc 2.0, this made many many
people unhappy. The usual solution was to downgrade to an older X11.
Most Japanese-capable Linux distributions (Debian-JP and TurboLinux)
have been using a dual libc5/libc6 solution (most apps are linked with
glibc-2 but the X11 libraries are linked against Linux libc5, yuck)
until very recently.
Urgh. Yuck is right.
...
I haven't heard anything about the Asian locale support in libc
2.1.
On the list of projects for January....
It's implemented for some definition of `implemented' (this is from
the test release glibc-2.0.108):
$ lf /usr/share/i18n/locales
POSIX en_AU es_AR es_MX eu_ES ga_IE ja_JP.ujis pt_PT tr_TR
cs_CZ en_CA es_BO es_PA fi_FI gr_GR kl_GL ro_RO zh_CN
da_DK en_CA,2.5 es_CL es_PE fo_FO he_IL lt_LT ru_RU
de_AT en_DK es_CO es_PY fr_BE hr_HR lv_LV ru_SU
de_BE en_DK.com es_DO es_SV fr_CA hu_HU nl_BE sk_SK
de_CH en_GB es_EC es_US fr_CA,2.13 is_IS nl_NL sl_SI
de_DE en_IE es_ES es_UY fr_CH it_IT no_NO sr_YU
de_LU en_NZ es_GT es_VE fr_FR iw_IL pl_PL sv_FI
el_GR en_US es_HN et_EE fr_LU ja_JP pt_BR sv_SE
Do you know of any non-X11 programs with localized Japanese messages
to test this with?
On a similar note, I've noted that recent versions of rxvt appear to
have Japanese functionality similar to the lightly maintained kterm.
Footnotes:
[1] They didn't do this for very long, but I was picking the lice out
of my system for over a year afterwards.