Closed Bug 952065 Opened 11 years ago Closed 10 years ago

Multiple access keys used in preferences dialog for xh locale

Categories

(Mozilla Localizations :: xh / Xhosa, defect)

Product:
Mozilla Localizations
Component:
xh / Xhosa
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mihaelav, Assigned: dwayne)

References

Details

Attachments

(3 files)

screenshots
509.62 KB, application/zip
Details
screenshot.png
30.18 KB, image/png
Details
screenshot.png (o key)
86.36 KB, image/png
Details
Attached file screenshots — 
Mozmill l10n tests have been caught that there are some access keys which are used multiple times in the same scope.

---XP, Vista---
 accessKey: "b" found in: button#useBookmark, button#restoreDefaultHomePage
accessKey: "n" found in: button[label=Nceda], radio#saveTo
accessKey: "n" found in: button[label=Nceda], radio#dntnotrack
accessKey: "n" found in: button[label=Nceda], radio#dntnotrack
accessKey: "i" found in: label#historyModeLabel, button#cookieExceptions
accessKey: "n" found in: button[label=Nceda], radio#dntnotrack
accessKey: "i" found in: label#historyModeLabel, button#cookieExceptions
accessKey: "n" found in: button[label=Nceda], radio#dntnotrack
accessKey: "n" found in: button[label=Nceda], checkbox#warnAddonInstall
accessKey: "n" found in: button[label=Nceda], checkbox#offlineNotify
accessKey: "n" found in: button[label=Nceda], checkbox#enableSearchUpdate 

--- 7, 8, 8.1 ---
 accessKey: "b" found in: button#useBookmark, button#restoreDefaultHomePage
accessKey: "n" found in: button[label=Nceda], radio#saveTo
accessKey: "k" found in: checkbox#linkTargeting, checkbox#showTabsInTaskbar
accessKey: "n" found in: button[label=Nceda], radio#dntnotrack
accessKey: "n" found in: button[label=Nceda], radio#dntnotrack
accessKey: "i" found in: label#historyModeLabel, button#cookieExceptions
accessKey: "n" found in: button[label=Nceda], radio#dntnotrack
accessKey: "i" found in: label#historyModeLabel, button#cookieExceptions
accessKey: "n" found in: button[label=Nceda], radio#dntnotrack
accessKey: "n" found in: button[label=Nceda], checkbox#warnAddonInstall
accessKey: "n" found in: button[label=Nceda], checkbox#offlineNotify
accessKey: "n" found in: button[label=Nceda], checkbox#enableSearchUpdate 

Reports: 
* XP: http://mozmill-staging.blargon7.com/#/l10n/report/b646dc9797659302414b7b8a9d069775
* 7: http://mozmill-staging.blargon7.com/#/l10n/report/b646dc9797659302414b7b8a9d06b940
OS: Windows 7 → All
Hardware: x86 → All
Summary: Multiple access keys used in preferences dialog for xh locale on Windows → Multiple access keys used in preferences dialog for xh locale
Ian, it seems that you're not watching the Xhosa bugzilla component yet? You might want to head over to https://bugzilla.mozilla.org/userprefs.cgi?tab=component_watch&product=Mozilla%20Localizations and fix that.
Blocks: fx-l10n-xh
I am watching  	Mozilla Localizations 	  xh / Xhosa.

We fixed all the screenshots indicated by Henrik, but after fixing I wanted the check that our fixes were OK. The problem has arisen because I have been unable to run the mozmill environment. Neither Jeff nor Dwayne have been able to help me with this.

Any help on this matter would be appreciated
If you don't want to run the tests locally you can rely on our CI system which runs the tests whenever you land a patch in your repository. Once the updated builds are ready, our system will run it and push results to the dashboard:

http://mozmill-daily.blargon7.com/#/l10n

Otherwise for local testruns simply do:

