Bug 11456 - Serbian locale updates (sr_RS and sr_ME)
Summary: Serbian locale updates (sr_RS and sr_ME)
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xlib (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: i18n, patch
Depends on:
Blocks:
 
Reported: 2007-07-02 15:45 UTC by Milos Komarcevic
Modified: 2018-08-10 20:09 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Patch for sr_RS and sr_ME locales (7.08 KB, patch)
2007-07-02 15:46 UTC, Milos Komarcevic
no flags Details | Splinter Review
Updated patch (6.15 KB, patch)
2009-03-16 16:49 UTC, Milos Komarcevic
no flags Details | Splinter Review
Additional entries for sr_RS.UTF-8@latin. (912 bytes, patch)
2012-04-08 01:32 UTC, Chusslove Illich
no flags Details | Splinter Review

Description Milos Komarcevic 2007-07-02 15:45:32 UTC
Serbia and Montenegro (formerly CS) have since last year and bug #5575 split
up, so we now have new sr_RS and sr_ME locales (from now on in UTF-8 only in
glibc).

Please update Xlib with the following patch after review.
Comment 1 Milos Komarcevic 2007-07-02 15:46:13 UTC
Created attachment 10560 [details] [review]
Patch for sr_RS and sr_ME locales
Comment 2 Milos Komarcevic 2008-01-02 13:56:05 UTC
Any feedback or estimates for applying this change?

Would be great to have it in for 7.4 and the spring 2008 round of distros.
Comment 3 Chusslove Illich 2008-08-06 11:38:09 UTC
Any news on this? Any particular reason the patch is not being applied?

The warning messages that stuff on top of X reports, such as "Qt: Locales not supported on X server", are getting kind of boring.
Comment 4 Goran Rakic 2008-12-22 10:54:14 UTC
This bug is reported in Debian as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507940 and in Ubuntu as https://bugs.launchpad.net/ubuntu/+source/libx11/+bug/299841

It would be great if this patch can be included in next release. Any progress on this?
Comment 5 James Cloos 2008-12-23 04:43:37 UTC
I'll get this pushed.
Comment 6 Rémi Cardona 2009-01-04 09:56:42 UTC
Downstream Gentoo bug : http://bugs.gentoo.org/253145
Comment 7 Alan Coopersmith 2009-03-16 14:39:25 UTC
The patch given in attachment 10560 [details] [review] is broken - it loses some characters
from some other locales:

@@ -1148,7 +1132,7 @@
 american.iso88591:				en_US.ISO8859-1
 arabic.iso88596:				ar_AA.ISO8859-6
 bokmal:						nb_NO.ISO8859-1
-bokm�l:						nb_NO.ISO8859-1
+bokml:						nb_NO.ISO8859-1
 bulgarian:					bg_BG.CP1251
 c-french.iso88591:				fr_CA.ISO8859-1
 catalan:					ca_ES.ISO8859-1
@@ -1167,7 +1151,7 @@
 estonian:					et_EE.ISO8859-1
 finnish:					fi_FI.ISO8859-1
 finnish.iso88591:				fi_FI.ISO8859-1
-fran�ais:					fr_FR.ISO8859-1
+franais:					fr_FR.ISO8859-1
 french:						fr_FR.ISO8859-1
 french.iso88591:				fr_CH.ISO8859-1
 galego:						gl_ES.ISO8859-1

[...]
@@ -1299,7 +1283,7 @@
 Dutch_Belgium.1252:				nl_BE.iso8859-1
 Dutch_Netherlands.1252:				nl_NL.iso8859-1
 Norwegian (Nynorsk)_Norway.1252:		no_NO.iso8859-1
-Norwegian (Bokm�l)_Norway.1252:			no_NO.iso8859-1
+Norwegian (Bokml)_Norway.1252:			no_NO.iso8859-1
 Polish_Poland.1250:				pl_PL.iso8859-2
 Portuguese_Brazil.1252:				pt_BR.iso8859-1
 Portuguese_Portugal.1252:			pt_PT.iso8859-1
Comment 8 Milos Komarcevic 2009-03-16 16:26:02 UTC
Alan, the patch seems to be ISO-8859-1 encoded for some reason, I suggest you use iconv to convert it to UTF-8. Otherwise, let me know and I'll resubmit it.
Comment 9 Alan Coopersmith 2009-03-16 16:38:04 UTC
If it was just the encoding of the patch, it wouldn't show those lines
as being edited - it seems to be an encoding problem in the environment
either the editor or diff was run in to generate the patch.
Comment 10 Milos Komarcevic 2009-03-16 16:49:19 UTC
Created attachment 23937 [details] [review]
Updated patch

Right you are. Patch reattached with problematic hunks removed, they have no relation to our locale anyway.
Comment 11 Alan Coopersmith 2009-03-16 17:45:11 UTC
Thanks - corrected patch pushed to git master for next libX11 release:

commit da95ecbbdcacc483cd0b5fd7db1fb2e2543341bd
Author: Milos Komarcevic <miloskomarcevic@netscape.net>
Date:   Mon Mar 16 17:43:26 2009 -0700

    Bug 11456: Serbian locale updates (sr_RS and sr_ME)
    
    X.Org Bug #11456 <http://bugs.freedesktop.org/show_bug.cgi?id=11456>
    Patch #23937 <http://bugs.freedesktop.org/attachment.cgi?id=23937>
    
    Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Comment 12 Chusslove Illich 2012-04-08 01:31:18 UTC
It seems some entries are still missing: when starting LibreOffice in
sr_RS.UTF-8@latin locale, it reports "X Window System doesn't support locale
'sr_RS.UTF-8@latin'" and then there are encoding problems inside. I fixed it
by adding this line to /usr/share/X11/locale/locale.dir:

  en_US.UTF-8/XLC_LOCALE: sr_RS.UTF-8@latin

Maybe the following patch would suffice?
Comment 13 Chusslove Illich 2012-04-08 01:32:09 UTC
Created attachment 59641 [details] [review]
Additional entries for sr_RS.UTF-8@latin.
Comment 14 Fiable.biz 2013-05-25 13:30:00 UTC
Mongolian from Mongolia is also lacking in locale.dir and compose.dir.
See the last comment of
https://bugs.mageia.org/show_bug.cgi?id=7797

Do I need to open a new bug for this, or do we change the bug title?
Comment 15 Mike FABIAN 2014-02-19 18:02:13 UTC
(In reply to comment #13)
> Created attachment 59641 [details] [review] [review]
> Additional entries for sr_RS.UTF-8@latin.

be_BY.UTF-8@latin is also missing, see:

https://bugs.freedesktop.org/show_bug.cgi?id=75220
Comment 16 GitLab Migration User 2018-08-10 20:09:11 UTC
-- 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/lib/libx11/issues/3.


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.