Bug 108151 - System input language is always ignored on Linux
Summary: System input language is always ignored on Linux
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
: 61912 113298 154495 (view as bug list)
Depends on:
Blocks: RTL-CTL 62063 Language-Detection
  Show dependency treegraph
Reported: 2017-05-27 10:06 UTC by Panos Stokas
Modified: 2023-09-04 18:28 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Panos Stokas 2017-05-27 10:06:22 UTC
System input language allows the user to define the current language being typed, based on the keyboard layout. It's very important for documents combining latin-based and non-latin-based languages where keyboard layout always defines the language being typed.

It's enabled by default and works fine on Windows.

The problem is that it doesn't work on Linux, or at least on Ubuntu-based distributions. That means the user will have to take additional steps to define the language of parts of the document which is very impractical.

Steps to Reproduce:
1. Make sure Language Settings > Languages > Ignore system input language is not enabled.
2. Switch your keyboard layout to US English.
3. Type a word and check the language at the status bar: it's "English (USA)"
4. Switch your keyboard layout to Greek.
5. Type anything in Greek and check the language at the status bar: it's still "English (USA)"

Actual Results:  
On Linux, the text didn't match the system input language and therefore it cannot be correctly processed by an appropriate hyphenator or spell-checker.

Expected Results:
The text should match the system input language so that it can be correctly processed by an appropriate hyphenator or spell-checker. This is how it works on Windows.

Reproducible: Always

User Profile Reset: Yes

Additional Info:
For some users, especially those using two different latin-based languages, this feature is not desirable but it can be disabled at the Language Settings > Languages options by ticking at the Ignore system input language checkbox.

User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0
Comment 1 Buovjaga 2017-06-03 10:22:42 UTC
Confirmed, but bug 61912 was closed as NOTABUG, so I will add needsDevAdvice keyword.

Arch Linux 64-bit, KDE Plasma 5
Build ID: 5.3.3-1
CPU Threads: 8; OS Version: Linux 4.10; UI Render: default; VCL: kde4; Layout Engine: new; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Comment 2 Panos Stokas 2017-06-08 06:35:44 UTC
I think that whoever marked bug 61912 as not a bug did not realize what the problem is about.

This is often difficult to explain to users who are using a single locale. They think that somehow the OS is supposed to figure out by itself which language is being typed, while in reality user-triggered keyboard layout is also considered language change for most keyboard layouts in both Windows and Linux. For those who don't want this feature, there's an option to ignore it.

I would request that whoever reviews this problem has at least some experience in writing documents using two or more different languages.
Comment 3 Caolán McNamara 2017-06-08 09:13:54 UTC
On windows we get an explicit WM_INPUTLANGCHANGE message 


which states the language the Input Method is for

Under linux, e.g. for GTK, we use GtkIMContext
https://developer.gnome.org/gtk3/stable/GtkIMContext.html which doesn't send/provide an equivalent explicit language that the IM is for

Maybe its possible to make an educated guess as to what the language is by examining the domain or the default_locales field of GtkIMContextInfo https://developer.gnome.org/gtk3/stable/GtkIMContext.html#GtkIMContextInfo but on the face of it at least there doesn't seem to be a non-ambiguous way to tell what language the IM is for under Linux
Comment 4 Buovjaga 2017-06-08 09:58:22 UTC
Ok, let's set to NEW with the caveat that this needs more research to even determine, if this is doable.
Comment 5 QA Administrators 2018-10-24 02:56:49 UTC Comment hidden (obsolete)
Comment 6 Mike Kaganski 2019-10-01 08:16:28 UTC
Closing bug 61912 like that was, of course, not a correct thing (although the problem could have no solution as mentioned in comment 3). The interesting thing is that the person closing that bug is familiar with multiple keyboard layouts.

