Localized accesskeys for Match diacritics checkbox conflicts with address bar shortcut (alt+d)
Categories
(Mozilla Localizations :: ko / Korean, defect)
Tracking
(Not tracked)
People
(Reporter: ikadro, Assigned: hyeonseok)
References
()
Details
Attachments
(1 file)
5.29 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0
Steps to reproduce:
In the Korean language pack, the shortcut for "Match Diacritics" in the search bar is Alt+D. The shortcut must be changed to Alt+I.
- Install the Korean version of Firefox.
- Open the search bar. (Ctrl+F)
- Enter Alt+D for the purpose of moving to the address bar.
Actual results:
The Match Diacritics function is enabled.
Expected results:
Focus moves to the address bar.
Comment 1•4 years ago
|
||
This is not a problem only for Korean. Since it's an accesskey, every locale localized it differently (depending on the label)
https://transvision.mozfr.org/string/?entity=toolkit/toolkit/main-window/findbar.ftl:findbar-match-diacritics.accesskey&repo=gecko_strings
That seems like a larger problem, and not one that should be fixed by locales individually.
Comment 2•4 years ago
|
||
The priority flag is not set for this bug.
:mikedeboer, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 6•4 years ago
|
||
(In reply to Francesco Lodolo [:flod] from comment #1)
This is not a problem only for Korean. Since it's an accesskey, every locale localized it differently (depending on the label)
https://transvision.mozfr.org/string/?entity=toolkit/toolkit/main-window/findbar.ftl:findbar-match-diacritics.accesskey&repo=gecko_stringsThat seems like a larger problem, and not one that should be fixed by locales individually.
I'm not sure what you mean here. How would we address this if not individually in locales?
Comment 7•4 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #6)
(In reply to Francesco Lodolo [:flod] from comment #1)
This is not a problem only for Korean. Since it's an accesskey, every locale localized it differently (depending on the label)
https://transvision.mozfr.org/string/?entity=toolkit/toolkit/main-window/findbar.ftl:findbar-match-diacritics.accesskey&repo=gecko_stringsThat seems like a larger problem, and not one that should be fixed by locales individually.
I'm not sure what you mean here. How would we address this if not individually in locales?
I have no idea what is technically possible, but a couple of examples:
- "Isolate" the find bar, i.e. pressing alt+(SOMETHING) would not trigger commands in the main menu.
- Drop the accesskeys, and replace them with actual keyboard shortcuts if people want to access them quickly via keyboard.
As I said, if you expose them as a normal accesskeys, people will localize them, and risk conflicts with the main menubar, or shortcuts that nobody is aware of (ALT+D for the address bar). There are 4 accesskeys in the find bar, the risk of conflict is not insignificant.
This is so confusing that it landed with the wrong accesskey even for English, and was later fixed (bug 1603636).
I could go through locales one by one, and find a different accesskey that D
, but that doesn't really scale for ~100 languages. More important, it doesn't exclude conflicts for the other 3 accesskeys, that are localized as well.
Comment 8•4 years ago
|
||
(In reply to Francesco Lodolo [:flod] from comment #7)
I have no idea what is technically possible, but a couple of examples:
- "Isolate" the find bar, i.e. pressing alt+(SOMETHING) would not trigger commands in the main menu.
That doesn't seem desirable since e.g. going to the address bar from the find bar is a legitimate use case.
- Drop the accesskeys, and replace them with actual keyboard shortcuts if people want to access them quickly via keyboard.
They keyboard shortcut space is just as crowded as the accesskey space, if not more. We generally have very little room for new shortucts in the main window.
As I said, if you expose them as a normal accesskeys, people will localize them, and risk conflicts with the main menubar, or shortcuts that nobody is aware of (ALT+D for the address bar). There are 4 accesskeys in the find bar, the risk of conflict is not insignificant.
This is generally a concern with access keys in all kinds of contexts and we rely on locales to deal with this. I don't think we expect that they test every access key when adding it, so I'm not blaming anyone, but when users report problems it seems reasonable to me that there needs to be a fix on the locale's side.
Comment 9•4 years ago
|
||
(In reply to Dão Gottwald [::dao] from comment #8)
This is generally a concern with access keys in all kinds of contexts and we rely on locales to deal with this. I don't think we expect that they test every access key when adding it, so I'm not blaming anyone, but when users report problems it seems reasonable to me that there needs to be a fix on the locale's side.
I agree, in general. But this is not "general", if nothing else given the number of errors reported for different locales.
The root cause is that English landed with the wrong accesskey and was fixed only a week later. All locales that translated in that period, in particular those that don't translate English accesskeys, ended up keeping the old character (that's Korean, for which this bug was originally reported).
This bug was moved outside of Mozilla Localizations because I was hoping there was a better solution (and more scalable) than checking 100 locales. Apparently there isn't.
Comment 10•4 years ago
|
||
At this point, it would be at least useful to have a comment in the file to explain the potential conflict with menubar accesskeys, including hidden ones like ALT+D (which only works on Linux?)
Comment 11•4 years ago
|
||
(In reply to Francesco Lodolo [:flod] from comment #10)
ALT+D (which only works on Linux?)
Alt+D
has historically focused the address bar in Windows Explorer/File Explorer, Internet Explorer, and Edge. It's likely the shortcut exists for compatibility reasons.
Updated•4 years ago
|
Comment 12•4 years ago
|
||
This has been already fixed for Korean.
Description
•