772366 - Multiple access keys used in preferences dialog for ms locale

Status: RESOLVED WONTFIX

(Mozilla Localizations :: ms / Malay, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: screenshots

Our Mozmill l10n tests have been shown that there are some access keys which are used multiple times in the same scope. The full list of those keys you can find here:

http://mozmill-ci.blargon7.com/#/l10n/report/99ab6c49d005522227c5717d8a067e97

Details:

 accessKey: "l" found in: value: laman utama: , button#chooseFolder
accessKey: "s" found in: button#useCurrent, radio#alwaysAsk
accessKey: "h" found in: button[label=Bantuan], checkbox#popupPolicy
accessKey: "i" found in: checkbox#loadImages, label[accesskey=i][control=defaultFontSize]
accessKey: "m" found in: label[control=monospace][accesskey=M], value: Mengkod Aksara Default:
accessKey: "l" found in: value: Latar:, value: Pautan Belum Dilawat:
accessKey: "c" found in: checkbox#acceptThirdParty, button#showCookiesButton
accessKey: "c" found in: checkbox#acceptThirdParty, button#showCookiesButton
accessKey: "p" found in: button#addonExceptions, button#showPasswords
accessKey: "c" found in: label[control=filter][accesskey=C], button[label=Tutup]
accessKey: "s" found in: checkbox#searchStartTyping, checkbox#submitCrashesBox
accessKey: "p" found in: button#clearCacheButton, button#offlineNotifyExceptions
accessKey: "u" found in: radio#systemPref, radio[label=URL konfigurasi proksi automatik:]
accessKey: "h" found in: button[label=Bantuan], button#showUpdateHistory
Modal dialog has been found and processed

Comment 1

[Muhammad Syafiq Mazli]

Hi Henrik,

I understand some issue on access key, even myself can't identify which letter to use for access key. So i use same access key as locale EN. Basically in ms locale, if we translate some access keys is same. I will check on this issue and let you know on this bug.

@syafiqmazli

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Axel can probably give some advices here. CC'img him.

Comment 3

[Axel Hecht [:Pike]]

Finding good accesskeys is tricky, but there should be enough choice for ms.

I don't think that sticking to en-US accesskeys is the best option here. The guidelines for picking good ones from https://developer.mozilla.org/en/XUL_Accesskey_FAQ_and_Policies should apply to ms, too.

Comment 4

[Muhammad Syafiq Mazli]

Axel,

When i try to put letter which from ms translated word. Most letter are same but it will issue if the access key is common letter? What do you think?

Comment 5

[Axel Hecht [:Pike]]

Let's try browser/chrome/browser/preferences/content.dtd, where we have 'h' and 'i' as conflicts as an example.

<!ENTITY  blockPopups.label           "Block pop-up windows">
<!ENTITY  blockPopups.accesskey       "H">

You probably want to actually translate that string, but for now, "B" would be a good accesskey.

<!ENTITY  loadImages.label            "Automatik muat imej">
<!ENTITY  loadImages.accesskey        "I">
<!ENTITY  defaultSize.label           "Saiz:">
<!ENTITY  defaultSize.accesskey       "i">

Now, 'i' shouldn't be an accesskey per guidelines, but loadImages could use 'A' and defaultSize 'S'.

Does that help?

Comment 6

[Muhammad Syafiq Mazli]

Yes, it helpful. 

Thanks Axel!

Comment 7

[Muhammad Syafiq Mazli]

Hello Henrik,

I think this has been fix or you may re-run mozmill test if any issue need fix. Thanks!

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

We run this tests automatically once you land changes in the repository. So the last run of the l10n tests on Nov 22nd still had a lot of access key conflicts. See:

http://mozmill-daily.blargon7.com/#/l10n/report/456bebe92845279408c15c03e8407166

accessKey: "l" found in: value: Laman Utama:, button#chooseFolder
accessKey: "s" found in: button#useCurrent, radio#alwaysAsk
accessKey: "a" found in: label[accesskey=a][control=defaultFont], button#advancedFonts
accessKey: "s" found in: checkbox#popupPolicy, label[accesskey=S][control=defaultFontSize]
accessKey: "l" found in: value: Latar:, value: Pautan Belum Dilawat:
accessKey: "c" found in: label#acceptThirdPartyLabel, button#showCookiesButton
accessKey: "t" found in: radio#dntdotrack, checkbox#acceptCookies
accessKey: "c" found in: label#acceptThirdPartyLabel, button#showCookiesButton
accessKey: "t" found in: radio#dntdotrack, checkbox#acceptCookies
accessKey: "p" found in: button#addonExceptions, button#showPasswords
accessKey: "p" found in: button#clearCacheButton, button#offlineNotifyExceptions
accessKey: "u" found in: radio#systemPref, radio[label=URL konfigurasi proksi automatik:]
accessKey: "a" found in: radio#autoDesktop, button#showUpdateHistory

Comment 9

[Muhammad Syafiq Mazli]

Henrik,

Where i can find path following above error on firefox folder?

Comment 10

[Francesco Lodolo [:flod]]

The bug subject says that is about Preferences, so you should look into browser/preferences
ID of the string is after # (e.g. chooseFolder for the first one).

Comment 11

[Muhammad Syafiq Mazli]

Flod,

Thanks for your answer. I have another question. If said i already fix the string. Where i could checking access key is fixed after done? Any tools to make sure all access key is fixed?

Comment 12

[arky [:arky]]

Syafig 

Does this help?

http://transvision.mozfr.org/accesskeys/?locale=ms&channel=aurora

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Those are not the results from mozmill about duplicated access keys, right? 

To run our Mozmill tests just do:
1. Download the latest mozmill-env for your platform from https://mozqa.com/mozmill-env/
2. Extract and execute the run command within the top folder
3. Call 'testrun_l10n -workspace data %path_to_firefox%

The path to Firefox should be the build which contains the fixed access keys. If failures occur you will find screenshots under 'data/screenshots'.

Comment 14

[Francesco Lodolo [:flod]]

Those are Transvision warning when the character is not available in the original string: it doesn't show conflicts, but it's still an error unless you run out of characters. So, for example, "Cuba Semula" will be displayed as "Cuba Semula (T)", since the T is not available in the label.

Comment 15

[Muhammad Syafiq Mazli]

Attachment: Bug_772366_Fixing_multiple_access_key.diff

I just create patch all fix string problem as above.

Comment 16

[Francesco Lodolo [:flod]]

No point in asking a review to Henrik ;-)

