Bug 15887 - libX11 has no "true" ru_RU.UTF-8 locale
Summary: libX11 has no "true" ru_RU.UTF-8 locale
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xlib (data) (show other bugs)
Version: 7.3 (2007.09)
Hardware: All All
: high major
Assignee: Julien Cristau
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: l10n, patch
: 3839 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-05-09 04:33 UTC by Dmitry Klimov
Modified: 2009-10-17 08:19 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
debian patch for ru_RU.UTF-8 (4.82 KB, patch)
2009-03-11 10:28 UTC, Julien Cristau
no flags Details | Splinter Review

Description Dmitry Klimov 2008-05-09 04:33:59 UTC
Existing ru_RU.UTF-8 locale is just an alias for en_US.UTF-8, which causes incorrect cyrillic font displaying in some apps(which use libX11 only for font rendering). Ones are well-known xmms(and other gtk1.2) and worker file manager.

The well recipe is separate locale(generally made from en_US.UTF-8, but with some fixes)

Here is the patch(made for FreeBSD ports)

http://www.freebsd.org/cgi/query-pr.cgi?prp=123137-1-txt&n=/patch.txt

and here is the pr sent by me almost two weeks ago, but still has no answer from maintainer

http://www.freebsd.org/cgi/query-pr.cgi?pr=123137
Comment 1 Incubos 2009-03-11 10:11:58 UTC
Something must be done with this bug. I've checked its presense in Arch Linux, Mandriva 2009 Powerpack using XMMS and WMII.
Comment 2 Alan Coopersmith 2009-03-11 10:19:07 UTC
A patch that was generated against/could be applied to the X.Org upstream 
sources instead of FreeBSD's build system and pre-existing patches would 
help get something done sooner.
Comment 3 Julien Cristau 2009-03-11 10:28:40 UTC
Created attachment 23765 [details] [review]
debian patch for ru_RU.UTF-8

Debian's carrying the attached patch since 6.9.0.  I guess I could push that upstream.  Original patch author is Eugene Konev <ejka@imfi.kspu.ru> (see debian bug#330144).
Comment 4 James Cloos 2009-03-12 11:32:49 UTC
*** Bug 3839 has been marked as a duplicate of this bug. ***
Comment 5 James Cloos 2009-03-12 11:45:59 UTC
Looking at Debian’s patch, ru_RU.UTF-8/XI18N_OBJS is based on pt_BR.UTF-8/XI18N_OBJS, so that should be OK, even though XIM and XOM lines differ from en_US.UTF-8/XI18N_OBJS.

It may be the case that one or the other needs to be updated, but it looks like a determination will require looking through XFree86’s repo and perhaps the old monolithic releases to find the history of pt_BR’s and en_US’s versions....

The ru_RU.UTF-8/XLC_LOCALE.pre seems to be OK.

ru_RU.UTF-8/Compose.pre, OTOH, is not.  It looks like:

,----
| include "/usr/share/X11/locale/en_US.UTF-8/Compose"
`----

First, IIRC, the support for include commands in the installed Compose files is part of another patch Debian adds.  Also it ignores --prefix, rather hardcoding the installed location of the locale db.

Since the .pre files are processed through the C preprocessor, it should be:

#include "../en_US.UTF-8/Compose.pre"

Otherwise, it looks OK.
Comment 6 Julien Cristau 2009-03-13 01:43:31 UTC
Thanks for looking over the patch!

> --- Comment #5 from James Cloos <cloos@jhcloos.com>  2009-03-12 11:45:59 PST ---
> ru_RU.UTF-8/Compose.pre, OTOH, is not.  It looks like:
> 
> ,----
> | include "/usr/share/X11/locale/en_US.UTF-8/Compose"
> `----
> 
> First, IIRC, the support for include commands in the installed Compose files is
> part of another patch Debian adds.

That's not true afaik.  Support for include in compose files was added
back in xfree86.  See commit c6349f43193b74a3c09945f3093a871b0157ba47,
in modules/im/ximcp/imLcPrs.c:parseline().

>   Also it ignores --prefix, rather hardcoding
> the installed location of the locale db.
> 
ack

