Red Hat Bugzilla – Bug 101046
numeric dot replaced by period with french keyboard
Last modified: 2007-04-18 12:56:15 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR
Description of problem:
Language selected: French. Keyboard selected: French.
In these programs (but maybe in other ones too):
-> using the dot of the numeric keyboard (the delete/. key), gives a
period "," instead of a dot "."
Using the other dot on the left part of the keyboard gives a dot.
Konsole hasn't this problem, nor several other apps.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. type numeric key .
2. see ,
No problem with Konsole or Konqueror
for why this is a X keymap bug; (actually missing key symbols,
but it could be worked around by using the normal period/comma
key symbols for that key in the keymap)
Reassigning to the XFree86 component, but you should file a bug
upstream in bugs.xfree86.org
It's worked around (or fixed?) in Mandrake 9.1 (maybe this way?): no ","
So the workaround could be ported to RedHat, so it works before XFree86 people
decide to change this.
Anyway I've added a bug at http://bugs.xfree86.org/show_bug.cgi?id=534
The bug in xfree86.org has been closed. Comments are:
------- Additional Comments From email@example.com 2003-29-07 06:59 -------
X knows two key symbols that can meaningfully be assigned to this:
KP_Decimal and KP_Separator. XLookupString() returns a '.' for the
first and a ',' for the latter. This is independent of any LC_NUMERIC
The translation is done in _XkbHandleSpecialSym() with a very simple
(keysym & 0x7F).
Therefore the comment one can find in many places
"/* separator, often comma */" is mostly misleading. The mapping to
the locale dependent values is therefore done in the keyboard mapping,
not when translating the keyboard symbols.
What are therefore the conclusions?
The keysym returned should depend on the value for the locale:
KP_Decimal should be returned if the decimal separator is a '.',
KP_Separator should be returned if it is a ','.
The application should be prepared to do the 'right thing' when it
reads KP_Decimal, KP_Separator, '.' or ','.
I will change the symbols/fr file to generate a KP_Separator instead.
If necessary gtk should be fixed to generate the correct output.
Since KP_Decimal and KP_Separator are bound to specific keyboard
symbols already I don't recommend a LC_NUMERIC dependent translation
I don't agree that a terminal emulator should always generate a '.'
for this key. Applications should be fixed to obey the LC_NUMERIC
I understand the following part: "If necessary gtk should be fixed to generate
the correct output."
I read the upstream report as well now, and resolution. I'm assuming whatever
the problem is, that it is solved now in XFree86 CVS, and will appear in
the next release of XFree86.
Reassigning to GTK for now as comments above indicate GTK might require
*** Bug 90670 has been marked as a duplicate of this bug. ***
* Fri Sep 5 2003 Owen Taylor <firstname.lastname@example.org> 2.2.4-2.1
- Fix up tutorial in packaging (#90197), add FAQ
- Back out change to make KP_Decimal interpretation dependent on locale