Closed Bug 1608096 Opened 4 years ago Closed 4 years ago

Localized accesskeys for Match diacritics checkbox conflicts with address bar shortcut (alt+d)

Categories

(Mozilla Localizations :: ko / Korean, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ikadro, Assigned: hyeonseok)

References

()

Details

Attachments

(1 file)

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.

  1. Install the Korean version of Firefox.
  2. Open the search bar. (Ctrl+F)
  3. 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.

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.

Component: Untriaged → Find Backend
Product: Firefox → Core
See Also: → 1603636

The priority flag is not set for this bug.
:mikedeboer, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mdeboer)
Summary: Invalid Shortcut in Korean Language Pack → Invalid Shortcut in localizations (conflict with alt+d)
Summary: Invalid Shortcut in localizations (conflict with alt+d) → Accesskey for Match diacritics conflict with address bar shortcut (alt+d)
Summary: Accesskey for Match diacritics conflict with address bar shortcut (alt+d) → Localized accesskeys for Match diacritics checkbox conflicts with address bar shortcut (alt+d)
Status: UNCONFIRMED → NEW
Ever confirmed: true

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

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

Component: Find Backend → Find Toolbar
Flags: needinfo?(mdeboer) → needinfo?(francesco.lodolo)
Product: Core → Toolkit

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

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

Flags: needinfo?(francesco.lodolo)

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

Flags: needinfo?(francesco.lodolo)

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

Flags: needinfo?(francesco.lodolo)

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

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

Assignee: nobody → hyeonseok
Component: Find Toolbar → ko / Korean
Product: Toolkit → Mozilla Localizations
QA Contact: channy
Version: 73 Branch → unspecified

This has been already fixed for Korean.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: