There are really strange Shortcuts in German UO I think there is only 1 possible way to resolve this problem. 1. Revert all Shortcut modifications in German UI since (August 2023?) 2. Discuss Problems which might exist with German native speaker experts and find solutions 3. Discuss impact of suggestions in (2) for international usability 4. Create and submit fixes.
See here: <https://bug-attachments.documentfoundation.org/attachment.cgi?id=192575> The Writer Shortcut list <Strg+0> ... <Strg+5> does not look very thoughtful. (Attachment is from Bug 159723 - GERMAN UI: Some of the shortcuts Ctl-0 … Ctl-9 ... don’t work as expected from earlier Versions)
Confirming, one of our customers was also shocked to see those in 24.2
Commits changing the German shortcuts: - 2d37ac2ca3a93cd7f05867ba7256c9e232192983 - f5ae03b235766070b1c1e5bf46d0cb86a8196b10 - e651d9e657f9b61fb45777d6e7edeb5cb95f8d27 - 691604d9037e72a94207d643cba29c64260b1cb9 - c0c8cffd3541e3cd616c96791b04e7ebf2b2ed03 - 3bd3c41bc930406ec3d995a45a7f7060d572bbd0 - 4b81692f8f3236082f9ac989e4e21c8119ff6e64
*** Bug 159709 has been marked as a duplicate of this bug. ***
*** Bug 159723 has been marked as a duplicate of this bug. ***
Created attachment 192602 [details] Example for LibO 7.6. wrong CALC shortcut listing Suggestions how and where to collect the changes in found commits and discuss pros and cons? And then include those with many pros as a complete solution An example what I am talking about. Old (LibO 7.6): <Strg+;> for insert date in Calc. There is no <;> in German Keyboard layout, ";" is <Umschalt+,>. So we needed to correct that. The real shortcut was <Strg+,> In 24.8. <Strg+.> for really insert date in Calc. But that collides with WRITER 24.8. New <Strg+.> for insert List So some discussion for best solution might be useful which are completely impossible like
*** Bug 159744 has been marked as a duplicate of this bug. ***
Hello, the changes were made in order to provide compatibility with other Office suits, such as MS office. But if some of them are incorrectly assigned or not feasible we can revert them of course. I tried them all with a German keyboard and German layout. They should work fine, i hope they do.
(In reply to Gökay ŞATIR from comment #8) > Hello, the changes were made in order to provide compatibility with other > Office suits, such as MS office. But if some of them are incorrectly > assigned or not feasible we can revert them of course. > > I tried them all with a German keyboard and German layout. They should work > fine, i hope they do. But, when we've done similar in the past, we've provided "compatability" keyboard/formatting modes via Tools -> Options per module, giving users a choice of mappings to use. Rather than changing the LibreOffice defaults. Some localization support is fine (e.g. for local keyboard diffs) but breaking what are LO norms in mass seems questionable.
*** Bug 159773 has been marked as a duplicate of this bug. ***
TIL that at least all shortcuts can be configured.
(In reply to Dirk Haar from comment #11) > TIL that at least all shortcuts can be configured. If you think of https://bugs.documentfoundation.org/show_bug.cgi?id=159744#c2: It is possible, but it is quite tediuos. And: you have to do this again for the next development version you want to test. My question, where these assignments are stored, has not yet been answered.
Hi, as my bug was called a duplicate of this one, some details: - unlike MS Office the Format types (H1, H2, H3, normal text) are not easily accessible so the shortcuts are needed. They cannot be manually assigned back for some reason. - ctrl+f is the normal search shortcut, the navigator is something different and always accessible through the sidebar, unlike the searchbar afaik (which has to be manually enabled) would be cool to just revert those
(In reply to amanita+LIBREOFFICE from comment #13) > Hi, as my bug was called a duplicate of this one, some details: > > - unlike MS Office the Format types (H1, H2, H3, normal text) are not easily > accessible so the shortcuts are needed. They cannot be manually assigned > back for some reason. You can revert them using *Tools>Customize>Tab Keyboard*. You first have to delete any previous assignment before being able to assign a new one to any function. First search your target key combination in the upper part *Shortcut Keys*, the mark the one you want to unassign, then click on *Delete*. Then you have to search in the lower part *Functions* for the function e.g. "Heading 2" to which you want to assign e.g. the key combination *Ctrl-2*. Alas, if you enter e.g. "Heading 2" under *Functions", you won't find anything! Category *All Commands* does not work! The UI of this function could be better! You first have to scroll down under *Category* to *Styles*, open *Styles>Paragraph* there. Then, in my example, Heading 2 shows up if it was in the Search entry. (If searching for "Heading 1", "Heading 1" and "Heading 10" would show up in the column *Function*). The last column *Key" lets you select, what was assigned there before (if anything). If there is anything you want to replace, use *Delete* to get rid of it. Then you can search for the new key combination in the upper part of the dialog "Shortcut key". You can mark an unassigned one and assign it by clicking on *Assign*. So that's pretty awkward. That's why I asked for the file, which stores these assignments. Spying around using file timestamps, it looks like ~/.config/libreofficedev/4/user/registrymodifications.xcu being the one which does it in Linux. It is part of the User Profile, see https://wiki.documentfoundation.org/UserProfile I assigned one more headline level for "Heading 6" to *Ctrl-6* and there appeared this line in ~/.config/libreofficedev/4/user/registrymodifications.xcu: <item oor:path="/org.openoffice.Office.Accelerators/PrimaryKeys/Modules/org.openoffice.Office.Accelerators:Module['com.sun.star.text.TextDocument']"><node oor:name="6_MOD1" oor:op="replace"><prop oor:name="Command" oor:op="fuse"><value xml:lang="en-US">.uno:StyleApply?Style:string=Heading 6&FamilyName:string=ParagraphStyles</value></prop></node></item> registrymodifications.xcu is a kind of elephant memory in which LibreOffice remembers many things, among them all kinds of things that you have done recently, e.g. which files you have worked with, which keywords you have searched for in them etc. It changes frequently and if you transfer it to another user, you could cause a data protection problem! > - ctrl+f is the normal search shortcut, the navigator is something different > and always accessible through the sidebar, unlike the searchbar afaik (which > has to be manually enabled) > > would be cool to just revert those You can re-assign *Ctrl-F" to the find dialogue, see above. The resulting line probably is <item oor:path="/org.openoffice.Office.Accelerators/PrimaryKeys/Modules/org.openoffice.Office.Accelerators:Module['com.sun.star.text.TextDocument']/org.openoffice.Office.Accelerators:Key['F_MOD1']/Command"><value xml:lang="de">vnd.sun.star.findbar:FocusToFindbar</value></item> The Navigator used to be assigned do *F5*. I have reverted all settings which I frequently use. Unfortunately, it all will get lost, as soon as I install the next development version. That's why I do this less frequently now until this is reverted or until I am told an easy way to re-establish a particular set of settings after installing a new development version. You are right: The team should revert all shortcut changes since last August as quickly as possible. And they should tell us how to get rid of all the data leak prone stuff from the elephant memory file registrymodifications.xcu.
Created attachment 192714 [details] "Überschrift" not found when assigning shortcut
No that did not work, see screenshot. I search for überschrift but nothing appears, while the others are assigned to that word, "heading" with same result.
Created attachment 192715 [details] Screenshot showing the right way amanita, you have to do it like shown in my attachment: Note that under *Category* you have to scroll down to open *Styles* and further select *Paragraph*. Then LO finds items with heading in it. Otherwise not. I consider this to be a (small) bug. I'll file an enhancement proposal in a few minutes.
The bug report is filed as https://bugs.documentfoundation.org/show_bug.cgi?id=159845. It's not a duplicate, but rather a proposal for enhancements of the Customize Keyboard dialog.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ac1bb5eda15dd3033c549a3df9c2c7b4862a6bbc tdf#159743: Revert all Shortcut modifications in German UI It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/74a12bcb96d8e602006be933d29ccc3c7238740d tdf#159743: Revert all Shortcut modifications in German UI It will be available in 24.2.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-24-2-1": https://git.libreoffice.org/core/commit/2967b5776b26644de416253da2fdbc8fcfb18c71 tdf#159743: Revert all Shortcut modifications in German UI It will be available in 24.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
thanks a lot @Xisco !
*** Bug 160552 has been marked as a duplicate of this bug. ***