<div dir="ltr">Hey Olivier,<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 26, 2015 at 6:10 PM, Olivier Hallot <span dir="ltr"><<a href="mailto:olivier.hallot@libreoffice.org" target="_blank">olivier.hallot@libreoffice.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Caolán, all.<br>
<br>
Thank you for answering. I have some comments though.<br>
<span class=""><br>
Em 25/08/2015 09:00, Caolán McNamara escreveu:<br>
> On Sun, 2015-08-23 at 08:37 -0300, Olivier Hallot wrote:<br>
>> Hi all<br>
>><br>
>> Just playing with a new linux master build today and I found that the<br>
>><br>
>> <property name="tooltip_markup" translatable="yes"> bla bla<br>
>> bla</property><br>
>><br>
>> of a widget in a UI dialog, edited by Glade, indeed acts like an<br>
>> extended tip (<ahelp></ahelp>) for help content for the widget,<br>
>> provided<br>
>> the "extented tips" in Tools - Options - General - Extended tips" is<br>
>> unmarked.<br>
>><br>
>> In other words, it is possible to have extended tips moved into these<br>
>> dialogs.<br>
><br>
><br>
> What is probably a better fit is to leave the tooltip .ui field for the<br>
> short "normal" tooltips. And use the "accessibility description" for<br>
> the big long extended tips that are current in help.<br>
<br>
</span>Can this be submitted to ESC appreciation/blessing and a task in BZ be<br>
open (may be an EasyHack or such). We should formalize this.<br></blockquote><div><br></div><div>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.<br><br></div><div>If this limitation would not be around I would have moved the extended tooltips a long time ago into the normal repository.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
>><br>
>> The benefits I see are<br>
>><br>
>> * Have the text of the e.t. in the UI and facilitate translation job<br>
>> (context)<br>
><br>
> agreed, and it also has the advantage that the "extended tips" are<br>
> always available even if help is not installed.<br>
><br>
> Another advantage is that the current ahelp tags have a "this refers to<br>
> the last defined helpid" i.e. "." markup and this is horribly broken in<br>
> a huge number of cases :-(<br>
<br>
</span>Indeed it will give us the opportunity to fix once for all.<br>
<span class=""><br>
><br>
>> * a quite large work of moving e.t. from helpcontent to UI.<br>
><br>
> Another disadvantage might be increased size of the default download<br>
> and install.<br>
<br>
</span>True but the benefits overcomes it, IMHO.<br></blockquote><div><br></div><div>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.<br>  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
>> * An impact in the translations of the UI (not sure it can be<br>
>> automated).<br>
><br>
> This, "impact in the translations" is the problem really from my side.<br>
> It's the dev<->translator bridging. Ideally on the dev-side we'd be<br>
> able to e.g. make all the changes ourselves and update the .po files<br>
> with the moved strings and push them to translation website and there<br>
> would then be no additional translator work.<br>
<br>
</span>Moving english strings from <ahelp></ahelp> to the UI + po files looks<br>
feasible. The issue is to move the translated equivalent. If possible<br>
too and seamless, that looks fantastic.<br>
<br>
Probably the translation memory will help translators but from our<br>
recent experiences with the UI and dialogs, my advice is to do it in<br>
spaced strides, not a bulk change.<br></blockquote><div><br><br></div><div>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).<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
><br>
>> * when unmarking Extended tips in the Options, we loose e.t. of<br>
>> toolbars and other non-Glade UI objects.<br>
>><br>
>> * by filling the tooltip_markup property, e.t. are always enabled in<br>
>> a dialog.<br>
><br>
> I think these problems can be solved by moving extended tips into the<br>
> a11y description and considering them both the same thing.<br>
<br>
</span>yep.<br></blockquote><div><br></div><div>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.<br><br><br></div><div>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).<br><br></div><div>Regards,<br></div><div>Markus<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="im HOEnZb"><br>
><br>
><br>
> Markus has an extended-tip extraction tool as ./bin/extract-tooltip.py<br>
> FWIW<br>
><br>
> C.<br>
> _______________________________________________<br>
> LibreOffice mailing list<br>
> <a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/libreoffice" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a><br>
><br>
<br>
</span><span class="im HOEnZb">--<br>
Olivier Hallot<br>
Comunidade LibreOffice<br>
<a href="http://ask.libreoffice.org/pt-br" rel="noreferrer" target="_blank">http://ask.libreoffice.org/pt-br</a><br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
LibreOffice mailing list<br>
<a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/libreoffice" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a><br>
</div></div></blockquote></div><br></div></div>