[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

--- Comment #10 from Maxim Monastirsky <momonasmon at gmail.com> ---
(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.

-- 
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/20171028/d1198c14/attachment-0001.html>