952065 - Multiple access keys used in preferences dialog for xh locale

Status: RESOLVED FIXED

(Mozilla Localizations :: xh / Xhosa, defect)

Description

[Mihaela Velimiroviciu (:mihaelav)]

Attachment: 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

Comment 3

[Axel Hecht [:Pike]]

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.

Comment 4

[ian.henderson]

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

Comment 5

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

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

Comment 6

[Jeff Beatty [:gueroJeff]]

(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.

Comment 7

[ian.henderson]

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.

Comment 8

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

(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.

Comment 9

[ian.henderson]

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.

Comment 10

[ian.henderson]

Thanks for all the help. The conflicts should be resolved now.

Comment 11

[Dwayne Bailey]

Pushed these to Aurora in 37:6f7e13a7f89f I'll mark this as FIXED

Comment 12

[Dwayne Bailey]

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

Comment 13

[Dwayne Bailey]

The accesskey changes where backported to Mozilla Beta in 38:05d1de6c8ff5.  They include the potential error highlighted in comment 12.

Comment 14

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

(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

Comment 15

[Dwayne Bailey]

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

Comment 16

[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…"

Comment 17

[Dwayne Bailey]

Final issues fixed in 38:3435eede6dca

Comment 18

[Dwayne Bailey]

(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.

Comment 19

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

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.

Comment 20

[ian.henderson]

(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.

Comment 21

[ian.henderson]

(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?

Comment 22

[Jeff Beatty [:gueroJeff]]

(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.

Comment 23

[Axel Hecht [:Pike]]

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.

Comment 24

[ian.henderson]

(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"

Comment 25

[Jeff Beatty [:gueroJeff]]

(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?

Comment 27

[Dwayne Bailey]

Fixed in changeset  39:f211098292dc

Hopefully we can really close this now :)

Comment 28

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

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.

Comment 29

[Dwayne Bailey]

(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.

Comment 30

[Dwayne Bailey]

Foward ported fixes form Aurora see comment 17 and comment 27 to Beta in commit 38:05d1de6c8ff5

Comment 31

[Dwayne Bailey]

(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

Comment 32

[ian.henderson]

(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.

Comment 33

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

(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.

Comment 34

[Axel Hecht [:Pike]]

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.

Comment 35

[ian.henderson]

(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.

Comment 36

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

Attachment: 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.

Comment 37

[ian.henderson]

(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.

Comment 38

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

Thank you Ian. Dwayne, who can do a push of that change to mozilla-aurora and beta?

Comment 39

[Dwayne Bailey]

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

Comment 40

[ian.henderson]

So this issue has been resolved?

Comment 41

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

Doesn't look like. The latest tests still complain about the 'o' access key:
http://mozmill-daily.blargon7.com/#/l10n/report/f892d42cad846376757d78540107d63b

Comment 42

[ian.henderson]

Hi Henrik,
Can I trouble you for a screenshot? I would like to get this issue out of the way.

Comment 43

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

Attachment: screenshot.png (o key)

Sure. That's what I see

Comment 44

[ian.henderson]

Thanks.

I have fixed the keys in Pootle.

Comment 45

[Jeff Beatty [:gueroJeff]]

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?

Comment 46

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

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.