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.
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.
Dear Heiko Tietze,
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 https://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://web.libera.chat/?settings=#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!