[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 bugzilla-daemon at bugs.documentfoundation.org
Mon Oct 30 09:00:32 UTC 2017


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

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

-- 
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/20171030/3eb00779/attachment.html>


More information about the Libreoffice-bugs mailing list