[Libreoffice-bugs] [Bug 108458] Label changes for Toolbar use degrade function listing in the Customize dialog--have duplicate entries on the list

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=108458

Yousuf Philips (jay) <philipz85 at hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|113510                      |

--- Comment #11 from Yousuf Philips (jay) <philipz85 at hotmail.com> ---
(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.


Referenced Bugs:

https://bugs.documentfoundation.org/show_bug.cgi?id=113510
[Bug 113510] [META] Bugs that cause CPU to run at 100%
-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20171029/f8b9847a/attachment-0001.html>