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

-- 
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/20171027/c27ca902/attachment-0001.html>