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

[Olivier Hallot]

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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
> 

-- 
Olivier Hallot
Comunidade LibreOffice
http://ask.libreoffice.org/pt-br