The LibreOffice version from the Mac App Store, mixes up the keyboard shortcuts from the english and the spanish version. For example command-A ('Select all' in every other app in the Mac) is interpreted as 'Open', and command-O works for 'Open' as well.
In most applications in Mac OS X, regardless of the language, shortcuts are the same as in english, they are usually not translated.
Mac store version of LO, cc Andras
It is not App Store specific at all. See in officecfg/registry/data/org/openoffice/Office/Accelerators.xcu:
<node oor:name="A_MOD1" oor:op="replace">
<value xml:lang="x-no-translate">I10N SHORTCUTS - NO TRANSLATE</value>
I personally agree with the reporter, but this behaviour has been there for ages (probably for compatibility with Spanish MS Office).
(In reply to Andras Timar from comment #2)
> It is not App Store specific at all. See in
> <node oor:name="A_MOD1" oor:op="replace">
> <prop oor:name="Command">
> <value xml:lang="x-no-translate">I10N SHORTCUTS - NO
> <value xml:lang="en-US">.uno:SelectAll</value>
> <value xml:lang="es">.uno:Open</value>
> I personally agree with the reporter, but this behaviour has been there for
> ages (probably for compatibility with Spanish MS Office).
Andras, FWIW, there are many other places on Mac LO where keyboard assignment is screwed up.
See also :
@Daniel : please check with the existing bug reports on keyboard shortcut problems on OSX to see if one of them corresponds to your situation. If you don't know how to search bugzilla, you can start with the link I've provided in comment 4
Please report back your findings here.
Setting to NEEDINFO, pending requested information.
(No idea why the OP is being vaguely requested to search Bugzilla and add more “findings”… That is a triager’s job!)
Yeah, I agree that keyboard shortcut localization should be disabled in OS X at least. That would fix bug 79933 and, partially, bug 90546 (which suggests to kill it completely). It apparently causes more problems than it solves – clashes are frequent in some locales, not only Spanish.
(In reply to Adolfo Jayme from comment #6)
> Yeah, I agree that keyboard shortcut localization should be disabled in OS X
> at least. That would fix bug 79933 and, partially, bug 90546 (which suggests
> to kill it completely). It apparently causes more problems than it solves –
> clashes are frequent in some locales, not only Spanish.
There is the install:module="unxwnt" attribute, so you can kill it for Mac only.
Just to add that this issue is present in Debian Stretch (LibreOffice 184.108.40.206).
It is small, but annoying and I haven't found a workaround.
It also happens with Ctrl-N which is both mapped for "New Document" and "Bold" (but only does the latter).
I think it's fine to have localized shortcuts but they should be (automatically?) double-checked to not conflict with each other. Perhaps a user might want to toggle this under Options > Accessibility or Language? I went looking for an option.
I'm using Spanish from Spain for UI.
Thanks in advance.
I took another look and it turns out that there is actually another keybinding for "New Document" -> Ctrl-U is listed under Options > Personalize
However in the File menu, Ctrl-N is listed as the keybinding. This is confusing and wrong.
Possibly then #85978 is related.
I consider this an important bug as it is very evident and feels very unprofessional.
(In reply to Sebastian Silva from comment #9)
> I took another look and it turns out that there is actually another
> keybinding for "New Document" -> Ctrl-U is listed under Options > Personalize
I think it is "Tools > Customize" in English.
By the way, Ctrl-U actually does open a new document.
** Please read this message in its entirety before responding **
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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
If I well understood https://bugs.documentfoundation.org/show_bug.cgi?id=116599#c3, help part is fixed but not code yet.
According https://bugs.documentfoundation.org/show_bug.cgi?id=116599#c5, caution should be used.