Re: ahelp/ahelp - Extended tips in Helpcontent VCL + Glade
Hi all, Thanks a lot for your work and explanations, I jump to the end: Le 26/08/2015 18:35, Markus Mohrhard a écrit : Hey Olivier, [...] 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). I think we could go further now if we plan the changes largely in advance and if it would be possible to make the changes in 3 or 4 steps instead of a big one. Knowing it in advance will allow translators to organize their work between the different open source projects they contribute to. Olivier, we will discuss the help topic during the l10n workshop at LibOCon, would it be possible that you explain the process to the group during Tuesday afternoon? Then I'll discuss with the team to push the project further. Cheers Sophie -- Sophie Gautier sophie.gaut...@documentfoundation.org GSM: +33683901545 IRC: sophi Co-founder - Release coordinator The Document Foundation ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ahelp/ahelp - Extended tips in Helpcontent VCL + Glade
Hey Olivier, On Wed, Aug 26, 2015 at 6:10 PM, Olivier Hallot olivier.hal...@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
Re: ahelp/ahelp - Extended tips in Helpcontent VCL + Glade
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 ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: ahelp/ahelp - Extended tips in Helpcontent VCL + Glade
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. 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 :-( * a quite large work of moving e.t. from helpcontent to UI. Another disadvantage might be increased size of the default download and install. * 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. * 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. 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
ahelp/ahelp - Extended tips in Helpcontent VCL + Glade
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. The benefits I see are * Have the text of the e.t. in the UI and facilitate translation job (context) * fix the e.t. of the wikihelp. The issues I see are * a quite large work of moving e.t. from helpcontent to UI. * An impact in the translations of the UI (not sure it can be automated). * 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. The last two may require an Option of e.t for toolbars and another Option or dialogs. bin/lint-ui.py can be adapted to check if the widget have a e.t. Regards -- Olivier Hallot Comunidade LibreOffice http://ask.libreoffice.org/pt-br ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
