Hotkeys shmotkeys

l10n
#1

I'm officially throwing the towel on the hotkeys. Or are they access keys? Whatever... the scope is impossible to tell, some use ~ some use & and as of 4.0.1 we now also have underscore. Apart from messing with my TM, I also end up with the unpalatable choice of either totally ignoring multiple uses of the same access key in the UI or spending an extraordinary amount of time fixing them. And as LO expands, it will only get worse.

We sort of had this debate before and I believe the upshot was that if you leave them out, the system will automatically assign them. I think that's what I will do from now assuming the failing access key checks in Pootle won't stop the release in my locale. If I file a bug, is it possible to remove all of them automatically? Or does the system not care if I stop assigning them manually part way through?

Michael

#2

Dana 28.5.2013. 13:21, Michael Bauer je napisao:

I'm officially throwing the towel on the hotkeys. Or are they access keys? Whatever... the scope is impossible to tell, some use ~ some use & and as of 4.0.1 we now also have underscore. Apart from messing with my TM, I also end up with the unpalatable choice of either totally ignoring multiple uses of the same access key in the UI or spending an extraordinary amount of time fixing them. And as LO expands, it will only get worse.

We sort of had this debate before and I believe the upshot was that if you leave them out, the system will automatically assign them. I think that's what I will do from now assuming the failing access key checks in Pootle won't stop the release in my locale. If I file a bug, is it possible to remove all of them automatically? Or does the system not care if I stop assigning them manually part way through?

Michael

I feel your pain. :slight_smile:
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.

Also, I'm having problems with knowing which of one word strings are free to translate and which are variables (place holders or whatever it's called, which I shouldn't translate). Not really sure why you are even offering those strings in Pootle translation if they shouldn't be translated.

Best regards,
Mihovil

#3

Hi Michael, Mihovil, all,

Dana 28.5.2013. 13:21, Michael Bauer je napisao:

I'm officially throwing the towel on the hotkeys. Or are they access
keys? Whatever... the scope is impossible to tell, some use ~ some use
& and as of 4.0.1 we now also have underscore. Apart from messing with
my TM, I also end up with the unpalatable choice of either totally
ignoring multiple uses of the same access key in the UI or spending an
extraordinary amount of time fixing them. And as LO expands, it will
only get worse.

We sort of had this debate before and I believe the upshot was that if
you leave them out, the system will automatically assign them. I think
that's what I will do from now assuming the failing access key checks
in Pootle won't stop the release in my locale. If I file a bug, is it
possible to remove all of them automatically? Or does the system not
care if I stop assigning them manually part way through?

Michael

I feel your pain. :slight_smile:
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.

I agree with you both that it's really difficult to have those keys
fixed. I've tried to get them right (I mean all different and no
duplicates) in the UI but I'm not sure what the algorithm is doing
beside my choices. Andras, do you have an idea on what we can do to
improve that ? I don't use Pootle to search the strings, but I'm feeling
the same pain when I grep my files, having now to take care of the ~ and _.

Also, I'm having problems with knowing which of one word strings are
free to translate and which are variables (place holders or whatever
it's called, which I shouldn't translate). Not really sure why you are
even offering those strings in Pootle translation if they shouldn't be
translated.

