Bug#251000: xlibs-data: keeping /usr/share/i18n/SUPPORTED and /usr/X11R6/lib/X11/locale/locale.alias in sync.
Hi Andreas
It works in this case, but things are a little more complicated than
they should be. Please see below.
On Wed, May 26, 2004 at 12:59:18PM +0200, Andreas Metzler wrote:
> On Wed, May 26, 2004 at 11:14:51AM +0200, giuseppe bonacci wrote:
> > Package: xlibs-data
> > Version: 4.3.0.dfsg.1-1
> > Severity: wishlist
> > Tags: l10n
>
> > This seems to be a cross-package issue, but I think this is the best
> > place to raise it. I know I could play with config files and solve the
> > problem for my pc, but that would not be useful to other users.
> >
> > I need a system meeting three conditions:
> >
> > - use English localization for messages, numerics, date conversions and
> > so on. (this suggests C or en_US)
>
> No ...
>
> > - use a charset including the Euro symbol. (this suggests ISO-8859-15 or
> > UTF-8)
>
> > - have 8 bit long characters. (this rules out UTF-8)
>
> ... this suggest using leaving LANG unset and only setting LC_CTYPE to
> it_IT@euro. (No idea whether this is supported by xlibs.) The whole
> point of the different LC-variables is that you can selectively set
> them.
>
But... I did never mention Italy! How could you know I have it_IT@euro
available? And what if I were a Turkish-speaking Zurich-based banker,
exchanging euros with the rest of Europe? :-)
Seriously: why generate a locale it_IT@euro that I don't need? The
only thing I need is a particular charset. I know, one cannot decouple
locale information and charset, but at the very end en_US.UTF-8 and
en_US.ISO-8859-15 should be equally legitimate, and differing in the
charset only.
Moreover: for the Euro community, there are XXXX@euro aliases, but if
you think .e.g. of ISO-8859-2 (simply a charset, no relationship with
the country where you live), there is not such shortcut.
In short, (after making sure /etc/locale.gen included both
en_US.ISO-8859-15 and it_IT@euro) I tried in bash the following commands,
and I cannot understand the results:
$ unset LANG
$ LC_CTYPE=it_IT@euro xterm
$ LC_CTYPE=en_US.ISO-8859-15 xterm &
Warning: locale not supported by Xlib, locale set to C
Why does the first locale works while the second does not?
> BTW, don't you use A4 in Italy?
Yes, we do.
>
> > When I 'dpkg-reconfigure locales', my best choice is to generate
> > en_US.ISO-8859-15 (also listed in /usr/share/i18n/SUPPORTED), and set LANG
> > (or LC_ALL) accordingly.
>
> How about en_IE@euro?
>
> [...]
> > Now, what about trying to keep xlibs-data's information in sync with
> > locales' information? Maybe it suffices to have the postinst script for
> > xlibs-data _merge_ entries from /usr/share/i18n/SUPPORTED (if present)
> > into /usr/X11R6/lib/X11/locale/locale.alias, after remapping ISO-8859-x
> > to ISO8859-x.
>
> This indeed would be nice.
> cu andreas
Unfortunately, this doesn't seem to work as smoothly as I thought. In
fact, after quite a few experiments, I could not yet manage to have my
xlibs-data bless en_US.ISO-8859-15. Now I will try Voodoo.
Reply to: