Bug 108458 - Label changes for Toolbar use degrade function listing in the Customize dialog--have duplicate entries on the list
Summary: Label changes for Toolbar use degrade function listing in the Customize dialo...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 56811 112826 117528 118733 120392 121085 (view as bug list)
Depends on:
Blocks: Customize-Dialog UX UNO-Command-Label
  Show dependency treegraph
 
Reported: 2017-06-11 08:35 UTC by V Stuart Foote
Modified: 2018-10-31 23:06 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
dirty patch to demonstrate a concept, don't push! (20.07 KB, patch)
2017-11-02 16:01 UTC, Maxim Monastirsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2017-06-11 08:35:55 UTC
Have an unintended issue in the Customize dialog's Keyboard tab, with the Format category functions listing, where the "Label" assigned to commands are used multiple times. 

From 5.3.0.3 we have duplicates of Increase/Decrease for: Paragraph Spacing, Font Size, & Indent

Because commands are named the same, the Customize dialog Keyboard tab's Category "Format" and Function listing has duplicated entries of "Increase" and "Decrease" with no means to identify the element being formatted by the custom key assignment.

If the labels have to remain short for use with Toolbar buttons, could the entry in the customize Function list be pulled from the "Tooltiplabel" instead?

=-ref-=
http://opengrok.libreoffice.org/more/core/officecfg/registry/data/org/openoffice/Office/UI/GenericCommands.xcu?full=increase+decrease+indent

https://gerrit.libreoffice.org/28742