Because everything is in Pootle (and I like it :slight_smile: So may be we have to
document what the variables are on the wiki? This is up to us to
document our process and the material we need to make our localization.
I won't do it now because I miss time, but may be we can work on it
together when the 4.1 localization round is over?

Kind regards
Sophie

#4

And as LO expands, it will only get worse.

This is a problem, but LO expands slowly, so you can always sort out
these issues by one of the bugfix releases.

We sort of had this debate before and I believe the upshot was that if you
leave them out, the system will automatically assign them.

This is (or was) the case with old style widgets, I'm not sure about .ui.

Regards,
Andras

#5

I feel your pain. :slight_smile:
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

Also, I'm having problems with knowing which of one word strings are free to
translate and which are variables (place holders or whatever it's called,
which I shouldn't translate). Not really sure why you are even offering
those strings in Pootle translation if they shouldn't be translated.

Please give us examples. If a string is not for translation, I'll take
it out from the pool. It may help, if you check other localizations in
Pootle, and see, if the string in question is translated there.

Regards,
Andras

#6

Andras,

I think you misunderstood me. As a one-man team running over two dozen l10n projects for my locale, I simply don't have to time to randomly browse around the LO UI and then spend 30 minutes trying to figure out which incidence of "Edit" has the wrong access key, then wait for a build, check, and most likely undo and try another one.

Even if there was someone else on the team, it would be a questionable use of valuable translator time (small language *are* that desperate for time) plus, and that applies to a lot of languages I think, there are corners of the UI people rarely go to and I suspect even some of the bigger languages will haver bits of the UI where the access keys are messed up.

The sidebar has added at least a couple hundred of these. Now multiply each by 30 minutes (a guesstimate).

If the system differentiates the automatic access keying depending on where you are, then I'm stuffed. I have no idea which bits are widget and which are UI. I'm not a magician :slight_smile: If that's the case I'll just have to shrug, guess at the access keys and live with the mess.

On the whole, I think the whole access key thing needs a more coherent, automated approach. Or at least a codekey attached to each UI string in the test builds you you can *easily* identify the string that needs fixing.

Michael

#7

This is not something I do, but it may be an option if you like to have
perfect hotkeys.

Open a dialog and make a screenshot. Next run the keyid build, open the
same dialog, make another screenshot. Now annotate hotkeys in the first
screenshot taking care there is no conflict. Finally, search for strings
by keyid and add hotkeys as annotated.

You should be able to fix all strings in a dialog in under 30 minutes.

Best,
Goran

#8

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?

Friedel

#9

I might try that for some of the more prominent one - does Pootle allow searching via keyid?

Thanks for suggesting.

Michael

28/05/2013 13:55, sgrìobh Goran Rakic:

#10

2013-05-29 13:48, F Wolff rašė:

I feel your pain. :slight_smile:
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?

Rimas

#11

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.

Andras

#12

Yes it does, indexing of new files is still running (slowly).

Andras

#13

2013.05.29 18:09, Andras Timar rašė:

2013-05-29 13:48, F Wolff rašė:

I feel your pain. :slight_smile:
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.

IMO, listing all three when only one is the actual marker would result
in more confusion than benefit. For example, the & character seems quite
common in English to me. Falsely marking it as an accelerator marker
would result in bad indexes, I guess...

Rimas

#14

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

#15

OK, I have another revolutionary idea. Let's forget about &, there are
only a few. What about changing the ~ to _ in VCL? Of course po files
will be changed accordingly.

Cheers,
Andras

#16

Hi, all,

I see this as a recurring problem.
Developers do some change in several files in many strings, because that
seems appropriate and cleaner, and they do it:
a) without thinking what that change will mean for translators
b) knowing it will cause a lot of manual work for translators, but they
think that is collateral damage.

I know this from OOo and it happens with LO as well.

Adding "_" as an accelerator should have made programmers think about it:
changing same strings with accelerators from tilde to underscore made a lot
of manual work for translators of more than 100 languages - one changed UI
string in this manner meant more than 100 people had to manually change
that string ... And there were hundred(s) of such strings, more to come.

But that is all history now.

Since underscore is more likely to appear in "normal" strings than tilde
(or at least I would suppose so) - why not make it the other way than what
Andras suggests - so that with a script in all specially marked po files
tildes would be changed to underscore? Or introduce some kind of
meta-accelerator (%ACC)?

There is one thing I miss from the OOo-Munich days - I am not sure how that
was called - but every time a new feature or bigger change was introduced,
there was a report/plan what it will mean, what needs to be done, how the
UI will look like etc. I think that the developers should adopt that same
or similar system and get some approval by a bigger developers/translators
community, and there should be a section in such a document weighing in the
work/changes by this new feature/development for the localizers. Hopefully
then more than 100 localizers would have a few more hours to test their
translations and not just to copy/paste/change a character.

And I know I will slapped for my thoughts again, as usually, so I humbly
rest my case.

Lp, m.

#17

+1 from me

Michael

29/05/2013 22:00, sgrìobh Martin Srebotnjak:

#18

Hi,

Adding "_" as an accelerator should have made programmers think about it:
changing same strings with accelerators from tilde to underscore made a lot
of manual work for translators of more than 100 languages - one changed UI
string in this manner meant more than 100 people had to manually change that
string ... And there were hundred(s) of such strings, more to come.

I created a compendium from old translations. Then I replaced all ~ to
_ and merged the two compendiums. With this merged compendium most of
the old translations were re-used. When not, they often come as
suggestion from amaGama server (in Pootle). So I tried to mitigate the
collateral damage. I do hope, however, that large scale code
reorganization will come to an end some day.

Since underscore is more likely to appear in "normal" strings than tilde (or
at least I would suppose so) - why not make it the other way than what
Andras suggests - so that with a script in all specially marked po files
tildes would be changed to underscore? Or introduce some kind of
meta-accelerator (%ACC)?

Unfortunately _ comes from GTK+/Glade. We edit dialogs in Glade now.

Best regards,
Andras

#19

+1 from me

+1 from me too.
Sophie

#20

... which allows people to tweak their dialogs directly from the build
or released product.

In Glade, open the dialog file with .ui as extension and look inside the
widgets (especially GtkLabel, GtkRadio and GtkCheckBox).

The dialogs are in <install>/share/config/soffice.cfg/<...> and can be
modified on-the-fly (just re-open the dialog to see the results)

Tweak it and port back to pootle.

*it is* an exercise of great patience, but the issue itself is not trivial.

(a shortcut will be one day to have a mydialog.ui <--> mydialog.po binding).

- --
Olivier Hallot
Founder, Board of Directors Member - The Document Foundation
The Document Foundation, Zimmerstr. 69, 10117 Berlin, Germany
Fundação responsável civilmente, de acordo com o direito civil
Detalhes Legais: http://www.documentfoundation.org/imprint
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812