Bug 134470 - Keybinding is defined by UI language instead of locale setting
Summary: Keybinding is defined by UI language instead of locale setting
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Shortcuts-Locale
  Show dependency treegraph
 
Reported: 2020-07-03 09:00 UTC by Heiko Tietze
Modified: 2020-07-16 13:48 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Tietze 2020-07-03 09:00:02 UTC
The keybinding should follow the tools > options > language > locale setting but instead is attached to the UI language. Happened for https://gerrit.libreoffice.org/c/core/+/94305 where accelerator <value xml:lang="de">.uno:InsertCurrentDate</value> is set to COMMA_MOD1 executing .uno:InsertCurrentTime.

Seeking for opinions here.
Comment 1 Eike Rathke 2020-07-03 10:18:21 UTC
Locale setting would be equally wrong. Correct would be the keyboard locale.
Comment 2 Mihkel Tõnnov 2020-07-03 10:22:15 UTC
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.
Comment 3 Heiko Tietze 2020-07-03 20:30:30 UTC
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.
Comment 4 Heiko Tietze 2020-07-09 07:21:19 UTC
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.
Comment 5 Sascha Z 2020-07-14 10:06:35 UTC
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.
Comment 6 Mihkel Tõnnov 2020-07-14 12:53:38 UTC
(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.
Comment 7 Sascha Z 2020-07-14 13:25:09 UTC
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.
Comment 8 Mihkel Tõnnov 2020-07-14 13:43:01 UTC
(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...
Comment 9 Sascha Z 2020-07-14 13:55:41 UTC
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.
Comment 10 Sascha Z 2020-07-16 13:48:43 UTC
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.