I guess that what could be useful here is if users who know of an open-source programs correctly detecting input language to post examples here.
Comment 7 drd 2019-10-01 22:56:02 UTC
Finally, after 6 years and 7 months! Big thanks to Panos Stokas and Mike Kaganski!

Getting to the point: i'm writing this comment in Chromium 77.0.3865.90. It is open-source. I confirm it can spellcheck all my languages. In any text field/area right click>Spell check>All your languages. If you have only one language there, then first go to right click>Spell check>Language settings>Language (click on it to expand)>Add languages. Feel free to add as many as you know and experiment. 

Thanks again and fingers crossed for a quick and easy fix.
Comment 8 Mike Kaganski 2019-10-02 05:45:02 UTC
> In any text field/area right click>Spell check>All your languages. If you have
> only one language there, then first go to right click>Spell check>Language
> settings>Language (click on it to expand)>Add languages. Feel free to add as
> many as you know and experiment. 

Unfortunately, this is something unrelated to the problem discussed here. It is obvious from the design of the spell checker feature in Chromium-based applications that Chromium *doesn't* detect the text language from keyboard layout, and relies on user explicitly telling it which dictionaries to apply to the text in the boxes. This "All your languages" selection wouldn't be necessary if Chromium could use the layout information to choose the dictionary itself - and this is exactly the problem raised here.
Comment 9 drd 2019-10-02 06:19:07 UTC Comment hidden (off-topic)
Comment 10 Mike Kaganski 2019-10-02 07:07:59 UTC Comment hidden (off-topic)
Comment 11 Mike Kaganski 2020-02-16 12:00:29 UTC
There are UI commands related to this:

> gsettings get org.gnome.desktop.input-sources sources
> gsettings get org.gnome.desktop.input-sources current
> gsettings get org.gnome.desktop.input-sources mru-sources

They are reported to have different shortcomings (e.g., "current" does not change in Ubuntu 17.10+; "mru-sources" only tracks user actions changing the layout, not switches between windows with different active layouts) - but maybe looking into what the commands do could allow to do that properly inside our gtk vcl plugin?
Comment 12 christos 2020-07-07 20:59:38 UTC
Until a technical solution can be found, making more languages readily available in the menus (instead of forcing the user to take several steps to open language-selection dialogs) could go some way towards easing language selection. This is true regardless of whether the user would like to have the input method change the language or whether he or she needs to prevent it from doing so. See attachment Description and suggestions to #tdf134628, especially the last paragraph.
Comment 13 Jan-Marek Glogowski 2020-11-22 16:07:54 UTC
I've just merged https://git.libreoffice.org/core/commit/9d96088c2832b681ae079b29cbc977231674ad52, which is like Caolan's suggestion in comment 3, but for Qt5. It doesn't fix this bug, because it just works for IM, like fcitx or ibus, but that might be sufficient for your use case.
Comment 14 Thomas Viehmann 2020-11-26 08:04:04 UTC
So there is this interface providing dbus notifications for language changes, used at least by gnome:


We currently subscribe to dbus signals for printer additions / removals:


Maybe code there could be an inspiration of how use signals to change the language.
Comment 15 Eyal Rozenberg 2022-12-12 22:55:34 UTC
So, assuming that this is exactly what's needed to resolve 62063, I'm raising the importance to Normal (and it may even be higher if we consider issues such as bug 148257 and bug 151290).
Comment 16 Buovjaga 2023-04-12 08:25:10 UTC
*** Bug 113298 has been marked as a duplicate of this bug. ***
Comment 17 Buovjaga 2023-04-12 08:25:16 UTC
*** Bug 154495 has been marked as a duplicate of this bug. ***
Comment 18 Eyal Rozenberg 2023-04-12 09:09:46 UTC
Please note the recent comments #10, #13 and #14 in dupe bug 113298 regarding mechanisms for determining the current keyboard layout.
Comment 19 Mike Kaganski 2023-04-12 10:09:04 UTC
*** Bug 61912 has been marked as a duplicate of this bug. ***