Red Hat Bugzilla – Bug 221777
Incorrect default setting for Romanian keyboard layout
Last modified: 2013-01-09 23:10:07 EST
Description of problem:
Fedora Core 6 still uses *by default* an old standard for the Romanian
keyboards, a standard that is obsoleted.
There are two main issues regarding the Romanian keyboard layout:
1. There is an official Romanian standard for the Romanian keyboard layout,
namely SR 13392:2004. It offers a "primary" layout and a "secondary" one.
The default in Fedora, when using a Romanian keyboard, should be the "secondary"
layout, as presented in the attached image (the "primary" one is maintained
mainly for compatibility with a much older standard).
2. Due to some very old incorrect implementations made by Microsoft long ago,
there is a confusion between the following four characters in Romanian keyboard
- "S with comma below" (Unicode 0218) - incorrectly implemented as "S with
cedilla below" (Unicode 015E)
- "s with comma below" (Unicode 0219) - incorrectly implemented as "s with
cedilla below" (Unicode 015F)
- "T with comma below" (Unicode 021A) - incorrectly implemented as "T with
cedilla below" (Unicode 0162)
- "t with comma below" (Unicode 021B) - incorrectly implemented as "t with
cedilla below" (Unicode 0163)
The standard SR 13392:2004 explicitly removes this confusion.
A correct Romanian keyboard implementation in Fedora Core 6 should implement *by
default* the "secondary layout" in the standard (as in the attached picture) and
should use the comma-form of "s" and "t" instead their cedilla-form counterparts.
The *correct* layout is that of "setxkbmap ro comma", which should be used by
default in both X programs and console-based ones.
Version-Release number of selected component (if applicable):
Fedora Core 6 with standard updates as of January 08, 2007.
Steps to Reproduce:
1. Install a stock Fedora Core 6
2. Boot in X with Gnome interface
3. Choose menu "System" -> "Administration" -> "Language" -> "Romanian"
4. Choose menu "System" -> "Administration" -> "Keyboard" -> "Romanian"
5. Open a Unicode-enabled text editor
6. Press the keys combinations corresponding to Romanian-specific characters
(see attached picture).
There are cedilla-forms of "s" and "t".
The layout of Romanian keyboard should be as in Romanian standard SR 13392:2004
The comma-forms of "s" and "t" should be used instead of their cedilla-counterparts.
(for Romanian speakers)
Created attachment 145012 [details]
Correct default Romanian keyboard layout
For the time being, using the setkbdmap command, one can configure a Romanian
keyboard in five variants, as follows:
- "setkbdmap ro comma" (this should be the default both in command line and in
X, since it's correct according to Romanian grammar);
- "setkbdmap ro" - this is the present default, with the confusion mentioned
above between comma and cedilla;
- "setkbdmap ro std" - old layout with all bugs implemented by Microsoft ;-)
- "setkbdmap ro academic" - old layout with s and t problem corrected;
- "setkbdmao ro ms" - Martin Poehler's old implementation, with y and z inversed.
For Fedora, please set the default as for *the first variant*, since it's
according to standards and the correct one - *both in console and in X*.
For the record: ;-) I just want to mention that a correct implementation of
Romanian keyboard was recently added in Windows Vista.
There are five types of Romanian keyboard now in Control Panel, corresponding
(in order) to the five variants described in comment #2. According to Windows
denomination, these are:
- Romanian (Programmers)
- Romanian (Programmers, cu sedile)
- Romanian (Standard, cu sedile)
- Romanian (Standard)
- Romanian (Legacy)
The default setting for any Linux distribution, in both X and text mode, should
be "Romanian (Programmers)".
Windows Vista is still unable to provide correct UTF-16 support for Romanian
At http://www.secarica.ro, the driver created by Cristian Secara for Windows XP
and older, version 2.3, implements these changes and denominations as well, in
order to obtain an uniform look and feel in all Windows variants.
*** This bug has been marked as a duplicate of 329071 ***