https://cgit.freedesktop.org/libreoffice/core/commit/?id=37ad8daabf596e039b4ca62e06e91d5a83128b7c
Comment 1 Yousuf Philips (jay) (retired) 2017-06-11 13:59:13 UTC
(In reply to V Stuart Foote from comment #0)
> If the labels have to remain short for use with Toolbar buttons, could the
> entry in the customize Function list be pulled from the "Tooltiplabel"
> instead?

So the *Command.xcu files has 4 labels that it can pull from (Label, ContextLabel, TooltipLabel, PopupLabel) and with changes in the menu, toolbar, and notebookbar, labels have been modified recently.

I guess Tooltiplabel could be used, but it would have a descriptive label like 'Paste Clipboard Contents', while a label of 'Paste' would be sufficient. Also Tooltiplabel isnt always defined, so it will need to be able to fallback on

Maxim: What is your take on this, as this issue did popup before.
Comment 2 Maxim Monastirsky 2017-10-27 09:17:41 UTC
Here is what I think about the whole situation:

Storing command labels in a central place such as the officecfg module, as opposed to specifying them in the toolbar/menu xml directly, has the advantage of having a single string for each command. The disadvantage is that it makes it impossible to fine-tune labels in certain places, such as different kinds of ui elements.

This led to the introduction of several "kinds" of labels: ContextLabel, PopupLabel and TooltipLabel. Given that for most commands the label is the same for all kinds of ui elements, and to avoid duplicating strings, a layering scheme was developed: All types of labels inherit from the regular Label, and use it as a last-chance fallback. Also, as a higher priority fallback, TooltipLabel inherits from PopupLabel, and PopupLabel inherits from ContextLabel. In addition, menu commands usually have keyboard accelerators, and commands that lead to a dialog have also ellipsis, but toolbar buttons shouldn't have any of those. And in many cases the presence of an accelerator and/or ellipsis is the only difference between the menu and toolbar label. The solution was to have accelerator & ellipsis in "Label", but strip them at runtime for toolbar buttons. This "stripped" variation is also what we use for the customization dialog.

This layering thing besides being just terribly confusing and complex, is far from solving our problems, as in some cases we want a different label for the same command in the same kind of ui element, but in a different location. The most famous example is slide/page commands in Impress/Draw. To solve this I introduced what I call "command aliases", which allow having a different identifier for the same underlying command. The idea is similar to shortcuts in Windows: Putting an alias on a toolbar/menu is like putting a shortcut on the desktop. It's not the real command, and therefore can have different label/icon. Basically it tries to bring the best of all worlds: Having a centralized storage of labels, while still be able to override the default label of a specific toolbar/menu item. What's good is that the override is stored inside officecfg/ instead of in a toolbar/menu xml file, so the same override can be reused in other places too.

But now that we have aliases, it makes the ContextLabel and PopupLabel properties largely unnecessary, as they can't solve all problems, at the same time that aliases can do the same and even more. The more I think about it, I come to the conclusion that the whole idea of several label properties and their complex fallback mechanism was a big big mistake. Besides not being able to handle the Impress/Draw case it has several other problems. Let's take an example: "Paste Special" is called "More Options..." in the context menu, and if one customizes the context menu and adds "Paste Special" somewhere else, by default it will be called there also "More Options...", because that's what PopupLabel dictates, although it doesn't make any sense. In addition, because TooltipLabel inherits from PopupLabel, if one customizes the toolbar with "Paste Special", its tooltip will be "More Options". To avoid that, we can add an explicit TooltipLabel="Paste Special" override, but then both Label and TooltipLabel will have the same string. In general, the duplicate strings problem arises a lot with PopupLabel, as in many cases it's actually the same as Label, but still has to be explicitly added to override ContextLabel.

So my suggestion is:

1. "Label" always contains the complete command name, thus suitable for the customization dialog (It can also have accelerator & ellipsis which we can strip at runtime if needed).
2. "TooltipLabel" should fallback then to "Label" directly, instead of the weird PopupLabel->ContextLabel->Label fallback path.
3. "ContextLabel" will override "Label" for all kinds of ui elements (toolbar/menubar/popupmenu). Typical use case is having a shortened label (assuming that if all need a shortened label, probably it will be the same).
4. In case not all ui elements want the same label, then those that need the long variation will use the original command, and the special (e.g. short) variation will be handled using an alias.
5. "PopupLabel" becomes unused and will be removed.
6. To make it easier to identify aliases, they can just append a context to the original command (e.g. ".uno:EditStyle:stylesmenu"), instead of inventing new command names each time.

Thoughts?
Comment 3 Yousuf Philips (jay) (retired) 2017-10-27 12:28:31 UTC
(In reply to Maxim Monastirsky from comment #2)
> 1. "Label" always contains the complete command name, thus suitable for the
> customization dialog (It can also have accelerator & ellipsis which we can
> strip at runtime if needed).

+1 as it focuses on the entry that is always assigned and targeting the menu bar

> 2. "TooltipLabel" should fallback then to "Label" directly, instead of the
> weird PopupLabel->ContextLabel->Label fallback path.

+1 as tooltip will be descriptive form of Label string

> 3. "ContextLabel" will override "Label" for all kinds of ui elements
> (toolbar/menubar/popupmenu). Typical use case is having a shortened label
> (assuming that if all need a shortened label, probably it will be the same).

Toolbar label will normally need the shorter form, while menubar and popupmenu normally dont.

> 4. In case not all ui elements want the same label, then those that need the
> long variation will use the original command, and the special (e.g. short)
> variation will be handled using an alias.

Dont really like the idea of separating this.

> 5. "PopupLabel" becomes unused and will be removed.

PopupLabel will always be useful as it can have a different accelerator key than the menubar or a completely different label, e.g. 'More Options...', 'Close Preview' (.uno:PrintPreview)

> 6. To make it easier to identify aliases, they can just append a context to
> the original command (e.g. ".uno:EditStyle:stylesmenu"), instead of
> inventing new command names each time.

i think aliasing should be done within a <prop> element rather than with a new node.

So here is my suggestion :D

1. Label - same as maxim's (will normally be either suitable for the toolbar, menubar, or tooltip label)
2. TooltipLabel - same as maxim's
3. ContextLabel will be used when Label is suitable for toolbar and will be used for menubar and context menu, else fallback on Label
4. PopupLabel for context menu, when a different accelerator or label is needed than what is found in ContextLabel or Label
5. ToolbarLabel will be used when Label is suitable for menubar and will be for the toolbar and notebookbar, else fallback on Label
6. We also need a mechanism to assign any of these entries to another label without having to type its label again, as this would reduce translation work.
Comment 4 V Stuart Foote 2017-10-27 12:56:21 UTC
That rework seems reasonable, but please consider the a11y requirements in this. 

Have to be sure the "Label"/"TooltipLabel" (or the correct descriptive entry from local help) appropriate for the action gets consistently assigned to respond when our Assistive Technology (AT) accessibility support is enabled.

Would a more verbose "AccessibilityLabel" (merging the label/tooltiplabel with the extended description from the help article) over improved consistency rendering the UI for AT?
Comment 5 Maxim Monastirsky 2017-10-27 13:33:16 UTC
(In reply to Yousuf Philips (jay) from comment #3)
> > 3. "ContextLabel" will override "Label" for all kinds of ui elements
> > (toolbar/menubar/popupmenu). Typical use case is having a shortened label
> > (assuming that if all need a shortened label, probably it will be the same).
> 
> Toolbar label will normally need the shorter form, while menubar and
> popupmenu normally dont.
Are you sure? I got the impression that the menu usually uses the shorter form. e.g. open the insert menu, you have there "Image...", "Chart...", Fontwork...", and most of those don't appear in context menus anyway.

> > 4. In case not all ui elements want the same label, then those that need the
> > long variation will use the original command, and the special (e.g. short)
> > variation will be handled using an alias.
> 
> Dont really like the idea of separating this.
Is it really worse than adding the label directly into xml files? I understand that this requires writing the command name again in officecfg, but for that you get the possibility of reusing that label somewhere else, something you couldn't do if the label was in xml.

> > 5. "PopupLabel" becomes unused and will be removed.
> 
> PopupLabel will always be useful as it can have a different accelerator key
> than the menubar or a completely different label, e.g. 'More Options...',
So basically we shouldn't care about users adding paste special to a different place, and still getting there "More Options..." by default? That's why I suggested that a completely different label should go to alias.

> i think aliasing should be done within a <prop> element rather than with a
> new node.
Don't see much benefit in doing this, but will research if that's easily possible.

> So here is my suggestion :D
Thanks. I will take the time to think about it, and reply later. Anyway, some inline comments for now:

> 4. PopupLabel for context menu, when a different accelerator or label is
> needed than what is found in ContextLabel or Label
During my work on context menus, I noticed that in many cases (esp. in Calc)
PopupLabel is the same as Label, and needed only because ContextLabel uses the shorter form. So as long as we have PopupLabel fallback to ContextLabel, there will be no solution for the string duplication in this case. Similarly, if PopupLabel will fallback to Label, surely it will require duplicates for other cases. Which just shows us that the whole idea of relying on fallbacks is just broken by design.

> 6. We also need a mechanism to assign any of these entries to another label
> without having to type its label again, as this would reduce translation
> work.
That's already possible with aliases, but you seem to not like it for some reason. Maybe we should clearly define what are the problems of the current aliases implementation, and just try to address them?
Comment 6 Yousuf Philips (jay) (retired) 2017-10-27 16:16:50 UTC
Sorry Stuart, didnt fully get the a11y issue you were trying to address. Where you saying that in addition to whatever tooltip that is read by the screen reader, some additional instructions should be read?

(In reply to Maxim Monastirsky from comment #5)
> Are you sure? I got the impression that the menu usually uses the shorter
> form. e.g. open the insert menu, you have there "Image...", "Chart...",
> Fontwork...", and most of those don't appear in context menus anyway.

It maybe 50/50 between which one uses the shorter form, but that all depends on how much work i've been doing to improve the organization of the menu. ;D

> Is it really worse than adding the label directly into xml files? I
> understand that this requires writing the command name again in officecfg,
> but for that you get the possibility of reusing that label somewhere else,
> something you couldn't do if the label was in xml.

Didnt fully get what you meant here, but adding labels directly into the XML file means that they wont be translatable (e.g. bug 101566).

> So basically we shouldn't care about users adding paste special to a
> different place, and still getting there "More Options..." by default?
> That's why I suggested that a completely different label should go to alias.

I know i should have written this down in my last comment but i had to rush out. :D So if a user uses the customization dialog, the PopupLabel text wont be used when adding it to the context menu, the Label text will be used.

> During my work on context menus, I noticed that in many cases (esp. in Calc)
> PopupLabel is the same as Label, and needed only because ContextLabel uses
> the shorter form. So as long as we have PopupLabel fallback to ContextLabel,
> there will be no solution for the string duplication in this case.
> Similarly, if PopupLabel will fallback to Label, surely it will require
> duplicates for other cases. Which just shows us that the whole idea of
> relying on fallbacks is just broken by design.

Which is why i suggested number 6, which allows string duplication. Let me give an example, which i wanted to as well before but had to rush out. :D

<node oor:name=".uno:BasicShapes" oor:op="replace">
  <prop oor:name="Label" oor:type="xs:string">
    <value xml:lang="en-US">Basic Shapes</value>
  </prop>
  <prop oor:name="ContextLabel" oor:type="xs:string">
    <value xml:lang="en-US">~Basic</value>
  </prop>
  <prop oor:name="TooltipLabel" oor:type="xs:string">
    <value xml:lang="en-US">Insert Basic Shapes</value>
  </prop>
  <prop oor:name="PopupLabel" oor:type="xs:string">
    <value>TooltipLabel</value>
  </prop>
</node>

So in this example, PopupLabel is pulling in the label from TooltipLabel as both the Label and ContextLabel aren't suitable and this wont require the translation team to translate the tootlip string a second time.

> That's already possible with aliases, but you seem to not like it for some
> reason. Maybe we should clearly define what are the problems of the current
> aliases implementation, and just try to address them?

Aliases require additional translation, they dont appear in the customization dialog and would also separate labels from all appearing under a single uno command node, which will likely complicate things more.

Would be great if we could have a jitsi meetup and discuss all these issues once by live voice/text as i can see things will likely be miscommunicated by comments. If you have time, would be great if you can jump on telegram[1] or irc[2] when you are free, so we could find a suitable meetup time, or you can join the weekly design meeting[3] on thursday at 1pm UTC. You are free to do any of these outside of this issue as well, you to Stuart. :D

[1] https://t.me/joinchat/B-szpERIwOCjY_97ehftHA
[2] https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-design
[3] https://meet.jit.si/LibreOfficeDesign
Comment 7 V Stuart Foote 2017-10-27 17:59:48 UTC
(In reply to Yousuf Philips (jay) from comment #6)
> Sorry Stuart, didnt fully get the a11y issue you were trying to address.
> Where you saying that in addition to whatever tooltip that is read by the
> screen reader, some additional instructions should be read?
> 

What I'm asking is that however the labeling is reworked--that function for a11y be taken into account and made consistent as well.

For a11y we probably should be reading the descriptive tooltip for menu and button objects.  But currently 5.4.3, with keyboard movements (F10 -> F6 -> <Tab/ShiftTab>; or <UP,DOWN,LEFT,RIGHT>) just the short button/menu label is exposed.  

This contrasts to mouseover behavior which gets the descriptive tooltip--or the extended tooltip pulled from offline local help when installed (and auto-enabled when an AT is in use).

Differences between keyboard and mouseover event triggers are probably unavoidable--but as the labeling controls what is exposed to AT, it needs to considered as well while reworking label structure--and ideally make keyboard and mouseover expose the same tooltip/enhanced tooltip when traversing menus, context menus, and toolbars when Assistive Technology tool support is enabled.
Comment 8 Yousuf Philips (jay) (retired) 2017-10-27 19:22:56 UTC
I get the issue now Stuart and you should file an enhancement bug for a11y that it should read the button tooltip and not the labels in the toolbars, as this wont be something solved in this issue.
Comment 9 V Stuart Foote 2017-10-27 19:39:00 UTC
(In reply to Yousuf Philips (jay) from comment #8)
> I get the issue now Stuart and you should file an enhancement bug for a11y
> that it should read the button tooltip and not the labels in the toolbars,
> as this wont be something solved in this issue.

Will do, just want to be sure that while refactoring the labeling that we don't complicate what is needed for a11y support--and ideally facilitate it as tooltip/extended tooltip from help should be derived from the label structure in some fashion.
Comment 10 Maxim Monastirsky 2017-10-28 19:18:35 UTC
(In reply to Yousuf Philips (jay) from comment #6)
> It maybe 50/50 between which one uses the shorter form, but that all depends
> on how much work i've been doing to improve the organization of the menu. ;D
I think the rule is this: If the upper menu (either top level or the menu item which points to the current sub menu) says the context, then it's dropped from its sub menu items. i.e. in my example - because the top level menu says "Insert", the word "insert" doesn't need to be repeated in its menu items, so it's sufficient to just say "Image" or "Comment". If this is true, we might build on this rule (see below).

> Didnt fully get what you meant here, but adding labels directly into the XML
> file means that they wont be translatable (e.g. bug 101566).
Yes, I know. What I meant was "_if_ that was possible to do w/o translation problems". As we had similar possibility back in the days menus were in .src files, and I can't remember any complaints about it.

> So if a user uses the customization dialog, the PopupLabel text wont
> be used when adding it to the context menu, the Label text will be used.
The way to do this is probably to store the "Label" contents in the customized xml file (as we can't just ignore PopupLabel for customized menus, as it will affect the whole menu). But doing this will reintroduce Bug 101374.

> <node oor:name=".uno:BasicShapes" oor:op="replace">
>   <prop oor:name="Label" oor:type="xs:string">
>     <value xml:lang="en-US">Basic Shapes</value>
>   </prop>
>   <prop oor:name="ContextLabel" oor:type="xs:string">
>     <value xml:lang="en-US">~Basic</value>
>   </prop>
>   <prop oor:name="TooltipLabel" oor:type="xs:string">
>     <value xml:lang="en-US">Insert Basic Shapes</value>
>   </prop>
>   <prop oor:name="PopupLabel" oor:type="xs:string">
>     <value>TooltipLabel</value>
>   </prop>
> </node>
> 
> So in this example, PopupLabel is pulling in the label from TooltipLabel as
> both the Label and ContextLabel aren't suitable and this wont require the
> translation team to translate the tootlip string a second time.
Will need to check in the config reading code, if that's OK to have non-translatable string, inside an otherwise translatable property. Also will need to check how bad it will affect performance, as this will require to compare each and every string with a known set of property names.

> Aliases require additional translation
Why? Suppose there is a long string and a short string. The original command gets the long string, and everything that needs the long string uses the original command. The alias gets the short string, and everything that needs the short string uses the alias. I don't see any additional translatable strings.

> they dont appear in the customization dialog
This is by design. Alias is just another identifier for the same underlying command. How useful it is to have in the list several items pointing to the same command, but with a slightly different title? And anyway aliases should *not* appear in the keyboard tab, as aliases can't have kb shortcuts by their own, as allowing this will make it impossible to show the kb shortcut next to an alias menu item, because you can't assign the same kb shorcut to several command.

> and would also separate labels from all appearing under
> a single uno command node, which will likely complicate things more.
Don't see much problem here, as long as we put the alias next to the original command (or if we find a way to have the alias as a property inside the original command).

> Would be great if we could have a jitsi meetup and discuss all these issues
> once by live voice/text as i can see things will likely be miscommunicated
> by comments.
I will consider this, but usually I try to avoid live discussions, as my live communication abilities aren't that good.

----

Anyway I would like throw an additional idea:

1. Label - always full name, used for menus.
2. ContextLabel - always short name (where applicable), used for toolbars, fallback to Label. (And such usage aligns well with the name "ContextLabel", as short names are about dropping the context when it's obvious.)
3. PopupLabel - used for context menus, fallback to Label. (Ideally only for slight changes, like a different accelerator. Completely different name like "More Options" I would prefer to have in alias, and hopefully there will be no that much of them.)
4. Each context menu or a menu item which opens another menu (including top level menu) gets a new optional property "menu:contextlabel". When set to true, that menu will be forced to use ContextLabel instead of PopupLabel or Label. This is based on the rule I suggested in the beginning of this comment, that menus have a short label only when their parent item clearly says the context, so we will be able to mark those parents with the new property.
Comment 11 Yousuf Philips (jay) (retired) 2017-10-29 22:42:23 UTC
(In reply to Maxim Monastirsky from comment #10)
> I think the rule is this: If the upper menu (either top level or the menu
> item which points to the current sub menu) says the context, then it's
> dropped from its sub menu items. i.e. in my example - because the top level
> menu says "Insert", the word "insert" doesn't need to be repeated in its
> menu items, so it's sufficient to just say "Image" or "Comment". If this is
> true, we might build on this rule (see below).

Yes ContextLabel is normally short when the top level or sub menu give the context, but you also have entries where the hierarchy only helps with organization and the string is independent like File > Preview in Web Browser, Edit > Select All, View > Hide Whitespace, Format > Spacing > Increase Paragraph Spacing, Table > Merge Cells, Tools > Mail Merge Wizard.

> Yes, I know. What I meant was "_if_ that was possible to do w/o translation
> problems". As we had similar possibility back in the days menus were in .src
> files, and I can't remember any complaints about it.

So which xml files did you want to do this in (menus, context menus, toolbars)?

> The way to do this is probably to store the "Label" contents in the
> customized xml file (as we can't just ignore PopupLabel for customized
> menus, as it will affect the whole menu). But doing this will reintroduce
> Bug 101374.

If we added the label into the xml as mentioned above, we'd also have the same problem when changing the UI. Maybe we could use the 'Label' contents and it works in whatever UI the user switches to something like this.

<menu:menu menu:id=".uno:InsertFormMenu" menu:use_default_label="true">

> Will need to check in the config reading code, if that's OK to have
> non-translatable string, inside an otherwise translatable property. Also
> will need to check how bad it will affect performance, as this will require
> to compare each and every string with a known set of property names.

Check and see if there is a performance hit. If so, i know you'll figure out a way to do it without one :D

> Why? Suppose there is a long string and a short string. The original command
> gets the long string, and everything that needs the long string uses the
> original command. The alias gets the short string, and everything that needs
> the short string uses the alias. I don't see any additional translatable
> strings.

Could you give an xml example of this so i can better get it. :D

> This is by design. Alias is just another identifier for the same underlying
> command. How useful it is to have in the list several items pointing to the
> same command, but with a slightly different title? And anyway aliases should
> *not* appear in the keyboard tab, as aliases can't have kb shortcuts by
> their own, as allowing this will make it impossible to show the kb shortcut
> next to an alias menu item, because you can't assign the same kb shorcut to
> several command.

True that its just another identifier, but when users open up the customization dialog and search for example 'new slide' in impress as it appears in the Slide menu and dont find the entry and dont have any indication that its the same as 'new page', this isnt an easy issue for users to deal with.

> Don't see much problem here, as long as we put the alias next to the
> original command (or if we find a way to have the alias as a property inside
> the original command).

Yes i was trying to have the alias in the same original command in my example xml code. :D

> I will consider this, but usually I try to avoid live discussions, as my
> live communication abilities aren't that good.

Your text communications seem to be perfect, so dont know why your live communications would be any different. No need to be shy, you dont have to turn on your webcam if you dont want to. ;D

> Anyway I would like throw an additional idea:
> 
> 1. Label - always full name, used for menus.
> 2. ContextLabel - always short name (where applicable), used for toolbars,
> fallback to Label. (And such usage aligns well with the name "ContextLabel",
> as short names are about dropping the context when it's obvious.)
> 3. PopupLabel - used for context menus, fallback to Label. (Ideally only for
> slight changes, like a different accelerator. Completely different name like
> "More Options" I would prefer to have in alias, and hopefully there will be
> no that much of them.)
> 4. Each context menu or a menu item which opens another menu (including top
> level menu) gets a new optional property "menu:contextlabel". When set to
> true, that menu will be forced to use ContextLabel instead of PopupLabel or
> Label. This is based on the rule I suggested in the beginning of this
> comment, that menus have a short label only when their parent item clearly
> says the context, so we will be able to mark those parents with the new
> property.

Having somethings in the .xml files and some in the .xcu files means that you'd have to modify things in multiple places, which will make this task more difficult. I'm assuming you forgot to include TooltipLabel or is Label supposed to have the full descriptive name that would go into TooltipLabel.

So using this proposal, how would the the xml look for this current entry.

<node oor:name=".uno:BasicShapes" oor:op="replace">
  <prop oor:name="Label" oor:type="xs:string">
    <value xml:lang="en-US">Basic Shapes</value>
  </prop>
  <prop oor:name="ContextLabel" oor:type="xs:string">
    <value xml:lang="en-US">~Basic</value>
  </prop>
  <prop oor:name="TooltipLabel" oor:type="xs:string">
    <value xml:lang="en-US">Insert Basic Shapes</value>
  </prop>
  <prop oor:name="Properties" oor:type="xs:int">
    <value>1</value>
  </prop>
</node>

For me, defining a different entry for each place the string can appear in ensures that we always get exactly what we define.
Comment 12 Maxim Monastirsky 2017-10-30 09:00:32 UTC
(In reply to Yousuf Philips (jay) from comment #11)
> Yes ContextLabel is normally short when the top level or sub menu give the
> context, but you also have entries where the hierarchy only helps with
> organization and the string is independent like File > Preview in Web
> Browser, Edit > Select All, View > Hide Whitespace, Format > Spacing >
> Increase Paragraph Spacing, Table > Merge Cells, Tools > Mail Merge Wizard.
True. That's why my second proposal includes a way to mark those items which need their submenus to drop the context, and those which don't. (Unless we have both short and long labels in the same level of the hierarchy, in which case this proposal won't help.)

> > Yes, I know. What I meant was "_if_ that was possible to do w/o translation
> > problems". As we had similar possibility back in the days menus were in .src
> > files, and I can't remember any complaints about it.
> 
> So which xml files did you want to do this in (menus, context menus,
> toolbars)?
Nowhere. I was just saying that using aliases gives us the same flexibility as if we were putting labels in xml, as we're not restricted with having just one possible label for a given ui element type, and we don't need to fight with a complex fallback mechanism. Instead we define a label with an unique identifier, and just use that label where we need it. If we need another label, then again we define it with another unique identifier, and use it where needed.

> <menu:menu menu:id=".uno:InsertFormMenu" menu:use_default_label="true">
So if we're about introducing this per-item property to force the usage of "Label", what stops us from using this property in our default xmls (not just after customization), and that way resolve the short vs long strings problem in menus?

> > Why? Suppose there is a long string and a short string. The original command
> > gets the long string, and everything that needs the long string uses the
> > original command. The alias gets the short string, and everything that needs
> > the short string uses the alias. I don't see any additional translatable
> > strings.
> 
> Could you give an xml example of this so i can better get it. :D
Right now it can be like this:

 <node oor:name=".uno:EditStyle" oor:op="replace">
   <prop oor:name="Label" oor:type="xs:string">
     <value xml:lang="en-US">~Edit Style...</value>
   </prop>
   <prop oor:name="Properties" oor:type="xs:int">
     <value>1</value>
   </prop>
 </node>
 <node oor:name=".uno:EditStyle:toolbar" oor:op="replace">
   <prop oor:name="Label" oor:type="xs:string">
     <value xml:lang="en-US">Edit</value>
   </prop>
   <prop oor:name="TargetURL" oor:type="xs:string">
     <value>.uno:EditStyle</value>
   </prop>
   <prop oor:name="Properties" oor:type="xs:int">
     <value>1</value>
   </prop>
 </node>

But we'll be able to optimize it, so e.g. "Properties" could be inherited from the main command.

> True that its just another identifier, but when users open up the
> customization dialog and search for example 'new slide' in impress as it
> appears in the Slide menu and dont find the entry and dont have any
> indication that its the same as 'new page', this isnt an easy issue for
> users to deal with.
True. Which suggests that using aliases for the page/slide commands wasn't the ideal solution. Ideally we need a way to override the "Page" string, not to introduce a separate "Slide" string, and just switch the UI to it. But at least I hope that we can agree that there shouldn't be an additional "More Options" entry in the list, as "Paste Special" is already there, and so aliases fit perfectly in this particular use-case.

> Having somethings in the .xml files and some in the .xcu files means that
> you'd have to modify things in multiple places, which will make this task
> more difficult.
If you feel this will be more difficult, maybe we can do something similar in .xcu instead, so e.g. .uno:InsertMenu will be marked somehow as being a context command.

> I'm assuming you forgot to include TooltipLabel
It wasn't needed, as we have already reached an agreement about it (comment 3).

> So using this proposal, how would the the xml look for this current entry.
> 
> <node oor:name=".uno:BasicShapes" oor:op="replace">
>   <prop oor:name="Label" oor:type="xs:string">
>     <value xml:lang="en-US">Basic Shapes</value>
>   </prop>
>   <prop oor:name="ContextLabel" oor:type="xs:string">
>     <value xml:lang="en-US">~Basic</value>
>   </prop>
>   <prop oor:name="TooltipLabel" oor:type="xs:string">
>     <value xml:lang="en-US">Insert Basic Shapes</value>
>   </prop>
>   <prop oor:name="Properties" oor:type="xs:int">
>     <value>1</value>
>   </prop>
> </node>
It can stay the same, except that there will be a change in behavior, so the toolbar button label (not the tooltip!) will be "Basic" (but I assume this is good, as we're moving towards short toolbar labels). Will also need to mark .uno:ShapesMenu as contextlabel=true, so an additional change will be required in menubar.xml (or in .xcu, see above).
Comment 13 Yousuf Philips (jay) (retired) 2017-10-30 13:46:37 UTC
So let me be more clear about the issue of translation. What i'm hoping we can do is limit the amount of changes to the existing elements if they are not needed, as renaming the strings or moving them using your aliasising mechanism will require the translation teams to retranslate them, which was the primary reason for my string referencing mechanism mentioned in comment 2.
Comment 14 Maxim Monastirsky 2017-10-30 15:44:31 UTC
(In reply to Yousuf Philips (jay) from comment #13)
> So let me be more clear about the issue of translation. What i'm hoping we
> can do is limit the amount of changes to the existing elements if they are
> not needed, as renaming the strings or moving them using your aliasising
> mechanism will require the translation teams to retranslate them, which was
> the primary reason for my string referencing mechanism mentioned in comment
> 2.
Ah OK, I get your point now, but:

1. As we both agree that "Label" will have the full name, and that isn't the case for now, all those short names currently in "Label" will need to be re-translated anyway, even according to your proposal.

2. I know nothing about how translations work, but as we don't plan to change the strings themselves, only their context, maybe it will be possible to script the change, so it won't require re-translation of anything? If yes, I think that it worth spending the time on such script, if as a result we'll get a system that will better serve us in the long run.

Anyway, that's a good point. We shouldn't accept any solution that doesn't have a clear migration path for existing translations, and we shouldn't push any change before we have the solution for translations already in place.
Comment 15 Yousuf Philips (jay) (retired) 2017-10-30 20:05:20 UTC
(In reply to Maxim Monastirsky from comment #14)
> 1. As we both agree that "Label" will have the full name, and that isn't the
> case for now, all those short names currently in "Label" will need to be
> re-translated anyway, even according to your proposal.

I skimmed through 1/4 of GenericCommands.xcu and the majority of entries only had Label, while the ones that had Label and ContextLabel, the majority of them wouldnt need to be changed according to my proposal. When you say "full name" in Label, would that mean for example 'Insert Text Box' (which i would have under TooltipLabel) or just 'Text Box' for .uno:Text.

<node oor:name=".uno:Text" oor:op="replace">
  <prop oor:name="Label" oor:type="xs:string">
    <value xml:lang="en-US">~Text Box</value>
  </prop>
  <prop oor:name="TooltipLabel" oor:type="xs:string">
    <value xml:lang="en-US">Insert Text Box</value>
  </prop>
  <prop oor:name="Properties" oor:type="xs:int">
    <value>1</value>
  </prop>
</node>

> 2. I know nothing about how translations work, but as we don't plan to
> change the strings themselves, only their context, maybe it will be possible
> to script the change, so it won't require re-translation of anything? If
> yes, I think that it worth spending the time on such script, if as a result
> we'll get a system that will better serve us in the long run.

I dont fully grasp the concept myself, but each string is given a reference ID which is used to translate that particular string into whichever language. This reference ID can be found in the qtz UI and help language packs, but i dont fully grasp how this reference ID changes sometimes. I think moggi, cloph and/or kendy will have better info that you can get.

> Anyway, that's a good point. We shouldn't accept any solution that doesn't
> have a clear migration path for existing translations, and we shouldn't push
> any change before we have the solution for translations already in place.

Or ideally have a solution that has limited string changes. :D
Comment 16 Maxim Monastirsky 2017-10-31 00:36:29 UTC
(In reply to Yousuf Philips (jay) from comment #15)
> When you say
> "full name" in Label, would that mean for example 'Insert Text Box' (which i
> would have under TooltipLabel) or just 'Text Box' for .uno:Text.
Anything that fits the customization dialog is fine for "Label", so I believe "Text Box" is OK. The problem is mostly around some verb-only labels, like "Edit" for edit style, "Clear" for clear formatting, or "Increase" (which repeats 3 times in the list, for increase font, increase paragraph spacing, and increase indent). There is also a problem with "Left"/"Right" which repeat 3 times in the list, for paragraph align, and for object align.
Comment 17 Maxim Monastirsky 2017-11-02 16:01:32 UTC
Created attachment 137469 [details]
dirty patch to demonstrate a concept, don't push!

Jay: So I was playing with improving our aliases offering, and I'm attaching now a patch that shows a few new ideas. The code there is horrible, and isn't mean to be pushed in its current state, but it should be otherwise functional. Would be great if you could give it a try, and give feedback about the new ideas (can be applied to your tree using 'git am 0001-aliases-WIP.patch').

What it tries to do is:

1. Define alternative labels inside the same node, instead of a separate alias. (Example is .uno:AddDirect in Writer's toolbar and menu).
2. Use this to fix the slide command names in the customization dialog. (Example is .uno:InsertPage). In this case the label of the original command is changed, no new identifier is created.
Comment 18 Maxim Monastirsky 2017-11-04 22:48:08 UTC
*** Bug 112826 has been marked as a duplicate of this bug. ***
Comment 19 Maxim Monastirsky 2017-12-19 12:20:01 UTC
*** Bug 56811 has been marked as a duplicate of this bug. ***
Comment 20 Yousuf Philips (jay) (retired) 2018-01-03 18:03:54 UTC
Maxim: Sorry that i didnt have time to try out your patch, but glancing at the code, the alternative labels on the same node seem like an interesting way to reference a particular label if one is needed, but didnt really see the point in it if we are defining specific labels as ContextLabel, TooltipLabel, etc.

The alias idea for the slide commands seems great as it would fix the customization dialog, but wouldnt solve the problem of a different icon needed for the alias command.

But now that 6.0 has been branched and nearly out the door, you can begin working on improving this issue for the next release with the stuff we've already agreed upon, so that the kinks can be smoothened out over the next 6 months, and translators will have sufficient time to fix any changes that are made.
Comment 21 Maxim Monastirsky 2018-05-09 22:00:32 UTC
*** Bug 117528 has been marked as a duplicate of this bug. ***
Comment 22 Regina Henschel 2018-07-13 12:38:05 UTC
*** Bug 118733 has been marked as a duplicate of this bug. ***
Comment 23 V Stuart Foote 2018-10-08 14:14:50 UTC
*** Bug 120392 has been marked as a duplicate of this bug. ***
Comment 24 V Stuart Foote 2018-10-31 23:02:10 UTC
*** Bug 121085 has been marked as a duplicate of this bug. ***