First of all: how do you work? Do you commit files directly to hg or use Pootle (or similar tools)? In the second case you need to fix the problem in the tool, in the first case just commit the patch to your repository.

Second: you need to test the product and see where strings appear. Example

 <!ENTITY session.label                "Benarkan Sesi">
-<!ENTITY session.accesskey            "S">
+<!ENTITY session.accesskey            "B">
 <!ENTITY allow.label                  "Benarkan">
 <!ENTITY allow.accesskey              "B">

You changed S to B to avoid a conflict, but I guess the string is displayed together with "Benarkan", which has "B", so you just moved the conflict, not resolved.

Comment 17

[Muhammad Syafiq Mazli]

(In reply to Francesco Lodolo [:flod] from comment #16)
> No point in asking a review to Henrik ;-)
> 
> First of all: how do you work? Do you commit files directly to hg or use
> Pootle (or similar tools)? In the second case you need to fix the problem in
> the tool, in the first case just commit the patch to your repository.
> 
I doing work from hg setup in my Linux PC, edit/fix using vim and commit files directly to hg server.

> Second: you need to test the product and see where strings appear. Example
> 
>  <!ENTITY session.label                "Benarkan Sesi">
> -<!ENTITY session.accesskey            "S">
> +<!ENTITY session.accesskey            "B">
>  <!ENTITY allow.label                  "Benarkan">
>  <!ENTITY allow.accesskey              "B">
> 
> You changed S to B to avoid a conflict, but I guess the string is displayed
> together with "Benarkan", which has "B", so you just moved the conflict, not
> resolved.

I understand there some access key has fixed with change different letter. Seem there few word are same access key and hard to identify which letter to use. I know the access key should be use with first letter of beginning word as i doing my fix above.

Comment 18

[Francesco Lodolo [:flod]]

As explained, the first letter of a word is the best choice but obviously not mandatory, since it's not always available.

In general you should avoid narrow letters like "i" or "l" (rendered in sans-serif font), but that's not always possible either.

Comment 19

[arky [:arky]]

Hope this help: 

http://docs.translatehouse.org/projects/localization-guide/en/latest/guide/translation/accelerators.html#selecting

Comment 20

[Muhammad Syafiq Mazli]

@arky,

i not sure this correct way but i did finish fix on "accelerators" in pootle, http://mozilla.locamotion.org/ms/firefox/ you may check under "falling check".

Comment 21

[arky [:arky]]

@Syafiq Looks good. Thank you for doing this. 

Perhaps more problems will emerge when dwayne pushes the changes into Mozilla repo. Keeping this bug open until then.

Comment 22

[Axel Hecht [:Pike]]

Looking at http://mozmill-daily.blargon7.com/#/l10n/report/f892d42cad846376757d785401a906be, we still have conflicts.

 accessKey: "l" found in: value: Laman Utama:, button#chooseFolder
accessKey: "s" found in: button#useCurrent, radio#alwaysAsk
accessKey: "a" found in: label[accesskey=a][control=defaultFont], button#advancedFonts
accessKey: "s" found in: checkbox#popupPolicy, label[accesskey=S][control=defaultFontSize]
accessKey: "l" found in: value: Latar:, value: Pautan Belum Dilawat:
accessKey: "a" found in: label#historyModeLabel, label#acceptThirdPartyLabel
accessKey: "t" found in: radio#dntdotrack, checkbox#acceptCookies
accessKey: "a" found in: label#historyModeLabel, label#acceptThirdPartyLabel
accessKey: "t" found in: radio#dntdotrack, checkbox#acceptCookies
accessKey: "p" found in: button#addonExceptions, button#showPasswords
accessKey: "p" found in: button#clearCacheButton, button#offlineNotifyExceptions
accessKey: "u" found in: radio#systemPref, radio[label=URL konfigurasi proksi automatik:]
accessKey: "a" found in: radio#autoDesktop, button#showUpdateHistory

Comment 23

[Muhammad Syafiq Mazli]

@Pike i check on report above from mozmill-daily, are you use previous build - Firefox 28.0a2 (28.0a2, ms, 20140126004002)? or the latest one?

Comment 24

[Muhammad Syafiq Mazli]

FYI, i just testing mozmill l10n testing from my machine - windows 8 x64 with using latest build - Firefox 28.0a2 (28.0a2, ms, 20140131004003)

Report : http://mozmill-daily.blargon7.com/#/l10n/report/0906e2c8b6f223d6588987bcd1525e29

Please find on attachment for the screenshot & access key fix on Pootle. I waiting for Dwayne commit my latest work.

Comment 25

[Muhammad Syafiq Mazli]

Attachment: mozmill-windowsx64.jpg

Comment 26

[Muhammad Syafiq Mazli]

Attachment: screenshots 20140201.rar

Comment 27

[Muhammad Syafiq Mazli]

Attachment: Access Key 20140201.rar

Comment 28

[Henrik Skupin [:whimboo][⌚️UTC+1]]

So the latest version which we have tested was from yesterday and it contains 2 duplicated accesskeys:

http://mozmill-daily.blargon7.com/#/l10n/report/0906e2c8b6f223d6588987bcd17111f5

    accessKey: "l" found in: value: Latar:, value: Pautan Belum Dilawat:
    accessKey: "a" found in: label#historyModeLabel, checkbox#acceptCookies

Once those have been fixed we are fine.

Comment 29

[Muhammad Syafiq Mazli]

@henrik,

Please find new attachment for new fix. Just need push from pootle.

Comment 30

[Muhammad Syafiq Mazli]

Attachment: Access Key Fix 20140102-latest.rar

Comment 31

[Francesco Lodolo [:flod]]

Attaching screenshots of the fixes on Pootle is not useful, you just need to wait for the next push and test results ;-)

Comment 32

[Jeff Beatty [:gueroJeff]]

Can take a look and see if these fixes have been implemented?

Comment 33

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The latest results still show problems:
http://mozmill-daily.blargon7.com/#/l10n/report/0906e2c8b6f223d6588987bcd18acc23

Comment 34

[Muhammad Syafiq Mazli]

@henrik

I been testing out Firefox 29.0a2 (29.0a2, ms, 20140211004037) and found issue on 't'

Here my result : http://mozmill-crowd.blargon7.com/#/l10n/report/e35f22a68fec3f6d144713f9ab87e5a6

I will fixing up this soon and will update here.

Comment 37

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Looks like there are still two issues left as reported by bug 995203:

http://mozmill-crowd.blargon7.com/#/l10n/report/7ab760e27012969ae02e3b9e41e79409

Details:
accessKey: "k" found in: label#historyModeLabel, checkbox#acceptCookies show more
accessKey: "p" found in: checkbox#privateBrowsingAutoStart, button#cookieExceptions show more

Comment 38

[Muhammad Syafiq Mazli]

@henrik 

Just adding fix with c36adbe132ef

Comment 39

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to Muhammad Syafiq Mazli from comment #38)
> Just adding fix with c36adbe132ef

Where has this been landed? I cannot see a check-in at http://hg.mozilla.org/releases/l10n/mozilla-aurora/ms/, which we use for our testing. Can you please check if the changeset has been  pushed correctly?

Comment 40

[Muhammad Syafiq Mazli]

This changeset is on http://hg.mozilla.org/releases/l10n/mozilla-beta/ms/ as what we currently fixing others string as well.

Comment 41

[Francesco Lodolo [:flod]]

Marking as a wontfix. With the reorganized preferences, duplicated accesskeys are inevitable.