Bug 81875

Based on this, libX11 needs to add a nls/cs_CZ.UTF-8 directory with a
Compose.pre which includes X11_LOCALEDATADIR/en_US.UTF-8/Compose and
overrides <dead_caron> <u> and <dead_caron> <U>.

I’m less certain of what the XI18N_OBJS and XLC_LOCALE.pre files should
look like.  In fi_FI.UTF-8, as an example, they are empty; the others
which include X11_LOCALEDATADIR/en_US.UTF-8/Compose have similar content
for XI18N_OBJS, but not so much for XLC_LOCALE.pre.

Created attachment 103653 [details] [review]
Patch to add cs_CZ.UTF-8/Compose.pre

@Vladimír:  please test this patch; the compose change should just work, but I’m not sure about the other two files in the nls directories.

Since you mention that you use xim, you are better able to test that part of the patch than I.

I expect to push this to libX11 git.

Hi,

thank you for your quick reply. I guess it's a patch agains xorg sources. At the moment I have no means of compiling xorg :( Nor I know what is the meaning of the two empty files ...

> I guess it's a patch agains xorg sources.

The Compose files come from libX11.

I tested it a bit, but I do not use XIM so cannot test that.

I pushed the change to the libX11 repository.

It still would help if someone who uses xim and cs_eCZ.UTF-8 were to
test it.

I'm sorry I can't be more helpful testing it. The patch adds three files
 - cs_CZ.UTF-8/Compose.pre
 - cs_CZ.UTF-8/XI18N_OBJS (empty)
 - cs_CZ.UTF-8/XLC_LOCALE.pre (empty)

At my opensuse installation I don't have any *.pre files or XI18N_OBJS files. I can confirm that if I open the file in utf-8 encoding the characters are correct.

Thank you
-- 
  Vlad

I tested the current git HEAD of libX11 and it doesn't work out of the box: The records in nls/locale.dir.pre still point to en_US instead of cs_CZ. After correcting that the composite combination ˇ + u = ů works correctly.

(In reply to vlmarek from comment #6)
> At my opensuse installation I don't have any *.pre files or XI18N_OBJS
> files. I can confirm that if I open the file in utf-8 encoding the
> characters are correct.

The "Compose.pre" is converted into "Compose" during build.

I'm confused, is there anything I can do to help with this issue?

Thanks!
__ 
  Vlad

I pushed 33840a5465a2e5fecab520bfbdd2d1bd0a456f51 with:

-en_US.UTF-8/XLC_LOCALE:                        cs_CZ.UTF-8
+cs_CZ.UTF-8/XLC_LOCALE:                        cs_CZ.UTF-8

I forgot about nls/locale.dir.pre when I wrote the earlier patch.

And then rememberred nls/compose.dir.pre, and pushed 5f0da8311a61498edf073cc877f5b467bfd5f863, too.

Thanks for taking care of this!

__ 
  Vlad

(In reply to James Cloos from comment #9)
> I pushed 33840a5465a2e5fecab520bfbdd2d1bd0a456f51 with:
> 
> -en_US.UTF-8/XLC_LOCALE:                        cs_CZ.UTF-8
> +cs_CZ.UTF-8/XLC_LOCALE:                        cs_CZ.UTF-8
> 
> I forgot about nls/locale.dir.pre when I wrote the earlier patch.
> 
> And then rememberred nls/compose.dir.pre, and pushed
> 5f0da8311a61498edf073cc877f5b467bfd5f863, too.

I use dmenu in Arch Linux. After libX11 upgrade from 1.6.3 to 1.6.4 I spotted that dmenu crashed. Spending some time debugging showed that the problem is related to handling cs_CZ.UTF-8 locale in libX11.

$ LANG=cs_CZ.UTF-8 dmenu_run
$ warning: no locale support
... and after a keypress there is a crash (the same as in [1])

Reverting 33840a5465a2e5fecab520bfbdd2d1bd0a456f51 fixes the issue because XLC_LOCALE was not defined for the mentioned locale.
See the next comment for the patch.

[1] https://bbs.archlinux.org/viewtopic.php?id=217913

Created attachment 127166 [details] [review]
[PATCH] nls: fix handling of cs_CZ.UTF-8 locale

Fixes locale.dir for cs_CZ.UTF-8 locale.

A related burgreport: https://bugs.archlinux.org/task/51442

Summary:

Upgrading libx11 to version 1.6.4-1 breaks diacritics with LibreOffice:
- using a deadkey to write diacritics is no longer possible (only the character without diacritics appears),
- opening/saving files with filenames or path containing characters with diacritics is not possible (GUI error file does not exist)

Patching libx11 1.6.4 with the patch by Jiří Klimeš, the results are mixed:
- diacritical characters using a deadkey can now be written in LibreOffice,
- files with diacritics in name/path still cannot be opened in LibreOffice.

*** Bug 98219 has been marked as a duplicate of this bug. ***

Created attachment 128124 [details] [review]
fix handling of cs_CZ locale - remove reference to empty XLC_LOCALE

line (1) is duplicit

en_US.UTF-8/XLC_LOCALE:			cs_CZ.UTF-8

(In reply to Pinky from comment #15)
> Created attachment 128124 [details] [review] [review]
> fix handling of cs_CZ locale - remove reference to empty XLC_LOCALE

Superb. Applying this patch fixed the issue with non working dead key in qt4, java applications and wine. Now I'm able to write "Š" by using dead key as before.

Thanks.

I have the same issue with en_DK.UTF-8 on Arch Linux with crashes on dmenu.

If I understand correctly, the currently proposed patch fixes only the cs_CZ locale, is that correct?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard/issues/16.