Re: <ahelp></ahelp> - Extended tips in Helpcontent & VCL + Glade

Hey Olivier,

On Wed, Aug 26, 2015 at 6:10 PM, Olivier Hallot <
olivier.hallot@libreoffice.org> wrote:

> 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.

It is not that easy. The current agreement between developers and
translators (who object any change in the workflow that causes more work)
is that we will extract the extended tooltips when we move the help to
wikihelp. And also only if we are able to retain all the existing
translations.

If this limitation would not be around I would have moved the extended
tooltips a long time ago into the normal repository.


> > > 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.

As I mentioned it is not a technical limitation blocking us at the moment
but the additional work (a few ten thounsand additional words of
translation) for translators. So unless you manage to convince them that
this is also in their interest it looks to me like this is not a quick
change that we can easily implement.


> > > * 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.


My script already would preserve all existing translations, so this is the
lesser of the two problems. The big one is that it duplicates a huge number
of strings (double the work) and increases the workload to get a fully
translated UI (we might have a solution for the second part).


> > > * 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.

At least my patches to move the tooltips extracts them to simple java like
property files. You can easily process them from there. That format at
least easily allows us to keep all the existing translations and handle all
the corner cases that are currently not covered by ui files. Additionally
the agreement with the translators asks us to make sure that the extended
tooltips can be extracted into an own pootle project to keep them
independent of the normal UI translations.


I hope my points explain why all this is less of an technical problem and
more a social one where before you can do any work you need to convince the
people affected by your change to come to a common understanding. At least
your current proposal goes against the current agreement betwee Kendy,
Sophi, me and the translators. (It already took a long time to get that
far).

Regards,
Markus


> > 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
> _______________________________________________
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice