Description: 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
Confirmed, but bug 61912 was closed as NOTABUG, so I will add needsDevAdvice keyword. Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.3.2 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
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.
On windows we get an explicit WM_INPUTLANGCHANGE message https://msdn.microsoft.com/en-us/library/windows/desktop/ms632629%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 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
Ok, let's set to NEW with the caveat that this needs more research to even determine, if this is doable.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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.
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.
> 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.
But it works, and that's what matters. I've tried it with 5 languages. Could be a workaround until you find a way to read the currently active system input language.
(In reply to drd from comment #9) > But it works, and that's what matters. I've tried it with 5 languages. Could > be a workaround until you find a way to read the currently active system > input language. When a problem discussed is "detecting system input language to apply the language to ranges of typed text", and you change the topic arbitrarily to "make spell check apply all its dictionaries to all text regardless of its language property", it is not an appropriate thing in bug tracker, each issue in which is to help *developers* fix some *specific* issue. Adding random off-topic comments just makes an issue unmanageable, and lowers chances of the issue to be fully read, understood, and fixed by a developer knowledgeable in the area. If you want, you can file an enhancement request like that ("As bug 108151 isn't fixed, please provide a workaround to apply all my dictionaries to all my text regardless of which language was set to it"), and even add this topic to its See Also.
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?
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.
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.
So there is this interface providing dbus notifications for language changes, used at least by gnome: https://www.freedesktop.org/software/systemd/man/org.freedesktop.locale1.html We currently subscribe to dbus signals for printer additions / removals: https://opengrok.libreoffice.org/xref/core/vcl/unx/generic/printer/cpdmgr.cxx?r=545f198a#494 Maybe code there could be an inspiration of how use signals to change the language.
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).
*** Bug 113298 has been marked as a duplicate of this bug. ***
*** Bug 154495 has been marked as a duplicate of this bug. ***
Please note the recent comments #10, #13 and #14 in dupe bug 113298 regarding mechanisms for determining the current keyboard layout.
*** Bug 61912 has been marked as a duplicate of this bug. ***