In certain text fields I can't type non-english characters at all (I type a character, nothing happens). Examples are:

  • Unity dash search field
  • Chromium address bar
  • Pidgin message box
  • Gajim message box

On other places (such as Terminal, Firefox address bar, input fields on web sites etc) inputting these characters works.


$ locale

$ gsettings list-recursively org.gnome.desktop.input-sources
org.gnome.desktop.input-sources current uint32 0
org.gnome.desktop.input-sources per-window false
org.gnome.desktop.input-sources show-all-sources false
org.gnome.desktop.input-sources sources [('xkb', 'us'), ('xkb', 'rs+latin'), ('xkb', 'rs')]
org.gnome.desktop.input-sources xkb-options @as []

$ setxkbmap -query -v
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+us+inet(evdev)
geometry:   pc(pc105)
rules:      evdev
model:      pc105
layout:     us

And when I switch to one of my non-US layouts, I get:

$ setxkbmap -query -v
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+rs(latin)+us:2+inet(evdev)
geometry:   pc(pc105)
rules:      evdev
model:      pc105
layout:     rs,us
variant:    latin,


$ env | grep -i im
  • What is your locale? Just type locale on a console
    – LnxSlck
    Mar 27 '14 at 10:19
  • @LnxSlck: updated the question. Mar 27 '14 at 11:21
  • @Sneetsher: done Mar 27 '14 at 11:24
  • 1
    Could you try: System Settings > Language Support > Language tab > Keyboard input method system: iBus. If didn't try other options you may need to logout/login to make settings active.
    – user.dz
    Mar 27 '14 at 11:58
  • any update on this?
    – rsz
    Apr 30 '14 at 23:39

I confirmed I had the same problem in Unity and Chromium with the same setup that you are showing, but fixed it with the following workaround.

The existing problem is that even when the menubar correctly shows that you have switched the layout to, say, S1, Unity reacts as if it is using the English layout.

That is, only English output is produced, even though the indicator says S1. Key presses in Unity will only produce the English key, or nothing will appear if no key corresponds to the Serbian combo, or another part of the interface will fire if the combo happens to trigger it. Other applications, however, for example, gedit, will correctly use the Serbian layout shown in the menubar; but Unity still only reacts as if the layout is set to English. In addition, this is not affected by changing the font.

There are 2 issues:

  1. There is a bug somewhere.
  2. This answer provides a workaround for the bug.

Please also note that:

  1. This has nothing to do with input methods. This worked with the default input method set to ibus, fcitx, or none.

  2. This is also not related to settings in xkb-options, such as the Compose Key or the 3rd level chooser (referred to as Alternative Characters Key in Keyboard >> Typing.

    (You don't have either of these set; this point is just for completeness.)

The key setting is found in System Settings >> TextEntry.

The default setting is Use the same source for all windows. Unfortunately, the default setting seems to always create the problem.

The workaround is to switch this to Allow different sources for each window.

TextEntry setting dialog with 3 keyboards and allow different sources

The New windows setting will work with either choice, but use the default choice seems to be less quirky and work correctly more consistently.

You shouldn't need to log out and in, but it doesn't hurt. At this point, entry with the Serbian keyboards works in both Chromium and Unity search. Well, most of the time. I discovered that Unity is still sometimes a little quirky, but this is also easily worked around.

With New windows use the default source, things worked as expected almost all of the time:

That is, you open Unity, the source switches to English, then you use Ctrl+Space to switch the source. Now the source is S1 (latin). Typing [ correctly produces š and keys that depend on a combination also work correctly in Unity. For example, Right-Alt+a produces æ.

The quirk is that sometimes Unity's input source and the input source displayed in the keyboard indicator seem to get out of sync and you get or continue to get the problem as described above.

The work around for this quirk is to cycle through the input sources. Press Ctrl+Space until you get back to the source you want.

This re-syncs the input sources most of the time. A few times I had to cycle through twice. Another time, I had to cycle through the sources, exit out of Unity and restart Unity.

The good news is that once the sources are re-synced they seem to stay correct through the rest of the session.

Better yet, as mentioned above, using the setting new windows use default source seems to prevent the quirk from happening in the first place almost all of the time.

The frequency of this quirk appears to be:

  1. Under the default setting Use the same source for all windows: Always. It will never work.
  2. Under the setting Allow different sources -- new use current source: Frequent. Cycling through the input sources and sometimes exiting/restarting Unity is frequently needed.
  3. Under the setting Allow different sources -- new use default source: Rare. Works as intended most of the time. Cycling through the input sources and sometimes exiting/restarting Unity needed now and then, but not often.

I couldn't find this bug in Launchpad, so you may want to report a new bug against input source switching. (I'm not sure of the exact package to report.) There are similar bugs in Launchpad, but all of the ones I saw were older and were not active.

  • First, thanks. I can't try your solution right away, as the problem occurs only on my machine on work. At home I have two other machines with the same Ubuntu version, and neither show the same buggy behavior(!). Another thing (not sure if we understood each other): the buggy behavior is not that the indicator displays wrong layout, it's displaying correct layout (let's say Serbian Latin), but when I type, for example, š (located where [ is in US layout), nothing appears. Neither š nor [ are outputted. Mar 27 '14 at 16:35
  • Thanks for the comment. My wording of that sentence was poor. I meant the English key or nothing if the Serbian RALT combo doesn't have a corresponding English key. I'll fix it. I did test it according to your problem. I just tried it with š nor [ and it still works fine. That's the thing with bugs. Sometimes it's hard to know when just the right set of things come together. My machine had the same problem as yours before I applied the workaround. After that, it types Serbian in Unity correctly.
    – chaskes
    Mar 27 '14 at 16:44

I would suggest that the issue is that in some places the fonts that you use do not have the necessary non-latin characters. Try to check that desktop-wide and in the apps that you use the fonts used have a wide range of covered characters, such as the Liberation or DejaVu font family.

  • I don't think fonts have anything to do with this: I am pretty sure I am using right fonts (Ubuntu and/or Roboto in particular), and even if I wouldn't, I would expect some replacement character (a square) would appear there. In my case, simply nothing happens. Mar 27 '14 at 16:43
  • Not always. Do experiment with other fonts just to make sure.
    – landroni
    Mar 27 '14 at 16:44
  • This would be pretty easy to check. You can just copy and paste into Libreoffice, then change fonts.
    – Sparhawk
    Mar 29 '14 at 4:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.