Description: Keyboard shortcuts do not work when the layout differs from the English one. Changing the order of the layouts does not change the situation. Ignoring the OS input language in the LO settings does not change the situation. Steps to Reproduce: 1.Switch to any language other than English. 2.Select the text in writer and press ctrl+B 3.You can see that the text has not become bold. Similarly, with copying and pasting text using hot keys - it doesn't work. Actual Results: Hotkeys only work with the English keyboard layout. Expected Results: Hot keys work correctly with any keyboard layout. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: 480(Build:2) CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: gtk4 Locale: ru-RU (ru_RU.UTF-8); UI: ru-RU 24.8.4-2 Calc: threaded
Forgot to clarify. The described behavior is observed when running with the parameter: SAL_USE_VCLPLUGIN=gtk4 libreoffice The specified launch parameter is necessary due to the strong inertia when moving through text or cells.
Dima, please wait for someone else to confirm that this is a bug. After that will be marked as New. Thanks for understanding.
I confirm the bug. $ libreoffice --calc # Everything is ok, Ctrl+C, Ctrl+X, Ctrl+V, Ctrl+Z work as expected # regardless of the current keyboard layout. $ SAL_USE_VCLPLUGIN=gtk4 libreoffice --calc # Ctrl+C, Ctrl+X, Ctrl+V, Ctrl+Z work if English (US) keyboard layout is # active. If Russian keyboard layout is active, then Ctrl+C, Ctrl+X, # Ctrl+V, Ctrl+Z have no effect. Fedora 38 @ x86_64, Gnome 44.10 (session type is x11), LibreOffice 7.5.9.2 50 (Build:2). (My setup is outdated a bit, I'll update it soon.)
(In reply to Van from comment #3) > I confirm the bug. > > 7.5.9.2 50 (Build:2). (My setup is outdated a bit, I'll update it soon.) Ok, try 24.8 or 25.2.
If I'm not wrong, shortcuts are localized. Maybe this https://ask.libreoffice.org/t/how-to-put-short-keys-in-english-in-a-spanish-libreoffice/8687 can help.
I changed the interface language to English completely in the tab: Tools -> Options -> Lauguages and Locales -> General. This change did not produce the expected result. Hot keys still work on the English layout. Hot keys do not work on the Russian layout.
I confirm, it's more specific: *Some* keys do not work under different keyboard layout(s). Examples: the key W is mapped in my keyboard layout to apostroph (') Pressing Ctrl+W (english keyb) closes current document/workbook) Pressing Ctrl+' (hebrew keyb) does nothing. They are the same key, physically. An example for expected behavior: Pressing Ctrl+C (english keyb) AND pressing Ctrl+ב (hebrew keyb) both do "COPY TO CLIPBOARD" (also the same physical key). This is because Shortcuts are used to *simplify* and *standardize* user's work. The correct and expected behavior is using the same physical key for the same action: Shortcut keys use "muscle memory", and accessibility reasons (ctrl+C/ב) is just easy to press even with one hand. Interestingly, When you use Tools > Customize > Keyboard, to map an action to "Ctrl+," (control+comma key), In my computer (Hebrew/English layouts), BOTH Ctrl+, AND ctrl+" ( but same character in different layouts) will invoke the same action in both cases, under 2 different physical keys. The keys that I mapped to work "wrong" are all the keys which in my non-latin keyboard layout, are not letters; i.e. most punctuations: `/qw[];'\,.<>:";{}
(In reply to Dima from comment #0) > Steps to Reproduce: > 1.Switch to any language other than English. > [...] > Additional Info: > Version: 24.8.4.2 (X86_64) / LibreOffice Community > Build ID: 480(Build:2) > CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: gtk4 > Locale: ru-RU (ru_RU.UTF-8); UI: ru-RU > 24.8.4-2 > Calc: threaded I'm not sure whether this is a bug. As comment 5 mentions, shortcuts are localized, so since you're using Russian language (as the "UI: ru-RU" above indicates), keyboard shortcuts will also be the Russian ones, not the English ones. I can reproduce that the English Ctrl+B shortcut doesn't work for me when I switch UI language to German, but the German one Ctrl+Shift+F works then, which I think is the intended behavior. Why do you expect using the English shortcut should work when the UI locale is set to something different? Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7b9e27da2033192c628b23e4e1686209e951dadb CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: gtk4 Locale: en-GB (en_GB.UTF-8); UI: de-DE Calc: threaded
(In reply to Dima from comment #1) > Forgot to clarify. The described behavior is observed when running with the > parameter: SAL_USE_VCLPLUGIN=gtk4 libreoffice The behavior described in comment 8 is the same for me with the gtk3 VCL plugin. Do you see different behavior when using gtk3 instead of gtk4?
Dear Dima, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Dima, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp