Accesskeys, variables and ampersands for Pootle localizers

[Francesco Lodolo [:flod]]

Hi,
If your locale works on Firefox (desktop, Android) in Pootle, please
keep reading this message. After checking several locales in the past
weeks, it's clear that there's a lot of confusion about this subject.

*What are accesskeys?*
Accesskeys, not to be confused with shortcuts (or commandkeys), are used
to access a UI element from the keyboard. Example: if File menu has an
accesskey F, and the Open menu has O, I can press ALT+F to access the
menu, and then O to open a file.

If the label is File, and the accesskey is F, it will be displayed as
"_F_ile" on Windows and Linux, with an underscored F. If the accesskey
was "O", so a character not available in the original label, it will be
displayed underlined between parenthesis: "File (_O_)".

*How accesskeys work in Pootle*
In the original localization file, label and accesskey are two separate
strings, for example:
<!ENTITY fileMenu.label "File">
<!ENTITY fileMenu.accesskey "F">

Pootle tries to help localizers by showing a single string, with the
accesskey preceded by a & (ampersand) character: &File. It then splits
the label during export in its original format (two strings).

*How to deal with accesskeys*
The first thing you need to decide is if you want to have localized
accesskeys: for example, if most users for your locale use a keyboard
with a different layout (English), it might make sense to keep the
English original accesskey instead of using a letter available in your
localization.

If you want to localize the accesskey, simply *put the & before the
letter you want to use*. For example, in ga-IE the string is stored as
&Comhad (label: Comhad, accesskey: C).
Export result in the repository:
<!ENTITY fileMenu.label "Comhad">
<!ENTITY fileMenu.accesskey "C">
In Firefox it will be displayed as "_C_omhad".

If you want to fallback to English, just *drop the &, it will fall back
to English automatically*. For example, ml: the string is stored in
Pootle as ഫയല്‍ (label: ഫയല്‍, accesskey: none, fallback to English).
Export result in the repository:
<!ENTITY fileMenu.label "ഫയല്‍">
<!ENTITY fileMenu.accesskey "F">
In Firefox it will be displayed as "ഫയല്‍ (_F_)".

Both are acceptable choices.

On the other hand, *all the following translations are incorrect*:

* Keep the string in English: &File. You need to localize the string
as if & was not there, so translate "File" and then determine what
to do with the accesskey.
* Keep somehow the accesskey in the label (I'll use ga-IE as an
example): "Comhad &F", "Comhad (F)", "Comhad F". For example, the
last case would be displayed as "Comhad _F_" in Firefox. This seems
to be the most common error.
* Keep the ampersand alone: "& Comhad", "Comhad &". This will result
as "Comhad &amp;" in the export, with the & escaped, and displayed
as "Comhad & (_F_)" in Firefox.

*Variables are not accesskeys*
And then there's another error. Consider for example this string:

<!ENTITY firstrun_tabqueue_subtext_on "You can always turn this off in
&settings; under &pref_category_general;.">

Both &settings; and &pref_category_general; are *variables*,
placeholders, and *must not be translated*. Unlike labels with
accesskeys (&File), they end with a semicolon, and that's how you can
recognize them. Another common example used across Firefox is
&brandShortName;

All these variable errors are reported on the l10n dashboard
(https://l10n.mozilla.org), so always keep an eye on it.

As usual, let me know if you have any questions.

Francesco

[Michael Wolf]

Francesco Lodolo [:flod] schrieb:

> Hi,
> If your locale works on Firefox (desktop, Android) in Pootle, please
> keep reading this message. After checking several locales in the past
> weeks, it's clear that there's a lot of confusion about this subject.
>

Hi Francesco,

I think this is not an issue for experienced Mozilla localizers. Wrong
decissions of localizers are, however, caused by some developers who
define an entity with .key suffix where it unclear if it is about an
accesskey or a commandkey. But, I had a look into Pootle and it seems
that text strings and related accesskey strings have been united to one
string now where the accesskey is marked by ampersand. I think they were
hown as different strings earlier and sometimes I didn't know what text
string an accesskey string referred to and vice versa.

I think that relatively new localizers have this issue. Anyhow, I think
it bodes well when this error type increasingly occurs. ;-) This
probably means that there are more localizers for more languages now.
And indeed, solely on Pootle, there are - if I counted correctly - 255
locales now. It is amazing though there are many locales in the very
beginning of translation, of course.

You can check your accesskey by Transvision:

https://transvision.mozfr.org/accesskeys/

and your variables:

https://transvision.mozfr.org/variables/

I used "de" as example locale because there are no errors for hsb and
dsb. :-)

Is there a commandkey check anywhere?

Regards,

Michael

[Francesco Lodolo [:flod]]

Il 12/07/16 18.47, Michael Wolf ha scritto:

> Francesco Lodolo [:flod] schrieb:
>> Hi,
>> If your locale works on Firefox (desktop, Android) in Pootle, please
>> keep reading this message. After checking several locales in the past
>> weeks, it's clear that there's a lot of confusion about this subject.
>>
>
> Hi Francesco,
>
> I think this is not an issue for experienced Mozilla localizers.

Actually, new localizers seem to grasp the concept quickly. On the other
hand we had issues with translated variables in the last cycle, even
with experience localizers, that completely broke the Android build.

I also confess that I don't find it super intuitive that dropping the &
would fall back to English, I had to ask someone else the first time I
saw it.

> Wrong decissions of localizers are, however, caused by some developers
> who define an entity with .key suffix where it unclear if it is about
> an accesskey or a commandkey.

Totally agree. With l20n and FTL this should improve, since accesskeys
are defined as part of the string (trait), e.g.

openCmd = Open File…
[html/accesskey] O
[html/shortcut] o

And developers can't make up their own string IDs.

> But, I had a look into Pootle and it seems that text strings and
> related accesskey strings have been united to one string now where the
> accesskey is marked by ampersand. I think they were hown as different
> strings earlier and sometimes I didn't know what text string an
> accesskey string referred to and vice versa.
>
> I think that relatively new localizers have this issue. Anyhow, I
> think it bodes well when this error type increasingly occurs. ;-) This
> probably means that there are more localizers for more languages now.
> And indeed, solely on Pootle, there are - if I counted correctly - 255
> locales now. It is amazing though there are many locales in the very
> beginning of translation, of course.
>
> You can check your accesskey by Transvision:
>
> https://transvision.mozfr.org/accesskeys/
>
> and your variables:
>
> https://transvision.mozfr.org/variables/
>
> I used "de" as example locale because there are no errors for hsb and
> dsb. :-)
>
> Is there a commandkey check anywhere?

There are no commandkeys checks in Transvision, also because the naming
consistency is even worse than accesskeys (key, commandkey, shortcut,
and probably others) :-\
Sadly the accesskey one is useful for locales translating accesskeys,
but not so much for locales using other scripts and falling back to
English for accesskeys.

Francesco


>
> Regards,
>
> Michael
>
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n

[Michael Wolf]

Francesco Lodolo [:flod] schrieb:

> Sadly the accesskey one is useful for locales translating accesskeys,
> but not so much for locales using other scripts and falling back to
> English for accesskeys.

And why it is not possible to use accesskey here? We are in the 21st
century and we are in the time of Unicode. There should be at least a
possibility to ignore the accesskey. Such things like "Dataja (F)" are
terrible. There should be a solution that the result is at least
"Dataja" without underscore and letter in brackets, maybe by an empty
string value or a space character: fileMenu.accesskey "". But in this
case different strings should be shown on Pootle again instead of one
string with ampersand. Or the source code may be changed that a missing
accesskey doesn't cause an accesskey error for certain locales.

Well, I still follow the rule to use ASCII-characters only though
Sorbian special characters work as well.

Michael

[Francesco Lodolo]

That has nothing to do with ASCII or Unicode. There needs to be an
accesskey to make the element accessible from keyboard, and that letter
needs to be available in the keyboard layout. For example, if the label is
ഫയല്‍ but there's are no keyboard with Malayalam layout (or it's extremely
uncommon), you need to keep the English one.

Francesco

[Michael Wolf]

Francesco Lodolo schrieb:

> That has nothing to do with ASCII or Unicode. There needs to be an
> accesskey to make the element accessible from keyboard, and that letter
> needs to be available in the keyboard layout. For example, if the label is
> ഫയല്‍ but there's are no keyboard with Malayalam layout (or it's extremely
> uncommon), you need to keep the English one.
>

Are there really keyboards without the necessary layout? A keyboard
layout must exist otherwise text in the corresponding language resp.
script cannot be written. I can use a keyboard which has key labels for
another language but I must have the necessary keyboard layout for the
language I want to translate into. I have a German keyboard and type
using a Czech keyboard layout. Meanwhile, however, there are Sorbian
keyboard layouts as well but I think there are no Sorbian keyboards.

BTW, do English accesskeys for another language or script really work? I
cannot use the English accesskey "H" for Sorbian "Pomoc" - there is no
"H" in the Sorbian word. I am sure the same is valid for Malayalam which
has even another script. So, why an accesskey should be assigned if it
doesn't work?


Michael

[Francesco Lodolo]

2016-07-12 22:09 GMT+02:00 Michael Wolf <mil...@sorbzilla.de>:

> BTW, do English accesskeys for another language or script really work? I
> cannot use the English accesskey "H" for Sorbian "Pomoc" - there is no "H"
> in the Sorbian word. I am sure the same is valid for Malayalam which has
> even another script. So, why an accesskey should be assigned if it doesn't
> work?
>
>

You can use H for Pomoc, it will be displayed as Pomoc (H), as ugly as it
sounds (you need to see the accesskey).
BTW, even English has one of those – Inspect element (Q) – because there
are no other non conflicting letters available.

Francesco

[Michael Wolf]

Francesco Lodolo schrieb:

> You can use H for Pomoc, it will be displayed as Pomoc (H), as ugly as it
> sounds (you need to see the accesskey).

Yes but AFAIK it won't work. And there is no possibility to hide the
wrong accesskey with the brackets?

> BTW, even English has one of those – Inspect element (Q) – because there
> are no other non conflicting letters available.

Yes, I know this entity and opened even a bug for German some years ago.
I localize it and have no error for dsb and hsb. And there is no chance
to change the text string to e.g. "Enquire/Inquire into element"? The
accesskey error will have gone away then.


Michael

[Michael Wolf]

Here is my bug which I opened 2012-03-31:

https://bugzilla.mozilla.org/show_bug.cgi?id=741074


Michael

[Axel Hecht]

So, for alphabet-based scripts, this is a question of keyboards. For
Chinese/Japanese/Korean, there's just no single glyph corresponding to a
rendered glyph, and the IMEs usually take several keystrokes to get to
the rendered glyph.

For scripts without strong content creation ecosystem, native keyboards
are a niche.

Now, language enthusiasts might be able to configure them, and use them
despite the characters on the keyboard not matching what they type. For
general end users, though, that's too tough.

Thus the accesskeys should show as they're likely to be printed on the
keyboard that people use.

Same for commandkeys, btw.

Axel

[அருண் குமார் (Arun Kumar)]

2016-07-13 5:47 GMT+08:00 Axel Hecht <l1...@mozilla.com>:

> On 12/07/16 22:09, Michael Wolf wrote:
>
>> Francesco Lodolo schrieb:
>>
>>> That has nothing to do with ASCII or Unicode. There needs to be an
>>> accesskey to make the element accessible from keyboard, and that letter
>>> needs to be available in the keyboard layout. For example, if the
>>> label is
>>> ഫയല്‍ but there's are no keyboard with Malayalam layout (or it's
>>> extremely
>>> uncommon), you need to keep the English one.
>>>
>>>
>> Are there really keyboards without the necessary layout? A keyboard
>> layout must exist otherwise text in the corresponding language resp.
>> script cannot be written. I can use a keyboard which has key labels for
>> another language but I must have the necessary keyboard layout for the
>> language I want to translate into. I have a German keyboard and type
>> using a Czech keyboard layout. Meanwhile, however, there are Sorbian
>> keyboard layouts as well but I think there are no Sorbian keyboards.
>>
>> BTW, do English accesskeys for another language or script really work? I
>> cannot use the English accesskey "H" for Sorbian "Pomoc" - there is no
>> "H" in the Sorbian word. I am sure the same is valid for Malayalam which
>> has even another script. So, why an accesskey should be assigned if it
>> doesn't work?
>>
>

You are right. We Tamilan's(ta) are also in the same with situation. Its a
contradiction with your keyboard layout/IME.

> Michael
>>
>>
> So, for alphabet-based scripts, this is a question of keyboards. For
> Chinese/Japanese/Korean, there's just no single glyph corresponding to a
> rendered glyph, and the IMEs usually take several keystrokes to get to the
> rendered glyph.
>
>

For Tamil(ta), we removed all the Access Keys(only & removed) just kept
translation. Because of that we are seeing 400+ critical Translation errors
in pootle :). Now its a re-work/review for us to correct those errors.

[Axel Hecht]

Sounds like Tamil is one of those languages for which we should disable
the accelerator test.

https://mozilla.locamotion.org/ta/translate/#filter=checks&checks=accelerators&unit=5861326

Arun, if checks are obviously false positives in general, please raise
the issue, the pootle team can disable individual tests for individual
languages, if they're in the way.

Axel

[Dwayne Bailey]

On 12 July 2016 at 15:42, Francesco Lodolo [:flod] <fl...@lodolo.net> wrote:

<snip>

Note that you can use the check within Pootle to identify accesskey
errors. This is really only relevant for languages that are including
accesskeys and aren't defaulting to en-US.

This is an accesskey error in Akan
https://mozilla.locamotion.org/ak/firefox/translate/browser/chrome/browser/baseMenuOverlay.dtd.po#filter=checks&checks=accelerators&unit=13233534

Note that accesskey errors are not shown as critical errors. So you will
need to use the expanded view of your language to see these. This is the
expanded view for Akan https://mozilla.locamotion.org/ak/?details

>
> *Variables are not accesskeys*
> And then there's another error. Consider for example this string:
>
> <!ENTITY firstrun_tabqueue_subtext_on "You can always turn this off in
> &settings; under &pref_category_general;.">
>
> Both &settings; and &pref_category_general; are *variables*, placeholders,
> and *must not be translated*. Unlike labels with accesskeys (&File), they
> end with a semicolon, and that's how you can recognize them. Another common
> example used across Firefox is &brandShortName;
>
> All these variable errors are reported on the l10n dashboard (
> https://l10n.mozilla.org), so always keep an eye on it.

These are picked up as critical errors by Pootle. So you shouldn't be able
to submit a unit with this type of error. It will also show up as a Red
critical error.

Here is an example one in Akan
https://mozilla.locamotion.org/ak/firefox/translate/browser/chrome/browser/baseMenuOverlay.dtd.po#unit=13233535



--
Dwayne

*Translate*
+27 12 460 1095 (work)

[Michael Wolf]

Dwayne Bailey schrieb:

> Note that you can use the check within Pootle to identify accesskey
> errors. This is really only relevant for languages that are including
> accesskeys and aren't defaulting to en-US.

Hi Dwayne,

does Pootle check for a correct accesskey or for the existence of an
accesskey only? In your example from Akan the accesskey wasn't defined.
But what's with an existing but wrong accesskey?

Michael

[Dwayne Bailey]

It will fail if you mark e.g. a space, end of line which can't be
diacritics. It will also mark certain Latin characters as a failure unless
we have defined a set of valid characters for your language. Thus some
languages would have ê on the keyboard and it would be a valid accesskey.
In most cases though it would not be valid.

So yes, we do more then just check that its present. We try make sure its
acceptable.

[Axel Hecht]

It's not checking for accesskey conflicts, though.

Mostly because that's *really* hard. I had an idea on how to tool
something, and found weird things in our dear friend XUL that just try
to confuse the world about what's where. The last least-bad idea was to
create runtime tests for each scenario, and run them on each locale. But
that's only least-bad in the sense that it requires a lot of engineering
work to write the tests, and a lot of compute power to run them. And
then there's still nobody looking at the outcome yet.

Axel

[Michael Wolf]

Axel Hecht schrieb:

> It's not checking for accesskey conflicts, though.
>
> Mostly because that's *really* hard. I had an idea on how to tool
> something, and found weird things in our dear friend XUL that just try
> to confuse the world about what's where. The last least-bad idea was to
> create runtime tests for each scenario, and run them on each locale. But
> that's only least-bad in the sense that it requires a lot of engineering
> work to write the tests, and a lot of compute power to run them. And
> then there's still nobody looking at the outcome yet.
>

I think a tool needs to check for 4 conditions:

1. Is accesskey check disabled? - Yes for languages that use another
script. Tool finishes checking.

2. Does an accesskey exist? - If not --> error message. Works already.

3. If existing, does the accesskey use an allowed character? If not -->
error message. AFAIK it already works.

4. Does the defined accesskey exist in the corresponding text string? If
not --> error message.


Michael

[Michael Wolf]

Michael Wolf schrieb:

> Axel Hecht schrieb:
>> It's not checking for accesskey conflicts, though.

Ah yes, this case I've forgotten.

Hm, It is really hard. A tool must know which accesskeys are in a common
context. The ideal case is that the context is the file they are in. But
may be some accesskeys are defined in other files.


Michael

[Francesco Lodolo [:flod]]

One more suggestion. It looks like Pootle doesn't let you search for
&amp; (unless that's due to lack of coffee on my side). But you can use
Transvision for that.

1) Go to Transvision and search for &amp;
2) The page will show 2 sets (tables) of results: en-US (source)
matching strings, xx-YY (target) matching strings. You need to scroll
down and focus on the latter.
3) If your string has a &amp; and the source doesn't, you most probably
have an error.

Francesco

> Hi,
> If your locale works on Firefox (desktop, Android) in Pootle, please
> keep reading this message. After checking several locales in the past
> weeks, it's clear that there's a lot of confusion about this subject.
>

> *Variables are not accesskeys*
> And then there's another error. Consider for example this string:
>
> <!ENTITY firstrun_tabqueue_subtext_on "You can always turn this off in
> &settings; under &pref_category_general;.">
>
> Both &settings; and &pref_category_general; are *variables*,
> placeholders, and *must not be translated*. Unlike labels with
> accesskeys (&File), they end with a semicolon, and that's how you can
> recognize them. Another common example used across Firefox is
> &brandShortName;
>
> All these variable errors are reported on the l10n dashboard