Closed Bug 772366 Opened 7 years ago Closed 2 years ago

Multiple access keys used in preferences dialog for ms locale

Categories

(Mozilla Localizations :: ms / Malay, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: whimboo, Assigned: syafiq)

References

()

Details

(Whiteboard: [mozmill-l10n])

Attachments

(6 files)

Attached file 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
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
Axel can probably give some advices here. CC'img him.
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.
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?
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?
Yes, it helpful. 

Thanks Axel!
Hello Henrik,

I think this has been fix or you may re-run mozmill test if any issue need fix. Thanks!
Flags: needinfo?(hskupin)
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
Flags: needinfo?(hskupin)
Henrik,

Where i can find path following above error on firefox folder?
Flags: needinfo?(hskupin)
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).
Flags: needinfo?(hskupin)
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?
Flags: needinfo?(francesco.lodolo)
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'.
Flags: needinfo?(francesco.lodolo)
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.
I just create patch all fix string problem as above.
Attachment #8347607 - Flags: review?(hskupin)
Attachment #8347607 - Flags: review?(hskupin)
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.
(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.
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.
@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".
Flags: needinfo?(hitmanarky)
@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.
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
@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?
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.
Flags: needinfo?(hitmanarky)
Attached image mozmill-windowsx64.jpg
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.
@henrik,

Please find new attachment for new fix. Just need push from pootle.
Attaching screenshots of the fixes on Pootle is not useful, you just need to wait for the next push and test results ;-)
Can take a look and see if these fixes have been implemented?
@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.
Duplicate of this bug: 974842
Blocks: 960439
Duplicate of this bug: 995203
Blocks: 974458
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
Assignee: nobody → creativeneuron8
Status: NEW → ASSIGNED
@henrik 

Just adding fix with c36adbe132ef
(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?
This changeset is on http://hg.mozilla.org/releases/l10n/mozilla-beta/ms/ as what we currently fixing others string as well.
Marking as a wontfix. With the reorganized preferences, duplicated accesskeys are inevitable.
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.