Bug 92237 - Mixed-Up Keyboard Shortcuts in spanish
Summary: Mixed-Up Keyboard Shortcuts in spanish
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.4.4.2 rc
Hardware: Other macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Shortcuts-Mac
  Show dependency treegraph
 
Reported: 2015-06-22 03:34 UTC by Daniel
Modified: 2024-03-03 03:15 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel 2015-06-22 03:34:53 UTC
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.
Comment 1 raal 2015-06-22 06:24:02 UTC
Mac store version of LO, cc Andras
Comment 2 Andras Timar 2015-06-22 07:05:19 UTC
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">
        <prop oor:name="Command">
          <value xml:lang="x-no-translate">I10N SHORTCUTS - NO TRANSLATE</value>
          <value xml:lang="en-US">.uno:SelectAll</value>
          <value xml:lang="es">.uno:Open</value>
        </prop>
      </node>

I personally agree with the reporter, but this behaviour has been there for ages (probably for compatibility with Spanish MS Office).
Comment 3 Alex Thurgood 2015-06-22 08:00:41 UTC
(In reply to Andras Timar from comment #2)
> 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">
>         <prop oor:name="Command">
>           <value xml:lang="x-no-translate">I10N SHORTCUTS - NO
> TRANSLATE</value>
>           <value xml:lang="en-US">.uno:SelectAll</value>
>           <value xml:lang="es">.uno:Open</value>
>         </prop>
>       </node>
> 
> 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.
Comment 5 Alex Thurgood 2015-06-22 09:38:58 UTC
@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.
Comment 6 Adolfo Jayme Barrientos 2015-06-22 16:23:01 UTC
(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.
Comment 7 Andras Timar 2015-06-22 17:19:25 UTC
(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.
Comment 8 Sebastian Silva 2017-04-08 04:17:12 UTC
Just to add that this issue is present in Debian Stretch (LibreOffice 5.2.6.2).

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.
Comment 9 Sebastian Silva 2017-04-08 13:52:37 UTC
Hi,
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.
Comment 10 Sebastian Silva 2017-04-08 13:54:03 UTC
(In reply to Sebastian Silva from comment #9)
> Hi,
> 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.
Comment 11 QA Administrators 2018-10-02 02:55:53 UTC Comment hidden (obsolete)
Comment 12 Julien Nabet 2020-03-02 15:33:40 UTC
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.
Comment 13 QA Administrators 2022-03-03 03:40:22 UTC Comment hidden (obsolete)
Comment 14 QA Administrators 2024-03-03 03:15:13 UTC
Dear Daniel,

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!

Warm Regards,
QA Team

MassPing-UntouchedBug