Locale setting would be equally wrong. Correct would be the keyboard locale.

Confirmed on Linux/KDE & Windows.

I think even the locale setting is not necessarily the right thing to follow, but rather the actual keyboard layout (probably with locale setting as fallback). But even using the locale setting would be an improvement, IMHO.

For example, in Estonia, many prefer English UI for OS and applications, but almost all of them nonetheless have Estonian layout on the keyboard (and as far as I have seen, also Estonian locale/date settings). This combination of English UI and Estonian keyboard layout effectively makes some of the LibreOffice default shortcuts (like Ctrl+Semicolon, or the newly added Ctrl+Shift+Comma) unusable. Using locale to steer this would solve this for at least a large part of users who prefer English UI otherwise.

If we use the actual keyboard layout we miss the option to change. Unsure if that's needed beyond QA. Mihkel's comment 2 is the primary use case.

Mihkel pointed out on the mailing list that switching the keyboard layout is a common task and we have to respond to this change. 

The pondering on a UI is done with development/debugging in mind. Could be still located in the expert settings (want to avoid a wall of language related options). But we definitely need some kind of feedback and I don't see how this additional dropdown can be avoided.

I suggest to start with connecting the keyboard layout to the locale setting first as this seems to be easy.

I am sorry I don't find the original post, but someone pointed out that he is using a customised keyboard mapped for his operating system. And so do I on both of my OS.

So I would like to ask you to consider the case of users have a personified keyboard-mapping. In my case would it be "QWERTY+" and LibreOffice might never found a corresponding entry in it's data.

So there has to be a fallback entry where LibreOffice actually use the UI-language to confirm it's key-bindings.

(In reply to Sascha Z from comment #5)
> I am sorry I don't find the original post, but someone pointed out that he
> is using a customised keyboard mapped for his operating system. And so do I
> on both of my OS.
> 
> So I would like to ask you to consider the case of users have a personified
> keyboard-mapping. In my case would it be "QWERTY+" and LibreOffice might
> never found a corresponding entry in it's data.
> 
> So there has to be a fallback entry where LibreOffice actually use the
> UI-language to confirm it's key-bindings.

I, too, use a rather personalised layout (with almost all letters physically rearranged based on their frequency in my native language and lots of extra letters/symbols added to AltGr-levels).

In case of most users with non-default layouts, it should be safe to assume that the vast majority of the letters/symbols typically found on the kb layout of their language/locale are still present (although possibly mapped to different physical keys).

Luckily, LibO doesn't care where a letter or symbol is physically located on the keyboard, so we don't need to know about each and every layout variation (which would be practically impossible anyway), we just need to know which set of letters and symbols is (typically) available on a kb layout of a given input language / locale.

What *would* cause issues when using custom kb layouts, however, is changed Shift-levels: if a symbol that requires pressing Shift on the layout (like ";" or "/") is used in a default shortcut in LibO, then that shortcut will either produce unexpected results or not work at all.

I don't think a fallback based on *UI* language (as opposed to system locale) would be particularly helpful, though, because many prefer their UI to be in English, even though their locale (and kb layout) is something else.

As a step in the right direction, I support switching the default shortcut keybindings to depend on locale setting.

The ideal solution here would be to provide a separated menu-entry for users to chose which key-bindings they prefer, with a fallback entry related to local settings.

But well, this would mean much work by extracting all the key-bindings out of the local settings to provide additional key-bindings.

(In reply to Sascha Z from comment #7)
> The ideal solution here would be to provide a separated menu-entry for users
> to chose which key-bindings they prefer, with a fallback entry related to
> local settings.
> 
> But well, this would mean much work by extracting all the key-bindings out
> of the local settings to provide additional key-bindings.

I'm not sure I understand what you have in mind. Do you mean something like a dropdown list in a settings dialog that would list *all* the available keyboard layouts the OS knows about? There are literally several hundreds of them...

Indeed, with the ideal solution do I mean a drop-down menu inside the languages settings that allows the user to chose what short-cuts he or she prefers.

But as I also mentioned does I guess this additional setting would become very work-intensive for us.

Most important to me is that there should be a fallback-solution to avoid errors.

Sorry, I completely missed the progress for thinking to much of my own case. When the keybindings are fixed on the local settings wouldn't it disturb with my custom keyboard.

So I am also for adjusting keybindings to local settings.

*** This bug has been marked as a duplicate of bug 115052 ***