Hotkeys are language dependent and work in English language only. While writing in any other language i.e. any Cyrillic, it's impossible to use hotkeys, they just don't do anything. Switching to English input language enable hotkeys once again. This is very frustrating as user needs to switch language to save document, to make it bold, or italic, etc.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Adding more info. Verified and reproduced on: 3.4.3, 3.4.4, 3.5.0.beta1 and 3.5.0.beta2. Mac OS X specific. Steps to reproduce: 1. Launch Writer. 2. Change language to Russian. 3. Press Cmd+B to change font weight to bold. Error: Font weight does not get changed. System error sound is played instead. Expected: Font weight changed to bold. Note that some other system hotkeys work as expected. I.e. Cmd+S to save, or Cmd+O to open document still work regardless of input language. Other critical key combinations that don't work: Cmd+I, Cmd+U and so on, all text manipulation hotkeys are English-only. One may assume that hotkeys don't work correctly in text area, but do work for UI. Workaround 1: Click toolbar button to apply corresponding style. Workaround 2: Change language to English, press desired hotkey, then switch language back to russian. The issue is critical, as it make text editor very slow for keyboard-only typing.
*** Bug 57290 has been marked as a duplicate of this bug. ***
Reproduced in 6.6.4.3 on Mac OS X 10.7.5.
I also confirm this in LibreOffice 3.6.3, and it is really annoying to change keyboard to En, only to use a shortcut and then change it back to whatever it was and then continue. I use Fedora, but this problem was not occurred in Fedora 17 or Windows, as they both use a different keyboard handling method than Fedora 18 (http://fedoraproject.org/wiki/Common_F18_bugs#Installer_does_not_automatically_set_up_multiple_keyboard_layouts_and_switch_command). But now in Fedora 18, lots of program are affected by this change. Applications such as gedit, nautilus, fileroller (Archive Manager) which are parts of gnome act like before, which means there is no difference which keyboard layout is currently active, the keyboard shortcuts work OK. But other applications usually is not the same, like LibreOffice, Zim, Blender, ... . So, I don't know where the problem is, but as (let say native) gnome applications are working fine, so there must be a way to solve this problem with others.
The problem still exist in LibreOffice 3.6.5.2 in Fedora 18. I realy dont know why no developer really pay attention to fix this problem. It may looks like that it is not important but it really affected the productivity of LibreOffice for non-Latin users.
Today I downloaded LibreOffice 4.0.0.3 from the official website and the problem still is there. I also install all available desktops in Fedora 18 repo and test LibreOffice against theme to check whether the problem of keyboard shortcuts in non-latin layout is steal exist or not: KDE: No problem MATE: No problem XFCE: No problem LXDE: Problem exist Cinnamon: Problem exist All the three first desktops still use the same keyboard handling as they used to be, but Cinnamon is based on gnome 3 and inherits its problems, and I have no idea about LXDE problem. I really hope someone at last pay some attention to this problem and attempt to fix it.
Today I also use the JHBuild tool on Fedora 18 to compile the Gnome 3.7.5 from their external module sets which contain the released tarbals. (http://ftp.gnome.org/pub/GNOME/teams/releng/3.7.5) Well, not too surprising, the problem is still exist using Gnome 3.7.5 and LibreOffice 4.0.0.3. This means that LibreOffice needs to make some changes in its keyboard shortcut handling, as it's likely that gnome is not and will not follow its old keyboard management. I am really hoping some developer at least look at this bug and put some information or notes here.
Here is how some other big open source products fix this issue: Mozilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=61190 https://bugzilla.mozilla.org/attachment.cgi?id=307428&action=diff Eclipse: https://bugs.eclipse.org/bugs/show_bug.cgi?id=61190 According to this page Chromium fix this in version 3.0.196 afterwards, so it might have something helpful: http://code.google.com/p/chromium/issues/detail?id=16806 And also a patch for Gnome which I don't know how to make it work: https://bugzilla.gnome.org/show_bug.cgi?id=685676 https://bugzilla.gnome.org/attachment.cgi?id=230597
Sorry in last comment I sent the Eclipse link in Mozilla part.
*** Bug 62330 has been marked as a duplicate of this bug. ***
Confirm this bug still exists in LibreOffice 4.0.2.2. Very annoying. The only workaround is to use other apps, like gedit for example. All hotkeys work great in any language there. Using ArchLinux with latest GNOME-Shell 3.8 from gnome-testing repo.
I can confirm the bug exists in LibreOffice 4.0.2.2 on MacOS X 10.8.3. It's not a Linux-specific bug.
I can not confirm the bug on 4.1.0.0beta1 on Ubuntu. I selected a text, and pressed ctrl+b to make it bold. I tested with the input configured as: English, Arabic, Turkish & French results: normal behavior.
P.S.: I use cinnamon
*** Bug 63763 has been marked as a duplicate of this bug. ***
I have the same problem. When my keyboard layout is in a non-English language (in my case Fa) most shortcuts don't work (e.g. Ctrl+C, Ctrl+S, customized LO shortcuts). My system: Linux Mint Debian Edition Update Pack 6, XFCE 4.8, LibreOffice 3.5.4.2, both libreoffice-gnome and libreoffice-gtk packages installed. (In reply to comment #5) > ... > Applications such as gedit, nautilus, fileroller (Archive Manager) which are > parts of gnome act like before, which means there is no difference which > keyboard layout is currently active, the keyboard shortcuts work OK. But > other applications usually is not the same, like LibreOffice, Zim, Blender, > ... . Also in my case, as AshkanV mentioned in comment #5, many other applications work just fine. I'm in XFCE but I also have Gnome, KDE and Mate installed. And text editors of all of these DEs work correctly.
In the both links below they blame packages libreoffice-gtk or libreoffice-gnome. http://en.libreofficeforum.org/node/1586#comment-26769 http://ubuntuforums.org/showthread.php?t=1986133 Someone also suggested resetting LO user profile in duplicate Bug 63763: https://wiki.documentfoundation.org/UserProfile However as mentioned in comment #13 this bug could be reproduced in LibreOffice 4.0.2.2 on MacOS X 10.8.3, which complicates the situation.
Sina, resetting profile does not help. Also this bug is reproducible in 4.1.0.4.
This bug is reproducible on gnome-shell in ubuntu 13.10, which handles now keyboard events with the new gnome-settings-daemon instead of directing them to X. It is indeed a crucial issue for all of us who happen to work with a non-latin language.
Still exists in LibreOffice 4.1.2.2.
Still exists in 4.1.2.3.
All hotkeys are not working in all keyboards, except English. Verified and reproduced on: 4.1.2.3 on Ubuntu 13.10 Steps to reproduce: 1. Launch Writer. 2. Change language to Russian and write a text, then select a part of it. 3. Press Ctrl+X to cut a text. Error: Text will be on screen Expected: To cut selected text. Workarounds to use toolbar buttons or select English keyboard layout, use shortcut, select Russian layout. It is very important bug because make work very slow.
*** Bug 55585 has been marked as a duplicate of this bug. ***
See https://bugs.freedesktop.org/show_bug.cgi?id=55585#c0 for why this happens and how it could be fixed.
*** Bug 59045 has been marked as a duplicate of this bug. ***
*** Bug 71358 has been marked as a duplicate of this bug. ***
== TESTS WE DO == This bug found in: - Fedora 19 Gnome Shell - Fedora 19 Mate - Ubuntu 12.04 Unity - Ubuntu 12.04 Cinnamon - Ubuntu 13.10 This bug not found in: - Fedora 19 KDE - Mint 15 Cinnamon - Mint 15 XFCE - Debian 7.1 - Debian - nonstable XFCE - Ubuntu 10.04 Gnome 2.30 - Arch KDE Current behavior: Accelators don't work Expected behavior: Accelators works Operating System: Linux (Other) Version: 4.1.2.3 release
The original report is from the Mac, but the recent storm is for gtk. There are different backends involved. So there are really two different bugs in here. A Mac one and a Gtk one.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8cef6c7ec67aec88b339ca647e784afbabf190f8 Related: fdo#41169 fix GTK non-Latin keyboard layout with Latin shortcuts The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=390b9d88c47347ebc714808979fcf8bd4e66f5c1&h=libreoffice-4-2 Related: fdo#41169 fix GTK non-Latin keyboard layout with Latin shortcuts It will be available in LibreOffice 4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=82b5172954261e030a42bd6b3f4acc99807d0ee5 Resolves: fdo#41169 fix MacOSX non-Latin keyboard layout with Latin shortcuts The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
And the last patch should allow stuff like ctrl+b to work on the mac even if the current keymap is Russian, which is the other older half of this problem apparently.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d77483f0ab1a7f97ec41adfac66d98696adeef70&h=libreoffice-4-1 Related: fdo#41169 fix GTK non-Latin keyboard layout with Latin shortcuts It will be available in LibreOffice 4.1.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=5677b7a9e4d33d07e1f5ad9e5d591beb242c2dd6&h=libreoffice-4-1 Resolves: fdo#41169 fix MacOSX non-Latin keyboard layout with Latin shortcuts It will be available in LibreOffice 4.1.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=341dfe3a2e0f6f9e5bc1e7985cc4ccd00cf733ee&h=libreoffice-4-2 Resolves: fdo#41169 fix MacOSX non-Latin keyboard layout with Latin shortcuts It will be available in LibreOffice 4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
While I had trouble with this bug for a long time, I recently discovered that using m17n keyboard layout instead of xkb layout for Persian (fa_IR) completely resolves the problem in libreoffice 4.1.3 gnome 3.8.
(In reply to comment #37) > While I had trouble with this bug for a long time, I recently discovered > that using m17n keyboard layout instead of xkb layout for Persian (fa_IR) > completely resolves the problem in libreoffice 4.1.3 gnome 3.8. And I think the keyboard is actually Latin keyboard, my comment was completely irrelevant.
I could not verify the fix on a build from master, Debian testing 64bit, GNOME 3.8 with Hebrew keyboard layout. While using the Hebrew layout I can't use CTRL+C/V or CTRL+O in LibO. Switching to another application (e.g. a web browser) I could paste with CTRL+V although I'm in the Hebrew layout.
ֹUnsure if this is the same bug or even related; however, the issue persists with the Hebrew keyboard layout (while absent in (a) other Hebrew layouts (lyx, phoenetic) (b) other languages, including RTL (Russian, Arabic tested)). Ubuntu 13.10 64-bit Unity 7.1.2 LibreOffice 4.2.0.4 Steps to reproduce: 1. Add Hebrew keyboard layout. 2. Open Writer. 3. Switch to Hebrew layout. 4. Type a string. 5. Attempt to use CTL+A/C/V/X.
Moving to mab4.1 (Bug 60270) because: - 4.0 reached EOL (End Of Life) - bug confirmed in later version
Hello everyone! After months of switching layouts and banging my head against this bug, I thought I should check LibreOffice settings (I'm using 4.1.5.3 now). What figures? I did find something. And in just a few clicks. This is not a bug! It's simply a matter of configuration. For the regular keyboard shortcuts (like Ctrl+C, Ctrl+V, etc.) to remain operational in LibreOffice applications while using a non-latin keyboard layout (like Greek or Russian), go to Tools -> Options -> Language Settings -> Languages, check the Ignore system input language option, save, and Bob's your uncle. Hope this helps. Cheers! PS Technically, though, shortcuts still remain language-dependent. This means if you enable this option, you will have to set your document languages manually.
The problem is with formatting shortcuts like Ctrl-B/Command+B and Ctrl-I/Command+I shortcuts that still don’t work after Setting “Ignore system input language option”. Ctrl-S/Command-S works even without this setting.
*** Bug 77163 has been marked as a duplicate of this bug. ***
is this bug still valid in 4.2.x branch? if yes, please move it from mab4.1 to mab 4.2 list since 4.1.x is EOL
Bug still exists in LO 4.2.3.3 on ubuntu 14.04 with hebrew layout.
The problem still occurs with LibO 4.2.5 on Debian unstable (Gnome 3), but doesn't on 4.2.5 on Ubuntu 10.04 (Official DEBs, not from distro) with Gnome 2.30. Can anyone confirm/deny on KDE/qt so we could narrow this to Gnome 3?
I tested that on Arch (Anteragos), with gnome 3.12 Build ID: 4.2.5.2 Arch Linux build-1 The bug still exists.. (I can test on ubuntu 12.04 if needed as well)
Version detail should be set to the earliest release the issue is confirmed on, please do not advance it--a note in a comment is all that is required. Resetting to original reporting.
Confirming that this bug STILL exists in: $ uname -a Linux localhost.localdomain 3.14.5-200.fc20.x86_64 #1 SMP Mon Jun 2 14:26:34 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/fedora-release FXorg -version X.Org X Server 1.14.4 Release Date: 2013-10-31 X Protocol Version 11, Revision 0 Build Operating System: 3.14.3-200.fc20.x86_64 Current Operating System: Linux localhost.localdomain 3.14.5-200.fc20.x86_64 #1 SMP Mon Jun 2 14:26:34 UTC 2014 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-3.14.5-200.fc20.x86_64 root=UUID=64bb5aa4-a945-4e0e-8d4d-776f44302cd1 ro rootflags=subvol=root vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_US.UTF-8 Build Date: 27 June 2014 01:35:28AM Build ID: xorg-x11-server 1.14.4-11.fc20 Current version of pixman: 0.30.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version.edora release 20 (Heisenbug) $ libreoffice --version LibreOffice 4.2.6.2 420(Build:2) Tools -> Options -> Language Settings -> Languages -> Ignore system input language - Checked as advised by commenter Paulo Fino, still no hotkeys :-(
This bug exists in a fully-updated Arch system: $ uname -a Linux XXXXX 3.17.3-1-ARCH #1 SMP PREEMPT Fri Nov 14 23:13:48 CET 2014 x86_64 GNU/Linux $ libreoffice --version LibreOffice 4.3.4.1 430m0(Build:1) Please fix this annoying bug, it prevents non-English locale users from getting any meaningful work done.
moving this bug to mab4.3 list since 4.2.x is END OF LIFE
This bugreport got non-actionable in the meantime I am afraid; we should close it as per comment 33, because fixes of 2 problems were already provided, and also the information about the "Ignore system input language" seems to be helpful. If there are still trouble with the shortcuts, please file that as separate report, and provide the following information: * your locale / language settings * your desktop environment, and its version * LibreOffice version * try also with the latest LibreOffice 'fresh' version, and tell if it is still present there * if it is affected by Tools -> Options -> Language Settings -> Languages -> Ignore system input language * exact reproduction steps (in the affected locale) Thank you all for the reports and fixes!
*** Bug 47314 has been marked as a duplicate of this bug. ***
Not really about RTL'ness or CTL'ness of any language.