Hi Caolán, all.
Thank you for answering. I have some comments though.
Em 25/08/2015 09:00, Caolán McNamara escreveu:
On Sun, 2015-08-23 at 08:37 -0300, Olivier Hallot wrote:
Hi all
Just playing with a new linux master build today and I found that the
<property name="tooltip_markup" translatable="yes"> bla bla
bla</property>
of a widget in a UI dialog, edited by Glade, indeed acts like an
extended tip (<ahelp></ahelp>) for help content for the widget,
provided
the "extented tips" in Tools - Options - General - Extended tips" is
unmarked.
In other words, it is possible to have extended tips moved into these
dialogs.
What is probably a better fit is to leave the tooltip .ui field for the
short "normal" tooltips. And use the "accessibility description" for
the big long extended tips that are current in help.
Can this be submitted to ESC appreciation/blessing and a task in BZ be
open (may be an EasyHack or such). We should formalize this.
The benefits I see are
* Have the text of the e.t. in the UI and facilitate translation job
(context)
agreed, and it also has the advantage that the "extended tips" are
always available even if help is not installed.
Another advantage is that the current ahelp tags have a "this refers to
the last defined helpid" i.e. "." markup and this is horribly broken in
a huge number of cases :-(
Indeed it will give us the opportunity to fix once for all.
* a quite large work of moving e.t. from helpcontent to UI.
Another disadvantage might be increased size of the default download
and install.
True but the benefits overcomes it, IMHO.
* An impact in the translations of the UI (not sure it can be
automated).
This, "impact in the translations" is the problem really from my side.
It's the dev<->translator bridging. Ideally on the dev-side we'd be
able to e.g. make all the changes ourselves and update the .po files
with the moved strings and push them to translation website and there
would then be no additional translator work.
Moving english strings from <ahelp></ahelp> to the UI + po files looks
feasible. The issue is to move the translated equivalent. If possible
too and seamless, that looks fantastic.
Probably the translation memory will help translators but from our
recent experiences with the UI and dialogs, my advice is to do it in
spaced strides, not a bulk change.
* when unmarking Extended tips in the Options, we loose e.t. of
toolbars and other non-Glade UI objects.
* by filling the tooltip_markup property, e.t. are always enabled in
a dialog.
I think these problems can be solved by moving extended tips into the
a11y description and considering them both the same thing.
yep.
Markus has an extended-tip extraction tool as ./bin/extract-tooltip.py
FWIW
C.
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
--
Olivier Hallot
Comunidade LibreOffice
http://ask.libreoffice.org/pt-br
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.