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.

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.

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. ***

The phenomenon discussed in bug 161850 may be relevant: There's different behavior for different keyboard layouts, already; so it seems like there is a way to detect the keyboard layout, or something about it.

(In reply to Buovjaga from comment #14 on bug 113298)
> A verbose layout query would be:
> 
> setxkbmap -query -verbose 10

On my system, with XOrg, this gives me the set of cycle-able layouts, but not the current one, e.g.

layout:     us,il
variant:    ,

regardless of whether I'm typing Hebrew or English.

But here's a small and poorly-designed repository which tells you what the current layout is:

https://github.com/nonpop/xkblayout-state

basically, it uses X11/XKBlib.h

and makes a few calls it. See this file:

https://github.com/nonpop/xkblayout-state/blob/master/XKeyboard.cpp

if xkb is also available on Wayland then this might work too; otherwise - I would be quite happy with an initial implementation that only works on X.

How to automatically set the language in LibreOffice-Writer when changing the keyboard layout with a shortcut on Linux, in order to have the correct Spell-checking and Grammar-checking.

My Distro is LinuxMint 22 (Wilma) with Cinnamon Desktop.
I do NOT use ibus, it didn’t work for me.
This should probably work on other Distros too.

Step for Step Instructions:
1. Get the tool of “brs-brs” from https://github.com/brs-brs/getxkblayout
2. Start a Terminal and enter “sudo apt-get install libxkbfile-dev”
3. Compile “getxkblayout” by just entering “make” in the directory where you unpacked the sourcecode of “getxkblayout”.
4. Copy “getxkblayout” in “/usr/local/bin”.
5. Go to Cinnamon-Settings → Keyboard → Layouts and add the Layouts you want/need. Under Options set “Ctrl+Space” as the shortcut for switching the layout (as only this was selectable on my German Version of Writer as a shortcut).
6. Create the file “~/.config/libreoffice/4/user/Scripts/python/SetLanguage.py” (if the directories “/Scripts/python/” do not exist, create them).
7. The content of the Python-script “SetLanguage.py” is:
import subprocess
import uno

def set_language_by_keyboard_layout():
    # Ausführen des Shell-Befehls und Abrufen des Layouts
    try:
        result = subprocess.run(['/usr/local/bin/getxkblayout'], stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
        layout = result.stdout.strip()
    except Exception as e:
        layout = "at"  # Fallback falls Fehler auftritt
    
    # Sprache basierend auf dem Layout setzen
    if layout == "at":
        language = "de"
        country = "AT"
    elif layout == "gr":
        language = "el"
        country = "GR"
    elif layout == "us":
        language = "en"
        country = "US"
    else:
        language = "de"
        country = "AT"  # Fallback auf Deutsch

    # Verbindung zu LibreOffice herstellen
    ctx = uno.getComponentContext()
    smgr = ctx.ServiceManager
    desktop = smgr.createInstanceWithContext("com.sun.star.frame.Desktop", ctx)
    model = desktop.getCurrentComponent()
    
    # Auf das aktuelle Dokument zugreifen
    if model is None:
        return

    view_cursor = model.getCurrentController().getViewCursor()
    text_cursor = model.Text.createTextCursorByRange(view_cursor)

    # Sprache auf den Cursorbereich anwenden
    locale = uno.createUnoStruct("com.sun.star.lang.Locale")
    locale.Language = language
    locale.Country = country
    
    text_cursor.CharLocale = locale
    view_cursor.CharLocale = locale

(change “language” and “country” according to your installed keyboard-layouts)

8. Go to Tools → Customize → Keyboard → Application Macros → My Macros → SetLanguage → (Function) set_language_by_keyboard_layout → Shortcut Keys → set “Ctrl+Space” as the shortcut.

9. Now go to Writer and start typing some text in various languages while changing the keyboard-layout with “Ctrl+Space”. After switching the layout the then written text will have the Language-setting according to the keyboard-layout, whether it is only one word, a sentence or a paragraph.

I found this solution and got the code from ChatGPT today, after many hours trying to get it done with a Basic-Macro (without success), and then ChatGPT suggested using the above python-script and some other bash-scripts and steps, but I figured that Step 8 would be a much better and cleaner solution.

Perhaps the developers of LibreOffice could use the above information in order to build this functionality in Writer and/or Calc etc.