Red Hat Bugzilla – Bug 259101
Add sr-latin Xkb mapping and update Serbian keyboard layouts
Last modified: 2008-02-27 07:48:18 EST
Serbian locale in anaconda uses two different keyboards, adding mapping for them.
Created attachment 175001 [details]
Add sr-latin mapping and update Serbian keyboard layouts
We also neet to move the po file for sr@Latn to sr@latin
I have done the necessary operations in the CVS to rename this file. Please
check the cvs & let me know if you need any more information on this...
I added the mapping for sr-latin and it'll be in the next build I hope.
I just realized that i made mistake with this.I am not supposed to rename the
file. Actually, this should never be renamed, as the standard locale name
sr@Latn is accepted all other major open source projects like Gnome...So, this
move is really improper. It should remain sr@Latn only. I guess keyboard-mapping
need to be changed to the correct one. So, i am reopening this bug & reverting
back the modifications i did.
Are you sure the @Latn is correct? Because when you look at the firs comment for
#235709, is surely says @latin. I'll try to confirm it with the glibc guys to be
You are right, Glibc guys and the serbian language community guys are right
people to answer this...
The file in rawhide glibc responsible for this locale is indeed named sr_RS@latin.
And I was given confirmation by Jakub Jelinek, that:
> the supported locale is sr_RS@latin
It started of as @Latn as "Latn" was the ISO 15924 script identifier suggested
by Gnome devs quite some time ago. However, after going back and forth for
almost tow years with the glibc locale mainternaier this was not accapted
(insisting on lowercase latin, cyrillic, etc. for legacy reasons), so we had to
settle for @latin, and are in the process of slowly transitioning all projects
with some cooridination within the Serbian FLOSS community.
IMHO, both are fraught as the scripts shouldn't be handled by the @ modifier at
all because of matching order, but should be part of the language label, as in
CLDR locales and RFC 4646, e.g. sr_Latn_RS or sr-Latn-RS. Anyhow, this
discussion is certainly beyond the scope of this bug...
Bug cleanup, fixed ages ago