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

Bug#347531: /usr/X11R6/lib/X11/locale/compose.dir: compose not working if LC_CTYPE=cs_CZ.UTF-8



On Wed, Jan 11, 2006 at 01:27:46PM +0100, David Martínez Moreno wrote:
> tag 347531 + pending
> thanks for the fish
> 
> El miércoles, 11 de enero de 2006 12:16, Marek Schmidt escribió:
> > Compose is not working in Qt-based applications (and in GTK applications
> > if input module set to xim) if LC_CTYPE=cs_CZ.UTF-8
> >
> > I've noticed that /usr/X11R6/lib/X11/locale/compose.dir contains lines
> > with cz_CZ.UTF-8:
> >
> > en_US.UTF-8/Compose             cz_CZ.UTF-8
> >
> > correct language code is "cs", not "cz" for czech language, though.
> >
> > It works OK when I replace cz_CZ.UTF-8 with cs_CZ.UTF-8 in compose.dir
> >
> > This error seems to be introduced by patch in
> > xorg-x11-6.9.0.dfsg.1/debian/patches/general/011a_recognize_glibc_2.3.2_loc
> >ale_names.diff
> 
> 	Hello, Marek. Well, this patch in fact removes the line:
> 
>  en_US.UTF-8/Compose:       ca_ES.UTF-8
> -en_US.UTF-8/Compose:       cs_CZ.UTF-8  <<<<
>  en_US.UTF-8/Compose:       cy_GB.UTF-8
>  en_US.UTF-8/Compose:       cz_CZ.UTF-8
>  en_US.UTF-8/Compose:       da_DK.UTF-8
> @@ -269,17 +333,28 @@
> 
> 	I am committing a fix for this, but I would prefer that Denis express his 
> opinion about this issue.

This removal was clearly an error, cz_CZ could have been dropped
instead.  But I see no reason to drop locales because they are not
supported by glibc.  They are sometimes legitimate (say Esperanto,
for instance, or Cyrillic languages with CP1251 encoding), users
have to generate their glibc locales by hand, and we make their
lives even harder by removing entries from this file.  We should
only add entries or fix existing ones like in the s/iso/ISO/ case,
not remove them.

Denis



Reply to: