German keyboard layout - deadkeys by default

Bug #73240 reported by Jan Niklas Hasse
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
xkeyboard-config (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

If you install Ubuntu with a german keyboard, deadkeys like ´ or ^ aren't activated by default, although they are on german keyboards and used very often.

If you activate them later in the keyboard options they work, but then you can't type ^^ by pressing only 2 times, you have to press 4 times!

So deadkeys for German users should be activated by default and also should be configured that you can type ^^ by only pressing the [^]-key 2 times.

Revision history for this message
Brian Murray (brian-murray) wrote :

Thanks for your bug report. With which version of Ubuntu did you notice this bug?

Revision history for this message
Jan Niklas Hasse (jhasse) wrote :

I noticed it with Edgy and Dapper, but i think it's also a bug with other distributions like Debian because there is no keymap with this special behaviour, although it's very useful and the default in Windows.

Revision history for this message
Dominik Holler (dominik-holler) wrote :

same problem with feisty: ubiquity selects "german" keyboardlayout as default - I think "gearman - no deadkeys" would be better
(because many users <should> not know about deadkeys, a labeling like "german" and "german with deadkeys'" would be better)

Changed in xkeyboard-config:
importance: Undecided → Medium
status: Unconfirmed → Confirmed
Revision history for this message
Dominik Holler (dominik-holler) wrote :

same problem with gutsy/tribe5

Changed in xkeyboard-config:
status: Confirmed → Triaged
Revision history for this message
Dominik Holler (dominik-holler) wrote :

problem with gutsy/beta1:
user can choose between "German", "German Deadkeys" and other Keybord Layouts.
if I choose German and press "~" in the test line nothing happens, if I press "~ " (tilde space) a "~" appears in the line.
if I choose "German Deadkeys" and press "~" in the test line appears "~".

Revision history for this message
Dominik Holler (dominik-holler) wrote :

same problem with hardy/alpha3

Revision history for this message
jiu (jacques-charroy) wrote :

I use the layout with 'Sun dead keys' or sthg like that, which makes the ê work. I think it should be made the default for german keyboards.

Revision history for this message
Jan Niklas Hasse (jhasse) wrote :

When I choose 'Sun dead keys' ê works indeed, but then i need to press ^ four times to write ^^.

Revision history for this message
Dominik Holler (dominik-holler) wrote :

same problem with hardy

Revision history for this message
Stevie (stevie1) wrote :

same here, count me in

Revision history for this message
kamereon (kamereon) wrote :

I think this Bug needs a bit of discussion :-)

firstly, I could not reproduce a general dead key problem on several gutsy and hardy (32 bit and 64 bit) machines with a clean german install. The standard keyboard for german is always "generic 105 keys", and typing "^" + "a" will correctly produce "â". Does anyone with a newly installed german ubuntu really have a dead key problem?
Dead Keys also work if you boot to german from a LiveCD of Ubuntu or Xubuntu

secondly, it is true: one can not produce a "ñ" by typing "~" + "n". But this is the same in german Windows XP!
One can also not type a "å" by hitting "°" + "a" But this is also the same in Windows. Now I don't know anything about keyboard and localization standards, but this may not be a bug, but simply a standard.

thirdly, the "^^ issue" is imho not a bug! If you hit "^", the computer will wait for the next key to be pressed. Which would normally be something like the "o" key, to produce an "ô". If you don't want an accented letter, you hit the"^" key a second time, to get "^".
This is imho perfectly correct dead letter behaviour. Now I know that in Windows, hitting "^" twice will produce "^^", BUT THIS IS A BUG IN WINDOWS! How do you type a single "^" in Windows? You can't! I think that ubuntu handles the dead key "^" correctly.

so:
a) does anyone really have a dead key problem on a freshly installed german hardy (or LiveCD) ? (I think not!) But if they do, what are their keyboard settings and locale?

b) do you type an "ñ" by hitting "~" + "n"? If so, we may have a bug here. But then german Windows has the same problem!

c) the "^^ issue" is imho not a bug. How would you type a single "^"?

Revision history for this message
Dominik Holler (dominik-holler) wrote :

my problem is, that dead keays are enabled by default, because non geeks never want to know about dead it.

Revision history for this message
Jan Niklas Hasse (jhasse) wrote :

@kamereon
You can type a single ^ on windows, simply press ^ + space.

The real problem is, that i often use ^^ in chatting and it's VERY annoying to press ^ four times. Like dominik said, there are many beginners out there, who don't know how to turn it off. If you turn it off by default, people will get annoyed that they can't type german words like "café" or something like this.

Revision history for this message
Jan Niklas Hasse (jhasse) wrote :

I forgot to say: Thanks for bringing this up kamereon, I think it's good to finally discuss about it.

Revision history for this message
klptzyxm (klptzyxm) wrote :

While the "nodeadkeys" variant is often preferred by programmers, I think the
default de-"basic" layout should conform to the German DIN 2137 standard for
keyboards.
This states that only french accent keys (circumflex ^, acute ´, grave `) are
dead keys, but not the tilde ~ key. This is also the correct behavior in
Windows with the "German (Germany) - German" setting.
It is currently not possible to select such a variant in Linux as the "basic"
variant has "dead_tilde" enabled and "deadgraveacute" is missing a
"dead_circumflex".

See also
<http://en.wikipedia.org/wiki/Keyboard_layout#Germany_and_Austria_.28but_not_Switzerland.29>

Revision history for this message
Rolf Leggewie (r0lf) wrote :

I think this is an excellent item for our papercutters.

Revision history for this message
Vish (vish) wrote :

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue, in the default Ubuntu install, that affects many people and is quick and easy to fix. So this bug can't be addressed as part of this project.

For further information about papercuts criteria, please read https://wiki.ubuntu.com/PaperCut.

Don't worry though, this bug has been marked as "Invalid" only in the papercuts project.

Changed in hundredpapercuts:
status: New → Invalid
Revision history for this message
Rolf Leggewie (r0lf) wrote :

> Thank you for bringing this bug to our attention. However, a paper cut should be a
> small usability issue, in the default Ubuntu install, that affects many people and is
> quick and easy to fix.

That's exactly what this is!

* small usability issue? Check
* default Ubuntu install? Check
* affects many people? everybody with a German keyboard, check
* quick'n'easy fix? Check, may be possible to do in an hour when the right skills are present

Reopening for papercut

Changed in hundredpapercuts:
status: Invalid → New
Vish (vish)
affects: hundredpapercuts → null
Revision history for this message
Vish (vish) wrote :

@Rolf Leggewie : Thank you for your interest in the papercuts project.
This bug was invalidated in papercuts , since it is a bug affecting only a particular keyboard layout. Language specific bugs are not papercuts.
Kindly leave the papercut task alone! It is counterproductive.

Revision history for this message
Rolf Leggewie (r0lf) wrote :

Vish, calm down, OK? And may I kindly ask for a more civilized and productive form of discussion? It's OK to disagree among adults, you know?

I'm only going by what the project has defined itself as criteria (see comment 19). And you don't seem to follow even your own, privately invented subset of that. Or why did you only hours ago approve a bug in ibus, a package which is very language specific? There is a difference between invalid and wontfix.

I understand that none of the three or so bugs I added in the last 24 hours to the papercuts task are going to be accepted. I don't have any particular issue with that.

Revision history for this message
Vish (vish) wrote :

@Rolf Leggewie:
In case you missed it. :-) "since it is a bug affecting only a particular keyboard layout." this bug was invalidated as a papercut.

We read through several bugs and if each user starts to re-open bugs [that too within the same day], since they are affected by it. It becomes harder for us. :-( We will never get to responding to other bugs or might not even discover bugs that are really papercuts. Kindly understand.
BTW, I am calm. ;-)
I'v responded this to you privately _and_ in comment#20 as well for the benefit of others subscribed to this bug as well.

Revision history for this message
Vish (vish) wrote :

Btw , The Ibus bug affects all users and the default system preferences menu uses the term "Ibus preferences" which is a design flaw. None of the preferences menu items are to have the ending preferences. Also the whole Ibus is not clear in its functions.
Any user can select the option and wonder why they get the error or what Ibus does.

That is exactly an example of a papercut. Not sure why you think it is language specific. It is an item in the default install for all languages.

Revision history for this message
Bryce Harrington (bryce) wrote :

While this bug report seems to have veered offtrack a bit, the original discussion appears to me to be a difference of opinion about the default behavior, where the current behavior matches expectations for one class of user but not another. It sounds like the original behavior in the bug report has changed, so perhaps some of the original problems are not occurring.

Given there is not an apparent consensus from the comments, and that the current behavior matches both Windows behavior and established specs (as per comment #16), then it sounds like the default behavior should be left as is. While it might not match everyone's expectations, at least it is configurable.

If you disagree and still think changes should be considered, I'd ask that you file a new bug with a clear proposal of what to change. I think such changes will need to be presented for upstream to consider before making changes in Ubuntu.

Changed in xkeyboard-config (Ubuntu):
status: Triaged → Won't Fix
Revision history for this message
Rolf Leggewie (r0lf) wrote :

comment 16 states that Windows gets it right and that Linux does not even have a setting which gets it right. Therefore, such a setting would have to be created first before becoming default. At least that's my understanding of comment 16.

As somebody who uses a German keyboard (which I think Bryce does not, so it'll likely be harder for him to grasp what's being discussed here) I can certainly attest to the fact that I never quite found a setting that worked exactly the way I expected it to.

Now, if somebody tells me about the package that contains the keyboard layout definitions, I'll make sure that a ticket gets opened to create a layout fully compliant with DIN 2137 standard (Germans are Germans ;-)) https://help.ubuntu.com/community/Howto%3A%20Custom%20keyboard%20layout%20definitions would suggest that it's xkb-data but I'm not sure how accurate or current that wiki page is.

Revision history for this message
klptzyxm (klptzyxm) wrote :

That was basically the point - there is no layout that matches the DIN 2137 standard.

There's a similar bug report for xkeyboard-config:
https://bugs.freedesktop.org/show_bug.cgi?id=9752

Revision history for this message
Rolf Leggewie (r0lf) wrote :

reopening as per comment 26

Changed in xkeyboard-config (Ubuntu):
status: Won't Fix → Confirmed
Curtis Hovey (sinzui)
no longer affects: null
Revision history for this message
Maik Riechert (neothemachine) wrote :

5 years.... I started using Ubuntu again alongside Windows recently and am now discovering that this annoying behavior still exists which should have been fixed a long time ago. Please, fix it or tell us how to fix it ourselves.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.