Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On Wed, May 29, 2013 at 4:09 PM, Andras Timar <timar74@gmail.com> wrote:
On Wed, May 29, 2013 at 2:42 PM, Rimas Kudelis <rq@akl.lt> wrote:
2013-05-29 13:48, F Wolff rašė:

On Tue, May 28, 2013 at 1:17 PM, Andras Timar <timar74@gmail.com> wrote:

On Tue, May 28, 2013 at 1:28 PM, Mihovil Stanic
<mihovil.stanic@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+unsubscribe@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.