The duplicate short name labels are a non-issue as we now (for bug 108458) provide specific UNO command identification and description for the controls when working with the Customize dialog.

It really is not worth the dev effort, nor i18n linguistic gymnastics, to attempt to resolve all duplicates--otherwise these are easy hackable for duplicate short labels that actually are substantive or unclear in context.

IMHO => WF

I too think, the "Keyboard" tab needs improvement.
There is a tooltip when hovering an entry. What information get users without using the mouse?
Showing an uno-command helps advanced users, but ordinary users likely need more information to distinguish the entries and find the desired one. Try it with search term "center" for example.
The "Toolbars" tab shows the icon of an entry. Why not the "Keyboard" tab too?

(In reply to Regina Henschel from comment #2)
> I too think, the "Keyboard" tab needs improvement.
> There is a tooltip when hovering an entry. What information get users
> without using the mouse?

Yes there probably should be a 'Description' panel to show the tooltip content, here on the 'Keyboard' and for the 'Notebookbar' tab to match what is provided for 'Menus', 'Toolbars', and 'Context Menus'

> Showing an uno-command helps advanced users, but ordinary users likely need
> more information to distinguish the entries and find the desired one. Try it
> with search term "center" for example.
> The "Toolbars" tab shows the icon of an entry. Why not the "Keyboard" tab
> too?

Think that is the best we can do, absent restoration of the local help provided descriptions, which are being pared down.

(In reply to Regina Henschel from comment #2)
> I too think, the "Keyboard" tab needs improvement.
> There is a tooltip when hovering an entry. What information get users
> without using the mouse?

I think the current implementation is not ideal for ordinary users and I too think the Keyboard tab needs improvement. However, I think it'll be a long time before we see the Keyboard tab redesigned.

I think that, for now, giving better function names and eliminating duplicates is a quick short term solution. The most difficult part would be to define new names for these functions.

I could try to propose some names and share here for other to comment on.

(In reply to V Stuart Foote from comment #3)
> Yes there probably should be a 'Description' panel to show the tooltip content, here on the 'Keyboard' and for the 'Notebookbar' tab to match what is provided for 'Menus', 'Toolbars', and 'Context Menus'

Is this information already available in the code? If so, we could use it to update the function names and provide better tooltips.

(In reply to Rafael Lima from comment #4)
> I think the current implementation is not ideal for ordinary users and I too
> think the Keyboard tab needs improvement. 

See bug 52335

> I think that, for now, giving better function names and eliminating
> duplicates is a quick short term solution. The most difficult part would be
> to define new names for these functions. I could try to propose some names 
> and share here for other to comment on.

Please do so. Hard to imagine that we find better short names. Let's check "Center":

CommonAlignVerticalCenter (Text Align > Center)
* Main menu (Format > Align Text > Center)
* Notebookbars

CellVertCenter (has tooltip "Center Vertically")
* Toolbars Table, Text Object, and drawtextobjectbar (unclear)
* Notebookbars

AlignMiddle (Align Objects > Center)
* Toolbars Align Objects and Drawing Objects (label used for tooltip which has not been set)
* Menus for OLE objects, frames, forms, graphics, drawings, and media (more in case of Draw/Impress) (missing to connect the pieces, however)
* Notebookbar

CenterPara (tooltop "Align Center")
* Toolbars formtextobjectbar, drawtextobjectbar, textobjectbar, singlemode
* Menu formrichtext
* Notebookbars

(plus some with similar text)

If we rename it, does it really help to see "Center Horizontally", "Center Text", "Center Paragraph", "Center Content", "Center Object" etc.?

Renaming a UNO command may break a lot of places where it's used. And all for no good reason but to make customization easier for experts who can read the tooltip?

=> my take: WF - not in respect to individual changes but to the revolutionary approach

(In reply to Heiko Tietze from comment #5)

> Renaming a UNO command may break a lot of places where it's used. And all
> for no good reason but to make customization easier for experts who can read
> the tooltip?

Hi Heiko! Maybe I did not make myself clear. When I say that I want to "rename functions" I do not mean to rename "UNO Commands", which I know will beak the code. What I mean is "rename the labels in the function list of the Customize Keyboard dialog".

When you go to Tools > Customize > Keyboard there is a list box named "Function", so what I am proposing is to update the labels shown in this list box.

What I noticed in the WriterCommands.xcu file is that the ToolTipLabel property could be used more often. Out of the approx. 490 commands there are only 69 tooltip labels. We could use this property to add tootips for all commands with duplicate labels.

For example, the "Center" labeled commands in the GenericCommands.xcu do not have tooltips for all instances. So maybe a good solution would be to provide tooltips for all duplicate entries.

What do you think of this approach? If everyone agrees, I can propose new tooltip labels for these duplicate entries.

(In reply to Rafael Lima from comment #6)
> 
> What do you think of this approach? If everyone agrees, I can propose new
> tooltip labels for these duplicate entries.

-1

I think it is a waste of effort. When Maxim and Jay reworked the labeling they established a mechanism for differentiating the labels depending on where they displayed in the UI (Menu, Toolbar, context menu, specific module, etc.)

The rules may need some tweaks here and there, but making the short name 100% unique in the customize dialog is not of sufficient demand to attempt to do this piecemeal.  And doing it as an additional class of labeling would require a lot of effort for what is a non-issue for users likely to customize (they'd know or quickly identify the correct UNO control to select). I'd like Maxims' take on what it would require.

Otherwise we should add the missing 'Description' frame to the 'Keyboard' and 'Notebookbar' tabs for a11y and consistency.

(In reply to Rafael Lima from comment #6)
> I do not mean to rename "UNO Commands"...
Sure, you modify the command to get a different string.

> So maybe a good solution would be to
> provide tooltips for all duplicate entries.
I'm all in for tooltips. What would be weird is when Center has a tip but all other alignments not. The documentation team, and in particular Seth, add extended tooltips in a considerable scale. Tip'ing UNO commands align with this effort, IMHO.

The rework of the keyboard customization tab is planned in bug 52335 and this should solve the issue when a name is unclear. It wont solve the issue of duplication, though. But from your list it's just "Borders (Shift to overwrite)". Let's do this particular issue with this ticket.

(In reply to Heiko Tietze from comment #9)
> The rework of the keyboard customization tab is planned in bug 52335 and
> this should solve the issue when a name is unclear. It wont solve the issue
> of duplication, though. But from your list it's just "Borders (Shift to
> overwrite)". Let's do this particular issue with this ticket.

I think it's a good idea to eliminate this duplicate entry. However, looking at:

/core/officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu

There is just a single "Borders (Shift to overwrite)" entry. I used OpenGrok to search if this entry is listed anywhere else, but couldn't find it.

Any idea where this duplicate might be coming from?

I am using LO 7.2 alpha built from source and this duplicate entry is still there.

(In reply to Rafael Lima from comment #10)
> Any idea where this duplicate might be coming from?
I think the problem here is that this command present it 2 categories at the same time (table and frame), and the "All commands" entry just combines the contents of all categories into a single list. We should either teach this list to filter duplicates, or decide on a single category for this command.

(In reply to Maxim Monastirsky from comment #11)
> I think the problem here is that this command present it 2 categories at the
> same time (table and frame), and the "All commands" entry just combines the
> contents of all categories into a single list. We should either teach this
> list to filter duplicates, or decide on a single category for this command.

Maxim, do you know where in the code happens the correlation between the GenericCategories and GenericCommands?

I tried my best but could not find where the association between the SetBorderStyle command and the Table / Frame categories is defined.

Muhammet, your expertise is needed here

(In reply to Rafael Lima from comment #12)
> Maxim, do you know where in the code happens the correlation between the
> GenericCategories and GenericCommands?
> 
> I tried my best but could not find where the association between the
> SetBorderStyle command and the Table / Frame categories is defined.

.uno:SetBorderStyle corresponds to the SID_ATTR_BORDER application slot. Searching *.sdi files for SID_ATTR_BORDER gives you:

- svx/sdi/svx.sdi - this is a global file, which puts the command in the format category.

And two overrides for Writer:

- sw/sdi/_frmsh.sdi - puts the command in the frame category.
- sw/sdi/_tabsh.sdi - puts the command in the table category.

cautionary note: any change to the "Label" will affect the notebookbar.