Make WordPress Core

Opened 4 months ago

Last modified 4 weeks ago

#60091 assigned defect (bug)

Improve language dropdown usability

Reported by: alanjacobmathew's profile alanjacobmathew Owned by:
Milestone: 6.6 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 (2)

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

Download all attachments as: .zip

Change History (22)

@alanjacobmathew
4 months ago

Language Frontend Screenshot

#1 @sabernhardt
4 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.


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

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

#5 @swissspidy
2 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
2 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:


2 months ago
#7

@swissspidy any update?

@swissspidy commented on PR #6122:


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


8 weeks ago

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


8 weeks ago

@up1512001 commented on PR #6122:


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

#60522 was marked as a duplicate.

#13 @swissspidy
7 weeks 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.


5 weeks ago

#15 @joedolson
5 weeks 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
5 weeks ago

adds language code inside option element before the native name

#16 @sabernhardt
5 weeks 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 weeks ago

Related to #60770?

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


4 weeks ago

#19 @joedolson
4 weeks 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 weeks ago

  • adding language code like below will work?

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

Note: See TracTickets for help on using tickets.