On Wed, May 29, 2013 at 4:09 PM, Andras Timar <tima...@gmail.com> wrote: > On Wed, May 29, 2013 at 2:42 PM, Rimas Kudelis <r...@akl.lt> wrote: >> 2013-05-29 13:48, F Wolff rašė: >> >>> On Tue, May 28, 2013 at 1:17 PM, Andras Timar <tima...@gmail.com> wrote: >>>> >>>> On Tue, May 28, 2013 at 1:28 PM, Mihovil Stanic >>>> <mihovil.sta...@gmail.com> wrote: >>>>> >>>>> >>>>> I feel your pain. :) >>>>> I'm coming from Mozilla L10n in which you have access keys as a separate >>>>> strings to LO in which there is 3 different ways to mark access keys. >>>>> I'm >>>>> not against marking access keys inside strings, but PLEASE decide how >>>>> you >>>>> want to do it. >>>> >>>> >>>> It is not possible, different technologies use different hotkey markers. >>>> ~ is for old VCL >>>> _ is for new .ui >>>> & is for native Windows widgets >>> >>> >>> I've seen mentions of the move to GtkBuilder, and it seems to hold >>> lots of advantages. Apart from the burden for translators as Michael >>> mentions, I just realised that this change will impact the quality >>> checks in Pootle and similar tools that still assume that '~' is the >>> only marker. From a quick look, 13 of the quality checks in the >>> Translate Toolkit remove the marker as part of the test. Although this >>> might not make a difference in all affected strings, this is still >>> unfortunate, since it might introduce lots of false complaints from >>> the quality checks. >>> >>> Is there a way to distinguish the accelerator from the #: comments, or >>> filename, or something like that? >> >> >> >> Assuming that a marker is consistent within each file, I think it would make >> most sense to use the X-Accelerator-Marker header for that. The question is >> whether or not that assumption is correct... Andras? > > It is correct. I was thinking about even more simplification. Can > Pootle accept comma separated values in X-Accelerator-Marker field? > Like: "X-Accelerator-Marker: ~,_,&\n" Friedel? If not, we need to > tweak l10ntools.
Pootle doesn't read the X-Accelerator-Marker, as far as I know. It uses the configuration for the project, which is (should be) set to "openoffice" which has '~' (only) defined as the marker. The code has support for more than one marker per configuration, so we could simply add the others in the code. I can't think of a situation where this has been tested. The two possible issues I can see with this: - might be a bit slower - might get some incorrect identification of accelerators. '&' is slightly tricky here, because of XML entities, although most of the tests remove those first, before removing the accelerator marker. If someone has a bit of time, here is a good test to see the impact: - Get a full set of files for a reasonably translated language (or multiple) - run pofilter from the commandline with --openoffice and --language and keep the output - change accelmarkers under openofficeconfig in translate/search/checks.py (in the Translate Toolkit) to have all three markers - run pofilter again - compare the output of the two runs This should give us an idea of how much this changes improve/change things. X-Accelerator-Marker is used by Virtaal, but only to recognise the project style (openoffice vs. mozilla vs. gnome, etc.) as far as I could see. So changing this header in the PO files won't do much good, as I see it. With all of that said, even if we look for temporary solutions, I want to underscore what Michael mentioned as one of the points: this makes things harder, and will reduce the use of translation memories. It is also causing some churn in the strings, I guess? (Unnecessarily fuzzying strings when the things are converted to GtkBuilder) If things can be unified and processed during the build phase as required, that would be ideal (although I realise that would involve some work). Friedel -- To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/l10n/ All messages sent to this list will be publicly archived and cannot be deleted