1. Download the latest environment for your platform from https://mozqa.com/mozmill-env/
2. Extract and execute the run script (under linux and os x with `source`)
3. Run 'testrun_l10n --workspace=./data %path_to_firefox%
4. Check screenshots under ./data/screenshots
(In reply to ian.henderson from comment #4)
> I am watching  	Mozilla Localizations 	  xh / Xhosa.
> 
> We fixed all the screenshots indicated by Henrik, but after fixing I wanted
> the check that our fixes were OK. The problem has arisen because I have been
> unable to run the mozmill environment. Neither Jeff nor Dwayne have been
> able to help me with this.
> 
> Any help on this matter would be appreciated

Sorry Ian, I'm working on getting mozmill running today. I reached out to Dwayne to get a feel for comparing error reporting in mozmill with the access key automated checks in Pootle, but haven't heard from him. If you've corrected the issues indicated in the screenshots from Henrik, I believe you'll have to wait until Dwayne commits the changes into your Aurora repo before anyone can see if all of the issues are resolved.

Additionally, Dwayne will need to port the access key changes up to Beta. Fortunately we're still in the beginning of the cycle right now and there are an extra two weeks due to the holiday break.
I have resolved as many as I can and have uploaded the amended files. There were a couple I could not find, for example
accessKey: "n" found in: button[label=Nceda], radio#dntnotrack
Some guidance to track this down would be appreciated.
(In reply to ian.henderson from comment #7)
> accessKey: "n" found in: button[label=Nceda], radio#dntnotrack
> Some guidance to track this down would be appreciated.

Not sure what Nceda means but this button is in the same scope as the radio button for do not track. One of the screenshots attached to this bug should show it.
Nceda is the Help button, which I think may be a generic button overlaying individual dialogs.
I completely missed that Michaela had attached screenshots. Sorry about that. Will get cracking on this tomorrow.
Thanks for all the help. The conflicts should be resolved now.
Pushed these to Aurora in 37:6f7e13a7f89f I'll mark this as FIXED
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Hi Ian,

In porting this to beta I noticed that one change change two 'b' characters to two 'u' characters.  They're close together in the file, so I assume that this shouldn't be.  Changing to conflicts for another set of conflicts doesn't seem like a solution here.

See browser/chrome/browser/preferences/main.dtd::
chooseBookmark.accesskey and restoreDefault.accesskey
The accesskey changes where backported to Mozilla Beta in 38:05d1de6c8ff5.  They include the potential error highlighted in comment 12.
(In reply to Dwayne Bailey from comment #12)
> In porting this to beta I noticed that one change change two 'b' characters
> to two 'u' characters.  They're close together in the file, so I assume that
> this shouldn't be.  Changing to conflicts for another set of conflicts
> doesn't seem like a solution here.
> 
> See browser/chrome/browser/preferences/main.dtd::
> chooseBookmark.accesskey and restoreDefault.accesskey

As long as this isn't fixed we shouldn't close the bug. Given that no follow-up fix has been landed for this conflict, I'm going to reopen this bug. For our Mozmill report see:

http://mozmill-daily.blargon7.com/#/l10n/report/361b4f553c3df363a1b22c126404357e
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ian could you have a look at the final remaining error that Henrik highlighted in comment 14

Also note that this is the one I mention in comment 12
Flags: needinfo?(ian.henderson)
Please change:

#: chooseBookmark.label chooseBookmark.accesskey
msgid "Use &Bookmark…"
msgstr "Sebenzisa ibh&ukhmakhi…"

to 

#: chooseBookmark.label chooseBookmark.accesskey
msgid "Use &Bookmark…"
msgstr "Sebenzisa i&bhukhmakhi…"
Flags: needinfo?(ian.henderson)
Final issues fixed in 38:3435eede6dca
Status: REOPENED → RESOLVED
Closed: 11 years ago → 10 years ago
Resolution: --- → FIXED
(In reply to ian.henderson from comment #16)
> Please change:
> 
> #: chooseBookmark.label chooseBookmark.accesskey
> msgid "Use &Bookmark…"
> msgstr "Sebenzisa ibh&ukhmakhi…"
> 
> to 
> 
> #: chooseBookmark.label chooseBookmark.accesskey
> msgid "Use &Bookmark…"
> msgstr "Sebenzisa i&bhukhmakhi…"

Hi Ian, in future you can search in Pootle for any of those locations e.g. 'chooseBookmark.label' or 'chooseBookmark.accesskey'.  Make sure when you search that you have 'Locations' selected from the search dropdown.  That would have allowed you to make the changes on Pootle.
Sorry for reopening again but exclusively on Linux it looks like that there is still a conflict:
http://mozmill-daily.blargon7.com/#/l10n/report/40742e0746fd767e6d2fd58659b00391

accessKey: "s" found in: checkbox#privateBrowsingAutoStart, checkbox#alwaysClear 

This failure does not appear for OS X and Windows.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Dwayne Bailey from comment #18)
> (In reply to ian.henderson from comment #16)
> > Please change:
> > 
> > #: chooseBookmark.label chooseBookmark.accesskey
> > msgid "Use &Bookmark…"
> > msgstr "Sebenzisa ibh&ukhmakhi…"
> > 
> > to 
> > 
> > #: chooseBookmark.label chooseBookmark.accesskey
> > msgid "Use &Bookmark…"
> > msgstr "Sebenzisa i&bhukhmakhi…"
> 
> Hi Ian, in future you can search in Pootle for any of those locations e.g.
> 'chooseBookmark.label' or 'chooseBookmark.accesskey'.  Make sure when you
> search that you have 'Locations' selected from the search dropdown.  That
> would have allowed you to make the changes on Pootle.

Thanks for this tip. I see you have already made the change.
(In reply to Henrik Skupin (:whimboo) from comment #19)
> Sorry for reopening again but exclusively on Linux it looks like that there
> is still a conflict:
> http://mozmill-daily.blargon7.com/#/l10n/report/
> 40742e0746fd767e6d2fd58659b00391
> 
> accessKey: "s" found in: checkbox#privateBrowsingAutoStart,
> checkbox#alwaysClear 
> 
> This failure does not appear for OS X and Windows.

I need some help here. I have searched in pootle as described by Dwayne and also on my local disk. To no avail. Can you let me know which file(s) this conflict appears in?
(In reply to ian.henderson from comment #21)
> (In reply to Henrik Skupin (:whimboo) from comment #19)
> > Sorry for reopening again but exclusively on Linux it looks like that there
> > is still a conflict:
> > http://mozmill-daily.blargon7.com/#/l10n/report/
> > 40742e0746fd767e6d2fd58659b00391
> > 
> > accessKey: "s" found in: checkbox#privateBrowsingAutoStart,
> > checkbox#alwaysClear 
> > 
> > This failure does not appear for OS X and Windows.
> 
> I need some help here. I have searched in pootle as described by Dwayne and
> also on my local disk. To no avail. Can you let me know which file(s) this
> conflict appears in?

Honestly, I can't find this either. The closest that I can find is privateBrowsingPermanent2, whose access key is S.
http://mxr.mozilla.org/l10n-mozilla-aurora/source/xh/browser/chrome/browser/preferences/privacy.dtd?mark=76,85#76 has those, privateBrowsingPermanent2.accesskey and clearOnClose.accesskey.

And yes, they're hard to find, for reference, I did:

Search for the ID in mxr, http://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/in-content/privacy.xul#143, find the entity reference, search for that on http://mxr.mozilla.org/l10n-mozilla-aurora/search?string=privateBrowsingPermanent2&find=xh/, and then search in both files for the conflicting ID and entity reference. Ugh, but there's no better way, as the l10n data is thrown away when parsing the DOM.
(In reply to Axel Hecht [:Pike] from comment #23)
> http://mxr.mozilla.org/l10n-mozilla-aurora/source/xh/browser/chrome/browser/
> preferences/privacy.dtd?mark=76,85#76 has those,
> privateBrowsingPermanent2.accesskey and clearOnClose.accesskey.
> 
> And yes, they're hard to find, for reference, I did:
> 
> Search for the ID in mxr,
> http://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/
> in-content/privacy.xul#143, find the entity reference, search for that on
> http://mxr.mozilla.org/l10n-mozilla-aurora/
> search?string=privateBrowsingPermanent2&find=xh/, and then search in both
> files for the conflicting ID and entity reference. Ugh, but there's no
> better way, as the l10n data is thrown away when parsing the DOM.

Thanks for investigating this. I do not seem to be able to edit the entry in Pootle though.

I don't like to have letters with descenders as access keys, but it makes most sense to change

#: privateBrowsingPermanent2.label privateBrowsingPermanent2.accesskey
msgid "Always use &private browsing mode"
msgstr "&Soloko usebenzisa imo yokubhrawuza yangasese"

to

#: privateBrowsingPermanent2.label privateBrowsingPermanent2.accesskey
msgid "Always use &private browsing mode"
msgstr "Soloko usebenzisa imo yokubhrawuza &yangasese"
(In reply to ian.henderson from comment #24)
> (In reply to Axel Hecht [:Pike] from comment #23)
> > http://mxr.mozilla.org/l10n-mozilla-aurora/source/xh/browser/chrome/browser/
> > preferences/privacy.dtd?mark=76,85#76 has those,
> > privateBrowsingPermanent2.accesskey and clearOnClose.accesskey.
> > 
> > And yes, they're hard to find, for reference, I did:
> > 
> > Search for the ID in mxr,
> > http://mxr.mozilla.org/mozilla-central/source/browser/components/preferences/
> > in-content/privacy.xul#143, find the entity reference, search for that on
> > http://mxr.mozilla.org/l10n-mozilla-aurora/
> > search?string=privateBrowsingPermanent2&find=xh/, and then search in both
> > files for the conflicting ID and entity reference. Ugh, but there's no
> > better way, as the l10n data is thrown away when parsing the DOM.
> 
> Thanks for investigating this. I do not seem to be able to edit the entry in
> Pootle though.
> 
> I don't like to have letters with descenders as access keys, but it makes
> most sense to change
> 
> #: privateBrowsingPermanent2.label privateBrowsingPermanent2.accesskey
> msgid "Always use &private browsing mode"
> msgstr "&Soloko usebenzisa imo yokubhrawuza yangasese"
> 
> to
> 
> #: privateBrowsingPermanent2.label privateBrowsingPermanent2.accesskey
> msgid "Always use &private browsing mode"
> msgstr "Soloko usebenzisa imo yokubhrawuza &yangasese"

I went ahead and made the change in Pootle. I had the same problem you did, but I realized I wasn't logged in. This change will have to be ported to Beta. Do you have that, Dwayne?
Fixed in changeset  39:f211098292dc

Hopefully we can really close this now :)
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
I would suggest we don't play ping pong here and leave the  bug open until the results are green. So we fail again now:

accessKey: "y" found in: checkbox#privateBrowsingAutoStart, checkbox#acceptCookies 

I would suggest that you run the mozmill tests locally on a patched Firefox version to verify the changes. See comment 5 how to do that.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to Henrik Skupin (:whimboo) from comment #28)
> I would suggest we don't play ping pong here and leave the  bug open until
> the results are green. So we fail again now:

No more ping pong.

> accessKey: "y" found in: checkbox#privateBrowsingAutoStart,
> checkbox#acceptCookies 
> 
> I would suggest that you run the mozmill tests locally on a patched Firefox
> version to verify the changes. See comment 5 how to do that.


That's not going to happen too soon for teams with less skills unless I can figure out how to automatically unwind the mozmill output as suggested by Axel in comment 23.
Foward ported fixes form Aurora see comment 17 and comment 27 to Beta in commit 38:05d1de6c8ff5
(In reply to Dwayne Bailey from comment #30)
> Foward ported fixes form Aurora see comment 17 and comment 27 to Beta in
> commit 38:05d1de6c8ff5

Sorry 40:0d4f191c7a6c
(In reply to Dwayne Bailey from comment #29)
> (In reply to Henrik Skupin (:whimboo) from comment #28)
> > I would suggest we don't play ping pong here and leave the  bug open until
> > the results are green. So we fail again now:
> 
> No more ping pong.
> 
> > accessKey: "y" found in: checkbox#privateBrowsingAutoStart,
> > checkbox#acceptCookies 
> > 
> > I would suggest that you run the mozmill tests locally on a patched Firefox
> > version to verify the changes. See comment 5 how to do that.
> 
> 
> That's not going to happen too soon for teams with less skills unless I can
> figure out how to automatically unwind the mozmill output as suggested by
> Axel in comment 23.

I managed to implement the change in Pootle thanks to the comment 25.
(In reply to Dwayne Bailey from comment #29)
> That's not going to happen too soon for teams with less skills unless I can
> figure out how to automatically unwind the mozmill output as suggested by
> Axel in comment 23.

Sure but I think it will be enough to get those tests run. If help is needed we can work it out on the appropriate bug. Otherwise we have to wait for our official test results, and might have breakage caused by landing changes.
I've posted my findings on running mozmill tests locally to https://groups.google.com/forum/#!topic/mozmill-dev/-cl9RpYKk6U.

Info on latest conflict:

privateBrowsingPermanent2 vs acceptCookies in privacy.dtd, the latter being uppercase.
(In reply to Axel Hecht [:Pike] from comment #34)
> I've posted my findings on running mozmill tests locally to
> https://groups.google.com/forum/#!topic/mozmill-dev/-cl9RpYKk6U.
> 
> Info on latest conflict:
> 
> privateBrowsingPermanent2 vs acceptCookies in privacy.dtd, the latter being
> uppercase.

I am afraid I don't understand the issue.

#: privateBrowsingPermanent2.label privateBrowsingPermanent2.accesskey
msgid "Always use &private browsing mode"
msgstr "S&oloko usebenzisa imo yokubhrawuza yangasese"

There are no other visible &o instances in privacy.dtd

#: acceptCookies.label acceptCookies.accesskey
msgid "&Accept cookies from sites"
msgstr "&Yamkela iikhukhi kwisayithi"

There are no other visible &y instances in privacy.dtd

The comment mentions that &Y is on the upper case letter, but judging from the English model &A, upper case access keys are OK. Please advise.
Attached image screenshot.png — 
(In reply to Axel Hecht [:Pike] from comment #34)
> I've posted my findings on running mozmill tests locally to
> https://groups.google.com/forum/#!topic/mozmill-dev/-cl9RpYKk6U.

Our automation mailing list would have been a better place but we surely can discuss it on the Mozmill list. Or I might forward it correctly.

(In reply to ian.henderson from comment #35)
> I am afraid I don't understand the issue.
> 
> #: privateBrowsingPermanent2.label privateBrowsingPermanent2.accesskey
> msgid "Always use &private browsing mode"
> msgstr "S&oloko usebenzisa imo yokubhrawuza yangasese"
> 
> There are no other visible &o instances in privacy.dtd
> 
> #: acceptCookies.label acceptCookies.accesskey
> msgid "&Accept cookies from sites"
> msgstr "&Yamkela iikhukhi kwisayithi"
> 
> There are no other visible &y instances in privacy.dtd
> 
> The comment mentions that &Y is on the upper case letter, but judging from
> the English model &A, upper case access keys are OK. Please advise.

Attached you can find the screenshot. It should help you to understand the problem.
(In reply to Henrik Skupin (:whimboo) from comment #36)
> Created attachment 8359646 [details]
> screenshot.png
> 
> (In reply to Axel Hecht [:Pike] from comment #34)
> > I've posted my findings on running mozmill tests locally to
> > https://groups.google.com/forum/#!topic/mozmill-dev/-cl9RpYKk6U.
> 
> Our automation mailing list would have been a better place but we surely can
> discuss it on the Mozmill list. Or I might forward it correctly.
> 
> (In reply to ian.henderson from comment #35)
> > I am afraid I don't understand the issue.
> > 
> > #: privateBrowsingPermanent2.label privateBrowsingPermanent2.accesskey
> > msgid "Always use &private browsing mode"
> > msgstr "S&oloko usebenzisa imo yokubhrawuza yangasese"
> > 
> > There are no other visible &o instances in privacy.dtd
> > 
> > #: acceptCookies.label acceptCookies.accesskey
> > msgid "&Accept cookies from sites"
> > msgstr "&Yamkela iikhukhi kwisayithi"
> > 
> > There are no other visible &y instances in privacy.dtd
> > 
> > The comment mentions that &Y is on the upper case letter, but judging from
> > the English model &A, upper case access keys are OK. Please advise.
> 
> Attached you can find the screenshot. It should help you to understand the
> problem.

Thanks for the screenshot. It looks like the build environment has not been updated with the changes made in Pootle, re comment 32.
Thank you Ian. Dwayne, who can do a push of that change to mozilla-aurora and beta?
Flags: needinfo?(dwayne)
Hi Gents,

Sorry got confused with the change and double checked today to realise I'd missed the last one.

Changes landed on Aurora in 41:5c76c356337d forward ported to Beta in 45:bf3c642ec08f
Flags: needinfo?(dwayne)
So this issue has been resolved?
Doesn't look like. The latest tests still complain about the 'o' access key:
http://mozmill-daily.blargon7.com/#/l10n/report/f892d42cad846376757d78540107d63b
Hi Henrik,
Can I trouble you for a screenshot? I would like to get this issue out of the way.
Attached image screenshot.png (o key) — 
Sure. That's what I see
Thanks.

I have fixed the keys in Pootle.
I assume this is clear to close, since we shipped Xhosa. If there are other access key issues, I assume that they will be filed in a new bug. Henrik, can you please confirm and reopen, if necessary?
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Flags: needinfo?(hskupin)
Resolution: --- → FIXED
I think it's fine now. I will make sure to reopen if we have a regression in that part again. Please keep in mind that we might still need a couple of days to adapt our mozmill tests for the new in-content preferences, which will land on Aurora maybe next week.
Flags: needinfo?(hskupin)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: