Fix wp.i18n.isRTL() returning false in RTL languages

[noisysocks]

Currently wp.i18n.isRTL() will return false in RTL languages such as Arabic and Hebrew. This was fixed in GB28279. The fix needs to be added to Core for 5.7.

Currently wp.i18n.isRTL() will return false in RTL languages such as Arabic and Hebrew. This was fixed in ​https://github.com/WordPress/gutenberg/pull/28279. The fix needs to be added to Core for 5.7.

Trac ticket: https://core.trac.wordpress.org/ticket/52441

[noisysocks]

@youknowriad @jonsurrell: Does this look right to you?

[noisysocks]

I tried to fix this bug properly by fixing #46089 but it is not enough because then we have a different problem which is that WordPress will print a script’s translations before it prints the script. This means that wp-i18n’s translations will try to call wp.i18n.setLocaleData() before wp.i18n is defined.

So this is just the workaround that's in GB28279.

[jonsurrell]

I've tested ​https://github.com/WordPress/wordpress-develop/pull/977 with WordPress 5.6.1 by:

• Set RTL language
• Enter post editor
• Console log wp.i18n.isRTL() (should be true)
• Without the patch, it's false
• Manually apply the patch and the result is then true as it should be.

The patch seems to work and is very similar to the solution used in Gutenberg.

This does seem like more of a workaround to me, I understand the solution to https://core.trac.wordpress.org/ticket/46089 is complex but I'd really like to see a solution for that. This has the limitation that it still doesn't add wp-i18n translations, it just adds a specific translation that we know is required.

What about adding a condition to WP_Scripts::print_translations to print the localization after if the script is the wp-i18n script?

​https://github.com/WordPress/wordpress-develop/blob/3c40632397cf1ee64e09c7ac767391dfac59e5ea/src/wp-includes/class.wp-scripts.php#L574-L602

[noisysocks]

Thanks for testing!

This does seem like more of a workaround to me, I understand the solution to https://core.trac.wordpress.org/ticket/46089 is complex but I'd really like to see a solution for that. This has the limitation that it still doesn't add wp-i18n translations, it just adds a specific translation that we know is required.

Looking at the source for for wp-i18n, it seems that "ltr" is the only localised string that that module has. I agree that this is hacky, but is making print_translations treat wp-i18n specially any less hacky? Both solutions feel not ideal to me...

Really I am thinking that wp-i18n should not have any localised strings at all. It doesn't make intuitive sense to me that a module which is used to implement localisation should require localisation. I wonder if there's another way of implementing isRTL?

[youknowriad]

i18n is special enough (it's the package responsible for the translations) that I don't mind using the same solution used in Gutenberg. Maybe later we could have some linting protection forbidding new strings there.

[noisysocks]

Let's commit this then. Thanks for testing @jonsurrell.

[noisysocks]

In 50259:

Fix wp.i18n.isRTL()

Fixes a bug causing wp.i18n.isRTL() to return false in RTL langauges by manually
loading the translated 'ltr' string for the i18n dependency. This ports over an
identical fix that was made in Gutenberg.

Fixes #52441.
Props @jonsurrell @youknowriad.