> Since the .pre files are processed through the C preprocessor, it should be:
> 
> #include "../en_US.UTF-8/Compose.pre"
> 
> Otherwise, it looks OK.
> 
I'll make these changes and attach an updated patch.
Comment 7 Julien Cristau 2009-03-13 06:18:15 UTC
> --- Comment #5 from James Cloos <cloos@jhcloos.com>  2009-03-12 11:45:59 PST ---
> Looking at Debian’s patch, ru_RU.UTF-8/XI18N_OBJS is based on
> pt_BR.UTF-8/XI18N_OBJS, so that should be OK, even though XIM and XOM lines
> differ from en_US.UTF-8/XI18N_OBJS.
> 
> It may be the case that one or the other needs to be updated, but it looks like
> a determination will require looking through XFree86’s repo and perhaps the
> old monolithic releases to find the history of pt_BR’s and en_US’s
> versions....

xfree86's version of nls/XI18N_OBJS/en_US.UTF-8 looks similar to our
pt_BR.UTF-8, and hasn't changed in at least 7 years.

Also, it seems that _SwitchOpenIM and _XimpLocalOpenIM don't actually
exist anywhere.  The files still referencing xiiimp should probably be
updated, as that doesn't seem to exist.  This seems to be true for a
bunch of other modules (ximp40, ximlocal and xomLTRTTB).  Sigh.
Comment 8 Julien Cristau 2009-03-16 14:22:36 UTC
> --- Comment #5 from James Cloos <cloos@jhcloos.com>  2009-03-12 11:45:59 PST ---
> Since the .pre files are processed through the C preprocessor, it should be:
> 
> #include "../en_US.UTF-8/Compose.pre"

this doesn't work when builddir != srcdir, unfortunately.
Comment 9 James Cloos 2009-03-17 03:26:01 UTC
>> #include "../en_US.UTF-8/Compose.pre"

> this doesn't work when builddir != srcdir, unfortunately.

Since I was wrong about the provenence of include (as opposed to
#include), then the only change the proposed patch needs there is
to honour $X11_LOCALEDATADIR.  I suspect that that will require
these changes to cpprules.in:

diff --git a/cpprules.in b/cpprules.in
index 12964fa..16ede7e 100644
--- a/cpprules.in
+++ b/cpprules.in
@@ -7,8 +7,9 @@ SED = sed
 SUFFIXES = .pre
 
 WCHAR32_FLAGS = -DWCHAR32=@WCHAR32@
+LOCALEDATADIR_FLAGS = -DX11_LOCALEDATADIR=\"@X11_LOCALEDATADIR@\"
 
-CPP_FILES_FLAGS = $(WCHAR32_FLAGS)
+CPP_FILES_FLAGS = $(WCHAR32_FLAGS) $(LOCALEDATADIR_FLAGS)
 
 # Translate XCOMM into pound sign with sed, rather than passing -DXCOMM=XCOMM
 # to cpp, because that trick does not work on all ANSI C preprocessors.

and then using:

include X11_LOCALEDATADIR"/en_US.UTF-8/Compose"

for the Compose.pre file.

A quick test shows that the above changes create a Compose file which
looks like:

include "/usr/share/X11/locale""/en_US.UTF-8/Compose"

after a ./configure --prefix=/usr && cd ... && make Compose

so cpprules will also need some more sed to remove the "".  (I don't see
any portable way to get cpp to expand the macro inside a " string....)
Comment 10 Julien Cristau 2009-03-18 09:10:29 UTC
> --- Comment #9 from James Cloos <cloos@jhcloos.com>  2009-03-17 03:26:01 PST ---
> so cpprules will also need some more sed to remove the "".  (I don't see
> any portable way to get cpp to expand the macro inside a " string....)
> 
or since we run sed on the Compose file anyway, we could do the
substitution then.
e.g. adding
 -e 's/X11_LOCALEDATADIR/$(X11_LOCALEDATADIR)/g'
to CPP_SED_MAGIC in cpprules.in and
include "X11_LOCALEDATADIR/en_US.UTF-8/Compose"
to nls/ru_RU.UTF-8/Compose.pre.  that seems simpler to me, what do you
think?
Comment 11 Julien Cristau 2009-04-06 08:40:59 UTC
(In reply to comment #10)
> or since we run sed on the Compose file anyway, we could do the
> substitution then.

I pushed the patch with that change.  Thanks again for the review James.

commit e3198b55dc16ec57346cc28aa8d34165ce8cde96
Author: Julien Cristau <jcristau@debian.org>
Date:   Fri Mar 13 13:52:33 2009 +0100

    Add a ru_RU.UTF-8 locale
    
    Based on patch by Eugene Konev <ejka@imfi.kspu.ru> for X.Org 6.9.0.
    
    Debian bug#330144 <http://bugs.debian.org/330144>
    X.Org bug#15887 <http://bugs.freedesktop.org/show_bug.cgi?id=15887>


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.