Download it now!
Bug 130405 - mismatch between command names and menu label for styles commands in Tools-Customize-Menus -- but they are consistent in "Toolbars"
Summary: mismatch between command names and menu label for styles commands in Tools-Cu...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Customise-Dialog
  Show dependency treegraph
 
Reported: 2020-02-03 23:04 UTC by sdc.blanco
Modified: 2020-02-18 13:53 UTC (History)
5 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 sdc.blanco 2020-02-03 23:04:50 UTC
1. Tools - Customize - Menus - (target) Styles
2. In "Search" field, type:  style
3. Here is a list showing some commands and menu items.

(command) - (menu)
Update      Update Selected Style
Edit        Edit Style
New         New Style from Selection
Styles      Manage Styles
Outline     Outline List


Removing a menu item and then adding the command item will give the correct menu item (e.g., remove "Update Selected Style", then add "Update" -- it will appear as "Update Selected Style")  

Question:  Shouldn't the command name be the same as the "menu" name? 
(it is confusing at first encounter)

(Also tested with 7.0.0.0.alpha)
Comment 1 sdc.blanco 2020-02-03 23:42:02 UTC
Continuing in "naive user" mode...

1.  If the "toolbar" tab is used instead of "menu" tab -- then commands listed before appear in the toolbar menu with the same command names.

2.  Tables Styles (command) becomes "Autoformat Styles" in the menu, but "Table Styles" in the toolbar.

No opinion about possible action -- but it is/was confusing to understand what was going on.
Comment 2 Dieter 2020-02-04 18:39:52 UTC
I confirm it with

Version: 7.0.0.0.alpha0+ (x64)
Build ID: eeb2d19e77d6dc47c68e8ba0920a02cf64a1247b
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-GB
Calc: threaded
Comment 3 V Stuart Foote 2020-02-04 19:02:04 UTC
Maxim & Jay spent a lot of effort hashing out this behavior--see also bug 108458, and there may be more labeling rules to refine.

Otherwise I don't have too much grief over the customization dialog, and if we could expose the commands/descriptions to the commands already present on the menus (bug 112237) that should suffice.

But still think we will need restoration of the more complete descriptions provided by the <ahelp> (bug 118148)--but available to both sides of the dialog.
Comment 4 Heiko Tietze 2020-02-17 16:57:51 UTC
There are places where short names are needed, eg on toolbars or when context is provided via submenu, and sometimes verbosity is better. For more details see https://design.blog.documentfoundation.org/2018/02/28/easyhacking-all-about-terminology/

The "naive user mode" has benjamin in mind but customization is Eve's business. So we can expect users to read the manual,. My take: WFM.
Comment 5 Dieter 2020-02-17 18:29:40 UTC
(In reply to Heiko Tietze from comment #4)
> The "naive user mode" has benjamin in mind but customization is Eve's
> business. So we can expect users to read the manual,. My take: WFM.

But we shouldn't force users too much, to read the manual. BTW: Have you checked, that this is part of the manual? I would expect consistency at least within a dialog.
Comment 6 Heiko Tietze 2020-02-18 13:53:56 UTC
I've seen the weird effect of adding a command. Smells like a bug. Muhammet might have an answer.