Improve language dropdown usability

[alanjacobmathew]

Issue
A:
When selecting Indian languages like Malayalam, Tamil, Kannada etc, the default choice on the front end are മലയാളം, தமிழ் etc. The issue with this is, with the default keys on the keyboard, one cannot select the language, as it follows the QWERTY format(of A-Z). So the user will have to go through each and every element in the list. ALso

B:
Languages like Tamil given twice. Possible reason one is Indian Tamil and other is Srilankan Tamil. But on the frontend it is written as"தமிழ்". So identifying which is what is difficult for the user. And also the difference in completed translations could be an issue in the future. Refer Image

What could be done.
Give the English word for the language next to Indian languages, മലയാളം (Malayalam), தமிழ் (Tamil_IN), தமிழ் (Tamil_LK) and make it searchable. So when 'മ' is not available on keyboard then "M" is typed and മലയാളം (Malayalam) should be shown on the list.

Also if possible rather than it being completely dropdown a textbox with dropdown would be a good option.

[alanjacobmathew]

Language Frontend Screenshot

[sabernhardt]

Related: #37611

Trac ticket: https://core.trac.wordpress.org/ticket/60091
--

• added language filename after each language for Installed and Available both.

## Demo Video
​https://github.com/WordPress/wordpress-develop/assets/75293077/88982759-1f5d-415d-be1a-ab9e0175ca59

[swissspidy]

Just looked at the pull request mentioned above.

I don't think we'd want to show the locale slug there in parentheses. That's not useful for users. The english name would be more helpful and is also what's suggested in the ticket description.

However, the confusion between the two Tamil locales can be simply addressed by the locale teams updating the translations, so I'd suggest you to do that first.

Second, neither proposal improves the searching part, because computers just look at the beginning of the word for autosuggest. I'm not aware of an easy way to solve this, but also not sure how big of a problem that really is?

Also if possible rather than it being completely dropdown a textbox with dropdown would be a good option.

That's a poor experience, people will make typos, put in the incorrect locales etc. A dropdown is much better. So definitely not changing that into a textbox.

[up1512001]

Hi, @swissspidy used english_name instead of locale for language could you please check once?

[swissspidy]

Thanks, appreciate that you also added a new video! This will be helpful for further discussing how useful this enhancement is.

[up1512001]

Hi, @swissspidy I think for languages that already have '/^[A-Za-z() ]+$/' these letters we should not display its English name as it's already in English.

@swissspidy any update?

As per my comment on the ticket, this needs more discussion.

As per my comment on the ticket, this needs more discussion.

@swissspidy could you please ask someone to add their view on this ticket so that we can know its status?

[swissspidy]

#60522 was marked as a duplicate.

[swissspidy]

Since an update was requested:

The current PR does not adequately address this ticket in its fullest, because the ticket mentions multiple separate-yet-related issues:

Issue 1: Keyboard navigation

It's impossible to select locales with non-latin characters using a latin keyboard.

The current PR does not address this, simply because the browser by default looks at the beginning of the text for keyboard navigation, not the end.

Solving this would require a more complex, JavaScript-based solution for an autocomplete dropdown with smarter filtering. Probably with Gutenberg's ​ComboboxControl component, which could theoretically be added via the ​Preferred Languages feature plugin

This begs the question whether this is actually a widespread issue or not. So I would appreciate more user feedback on this one.

If it's not a common issue, we might not need to solve this with such a more complex component.

Issue 2: Languages like Tamil given twice

The current PR does address this issue by showing the English name after the native name. This solution was also suggested in #60522 (now closed as a duplicate) in order to improve usability.

A suggested short term workaround is to notify the respective polyglots teams to update the translation, so that they simply update their translation. That would immediately help solve this as well.

[joedolson]

In my opinion, the best solution would be to implement a wrapper available throughout the admin that implements the ComboBoxControl from Gutenberg so that we could use this here and elsewhere that it's required - this isn't the only control in the admin that would benefit from a combobox.

From the accessibility standpoint, it doesn't really matter how widespread this is; if any user is unable to select their language, then it's a bug that needs a resolution.

See also #19867.

[sabernhardt]

adds language code inside option element before the native name

[sabernhardt]

The option elements have a lang attribute, so they should not have the English name and the native name together.

• #60522 asked to show the language code (value) within the option, so I tried that with the Available languages grouping (used on Profile and Settings screens, not login or installation-related pages). Screen readers would need to speak each letter instead of reading words such as 'is' for Icelandic or 'it' for Italian, so I added the zero-width non-joiner character between them. However, the 'formal', 'informal' and 'ao90' locales could be better without spelling out every character. This may not be the best choice, but it would achieve a distinction between similar language options in the Available set, ensure that screen readers say something for each option (though the code is not easy to recognize if the native name is not read), and allow typing latin characters to jump to the options that start with that letter.
• Creating a list of English names—without native names—if the user's language is one of the English locales might help some people, but it likely would not be better for everyone.
• The Gutenberg ComboBoxControl probably could include separate elements for each language.

[samiamnot]

Related to #60770?

[joedolson]

This seems plausible for 6.6; there's enough interest and some reasonable ideas about how to resolve the issue.

[up1512001]

• adding language code like below will work?

[up1512001]

@swissspidy @joedolson any update on this ticket about how we want to display language names?

[swissspidy]

Well, as I said in my earlier comment(s), just adding the locale code at the end doesn't really solve the keyboard navigation aspect.

And the issue with the Tamil locales specifically is best solved by just asking the locale team to update the translation.

If we wanna experiment with improving the language dropdown using the ComboBox component (which supports autosuggest and improved appearance), I'd suggest doing that in the ​Preferred Languages feature project. That is already React-powered, so we avoid doing duplicate work. The big downside: ComboBox does not support option groups like we need them for the language dropdown. So first we'd need to add support for that in Gutenberg.

[sabernhardt]

60091.diff​ could solve the keyboard navigation because the language code is first, but having it in the select is not perfect.

I'm moving the ticket out of the milestone, and hopefully it will have a ComboBox proof-of-concept. Otherwise, we could decide later whether the general direction of the current patch (or something else) can be good enough.

[sabernhardt]

language code before native name, with 60091.diff

[joedolson]

While enhancing this with Combobox is a nice long term goal, in my opinion adding the country code as a prefix solves the immediate accessibility issue (keyboard access and duplicate values), and is worth pursuing more immediately using @sabernhardt's proposed solution.

If the Combobox component matures more, and adds grouping, then we can look at it; but this would still improve the situation for usability and accessibility.

[sudipatel007]

Test Report

Description
Tested Patch: https://core.trac.wordpress.org/attachment/ticket/60091/60091.diff

Environment

• WordPress: 6.7-alpha-59086
• PHP: 8.2.23
• Server: Apache/2.4.62 (Debian)
• Database: mysqli (Server: 11.5.2-MariaDB-ubu2404 / Client: mysqlnd 8.2.23)
• Browser: Chrome 129.0.0.0 (macOS)
• Theme: Twenty Twenty-Four 1.2
• MU-Plugins: None activated
• Plugins:
  • WordPress Beta Tester 3.5.6

Actual Result - Working as expected after applied patch
Screenshot : ​https://drive.google.com/file/d/1ShTBnkhUhN-7LZi9C_2JtVFKFE_0rAHD/view?usp=sharing

[joedolson]

This seems like an elegant solution, but it really just reverses the problem. As is, a user must be able to type in their desired language's character set to search the options; but with this change, they must be able to type in a Latin keyboard.

So I don't think it ultimately solves the problem, just changes who experiences it.

Punting this to future release; it needs support for Combobox or for the ​Keyboard API to be made practical.