Make WordPress Core

Opened 7 months ago

Last modified 3 weeks ago

#60091 assigned defect (bug)

Improve language dropdown usability

Reported by: alanjacobmathew's profile alanjacobmathew Owned by:
Milestone: 6.7 Priority: normal
Severity: normal Version:
Component: I18N Keywords: has-patch 2nd-opinion
Focuses: ui, accessibility, administration Cc:

Description

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.

Attachments (3)

oCqAwKbFD7.png (22.1 KB) - added by alanjacobmathew 7 months ago.
Language Frontend Screenshot
60091.diff (1.3 KB) - added by sabernhardt 4 months ago.
adds language code inside option element before the native name
available-languages-60091.diff.png (25.6 KB) - added by sabernhardt 7 weeks ago.
language code before native name, with 60091.diff

Download all attachments as: .zip

Change History (28)

@alanjacobmathew
7 months ago

Language Frontend Screenshot

#1 @sabernhardt
7 months ago

  • Component changed from Administration to I18N
  • Focuses administration added

Related: #37611

This ticket was mentioned in PR #6122 on WordPress/wordpress-develop by @up1512001.


5 months ago
#2

  • Keywords has-patch added

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

#3 @swissspidy
5 months ago

  • Keywords 2nd-opinion added

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.

#4 @up1512001
5 months ago

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

#5 @swissspidy
5 months ago

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

#6 @up1512001
5 months ago

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.

@up1512001 commented on PR #6122:


5 months ago
#7

@swissspidy any update?

@swissspidy commented on PR #6122:


5 months ago
#8

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

This ticket was mentioned in Slack in #core-i18n by up1512001. View the logs.


5 months ago

This ticket was mentioned in Slack in #accessibility by up1512001. View the logs.


5 months ago

@up1512001 commented on PR #6122:


5 months ago
#11

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?

#12 @swissspidy
5 months ago

#60522 was marked as a duplicate.

#13 @swissspidy
5 months ago

  • Summary changed from Language Selection Issue on Frontend to Improve language dropdown usability

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.

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


4 months ago

#15 @joedolson
4 months ago

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
4 months ago

adds language code inside option element before the native name

#16 @sabernhardt
4 months ago

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.

#17 @samiamnot
4 months ago

Related to #60770?

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


4 months ago

#19 @joedolson
4 months ago

  • Milestone changed from Awaiting Review to 6.6

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

#20 @up1512001
4 months ago

  • adding language code like below will work?

https://github.com/FireWork-Production-Private-Ltd/npm_github_package/blob/main/images/language-dropdown.png

#21 @up1512001
3 months ago

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

#22 @swissspidy
3 months ago

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.

#23 @sabernhardt
7 weeks ago

  • Milestone changed from 6.6 to Future Release

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
7 weeks ago

language code before native name, with 60091.diff

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


3 weeks ago

#25 @joedolson
3 weeks ago

  • Milestone changed from Future Release to 6.7

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.

Note: See TracTickets for help on using tickets.