Make WordPress Core

Opened 8 years ago

Closed 4 years ago

#40194 closed enhancement (maybelater)

Automatic text direction detection for input fields in the admin area

Reported by: johnbillion's profile johnbillion Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: I18N Keywords: needs-patch
Focuses: javascript, rtl, administration Cc:

Description

When the WordPress admin area is displayed in a left-to-right language (such as English), any text in a right-to-left language (such as Arabic) will not be displayed correctly in input fields due to the incorrect text direction, and vice versa for left-to-right text displayed in right-to-left inputs.

This can be a significant problem not only for multilingual websites, but also for sites where users are using the admin area in a language with a text direction opposite to the content they're editing, or indeed any site which has published any content in a language that uses the opposite text direction.

After some discussion at WordCamp London with @s1m0nd, @swissspidy, and @shadyvb, it was decided that input fields across the whole of the WordPress admin area should detect the direction of the text contained within them and switch the text direction of the input field on the client side automatically.

An example of this in action is on google.com, where the main search input field automatically switches direction as soon as you input the first character. This is the desired behaviour. @shadyvb has some experience implementing this already. The text direction of a character is detectable based on the right-to-left unicode range(s).

The same problem also extends to output of user-defined content that doesn't appear in an input field, for example category names in the Categories meta box, user display names, and comments on the Comments screen, but this may be more complicated to implement so is best approached in a follow-up ticket.

Adding the accessibility keyword as there may be some Aria live requirements around switching an input's text direction on the fly.

QUnit tests for the functionality would be desirable.

Attachments (2)

Screen Shot 2017-03-18 at 11.18.01.png (61.9 KB) - added by johnbillion 8 years ago.
Screen Shot 2017-03-18 at 14.22.46.png (152.7 KB) - added by shadyvb 8 years ago.
Explicit Directional Embeddings

Download all attachments as: .zip

Change History (8)

#1 @swissspidy
8 years ago

  • Focuses javascript added

@shadyvb
8 years ago

Explicit Directional Embeddings

#2 @shadyvb
8 years ago

  • Focuses rtl added

While single-line inputs should be okay detecting the first character just like what Google currently does, this does not apply cleanly to WYSIWYG fields though, because switching the whole content to one direction assumes it is all expected to be in that direction, which is not always the case.

So I think there are a few cases to discuss/handle here:

# Inputs:

Single-line inputs, minus those with URL/Email/etc types, should be safe to monitor/handle using the technique Google currently has. Basic demo on JSBin.

TinyMCE already has RTL/LTR buttons possible via WP-RTL plugin, so what can be introduced here is the detection of each new line's first character and automatically switching the direction of that paragraph based on it. Which might mean :

  1. Updating the plugin to do that, and..
  2. Start thinking about the fundamental question of whether we should add an option for enabling RTL buttons instead of having to install a plugin for it.

So far, apart from WYSIWYG/TinyMCE, this only handles the direction of the text during writing, but does not yet address how the value is displayed, either within admin area, or in front-end. So:

# Output

Unicode does support a feature called Explicit Directional Embeddings which allows adding zero-width unicode characters to manage the direction of a subset of text within a larger string. Check screenshot.

This can be easily implemented by detecting RTL characters ( or LTR ones in an RTL website ) at writing time, and adding the necessary RLE/LRE/PDF characters, or even a single ALM/LRM one, so output maintains the proper flow of text in either direction.

I'll work on POCs for input/output handling, as well as the proposed TinyMCE plugin update.

Would appreciate some feedback on:

  1. Inclusion of RTL buttons in core, enabled via an option in 'Writing' screen, coupled with auto-detection of the first paragraph character to switch its direction.
  1. Using unicode characters to manage text flow, and whether we would store them in database, saving the processing time of doing it on-the-fly on every load, or provide a filter that can be opt-in/out by users/devs, or doing it via JS altogether ( a bit hacky and more painful to maintain IMHO, given the need to select what output should be processed and what not ).
Last edited 8 years ago by shadyvb (previous) (diff)

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


8 years ago

#4 @swissspidy
6 years ago

Related Gutenberg issue: https://github.com/WordPress/gutenberg/issues/12352

Perhaps dir="auto" is a simple solution for this?

#5 @afercia
6 years ago

  • Focuses accessibility removed

As previously mentioned, there are probably a few exceptions like input fields meant for URLs, see also [29623].

As per switching "on the fly":

An example of this in action is on google.com, where the main search input field automatically switches direction as soon as you input the first character. This is the desired behaviour.

Yes, in that case there would be the need to inform users with a clearly visible and audible message. I'm going to remove the accessibility focus though, to keep the accessibility Trac report clean. Glad to put it back if this ticket will see some progress and if there will be the need for additional accessibility feedback.

#6 @johnbillion
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.