Block editor canvas should use site language and language direction

[OmerQadirFM]

Description

when I'm making a Kurdish or Arabic website, my website shows from LTR in Gutenberg interface but when I visit my website it shows RTL, My user profile language is English and my website language is Kurdish, it is supposed to always shows RTL.

Step-by-step reproduction instructions

in Gutenberg interface
Change user profile language to English
Change website language to Kurdish or Arabic
then go to Appearance > Editor and you will see the issue

Screenshots, screen recording, code snippet

No response

Environment info

• WordPress: 6.4-alpha-56272
• PHP: 8.1.9
• Server: nginx/1.16.0
• Database: mysqli (Server: 8.0.16 / Client: mysqlnd 8.1.9)
• Browser: Edge 114.0.1823.86 (Windows 10/11)
• Theme: Twenty Twenty-Three 1.1
• MU-Plugins: None activated
• Plugins:
  • WordPress Beta Tester 3.5.2

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[github-actions]

Hi,
This issue has gone 30 days without any activity. This means it is time for a check-in to make sure it is still relevant. If you are still experiencing this issue with the latest versions, you can help the project by responding to confirm the problem and by providing any updated reproduction steps.
Thanks for helping out.

[OmerQadirFM]

I still have a same problem with WordPress 6.3

[sabernhardt]

I thought this was a new bug with the iframe editor, but #44863 mentions needing to have (post) content in the site language when the profile language is different. I did not find a WordPress version that showed site (or post) content in the site language when the profile was different. Did it ever work?

[OmerQadirFM]

• WordPress: 6.6-RC2
• PHP: 8.3.8
• Server: Apache/2.4.43 (Win32) mod_fcgid/2.3.9a
• Database: mysqli (Server: 8.0.16 / Client: mysqlnd 8.3.8)
• Browser: Edge 126.0.0.0 (Windows 10/11)
• Theme: Twenty Twenty-Four 1.1
• MU-Plugins: None activated
• Plugins:
  • WordPress Beta Tester 3.5.6

2024-07-07.02-51-02.mp4

[ramonjd]

I'm not sure how to reproduce.

I was testing using WordPress 6.7-alpha-58576-src running Twenty Twenty-Four theme. And then with the Gutenberg plugin activated.

I switched to Arabic, then I did have to update the language packs:

/wp-admin/update-core.php?action=do-translation-upgrade

Site Editor menu	Editor

[OmerQadirFM]

In this Example your Profile language same as your Site language means your profile and your Site language are same.
the issue happens when your Profile language is English, and your Site language is Arabic
try to change you profile language to English

[ramonjd]

In this Example your Profile language same as your Site language means your profile and your Site language are same.
the issue happens when your Profile language is English, and your Site language is Arabic

Apologies, thanks for setting me straight.

So, is the following an accurate summary?

• the content in the editor canvas should match the site language (so the preview is the same as what you see on the website)
• the editor itself (controls etc) should match the user profile language

[OmerQadirFM]

In this Example your Profile language same as your Site language means your profile and your Site language are same.
the issue happens when your Profile language is English, and your Site language is Arabic

Apologies, thanks for setting me straight.

So, is the following an accurate summary?

• the content in the editor canvas should match the site language (so the preview is the same as what you see on the website)
• the editor itself (controls etc) should match the user profile language

Yes, for example, in my case I build Arabic and Kurdish websites and they are both RTL languages and my profile is always in English

When site language is Kurdish (RTL) should the Theme language be Kurdish too and the Editor canvas should shows from right to left (RTL)

the Admin dashboard and The Editor Dashboard should match the profile language

[ramonjd]

I can reproduce now, thanks!

The TL;DR is that the iframed editor needs access to the site locale to set lang and dir attributes on the html element.

What's happening now is that, if a user locale is set in /wp-admin/profile.php the block editor will use it to display the site contents. This is despite whether the site locale is set to another locale.

I had a quick look and there are a few things to investigate here.

The editor iframe

The editor iframe assumes that the editor language direction is the same as the parent frame language direction, and copies the attribute to the iframed html element:

gutenberg/packages/block-editor/src/components/iframe/index.js

Line 164 in 1f4891e

contentDocument.dir = ownerDocument.dir;

If the user locale is en_US but the site locale is something else, we'd prefer the editor iframe to use the site locale to accurately reflect the site's contents.

However, the editor iframe doesn't know what the site locale is, because it's looking at the parent frame, which is set to the user locale of en_US.

Editor settings

We could fetch the right values from the editor iframe via the settings... the interesting task will be returning accurate values for language direction.

Here's what I'm seeing:

In the editor, the "current" locale is set to the user locale. So, en_US in our example.

That means is_rtl() looks at the current, global locale.

What we want is the site locale however, and I'm not yet sure how to grab that. There's probably a way, I just ran out of time.

// Site locale
get_locale(); // ar

// User locale (current)
get_user_locale(); // en_US

// Current site language dir
is_rtl(); // ltr from the current locale.

// Current user language dir
?? // How to get this?

CSS

I'm not sure yet, but I'm also wondering if different CSS needs to be loaded if the iframed editor's language direction differs from the parent.

I'd wager "yes", but I haven't looked into it.

[OmerQadirFM]

Environment

• WordPress: 6.6
• PHP: 8.3.8
• Server: nginx/1.16.0
• Database: mysqli (Server: 10.4.32-MariaDB / Client: mysqlnd 8.3.8)
• Browser: Edge 126.0.0.0 (Windows 11)
• Theme: Twenty Twenty-Four 1.2
• MU-Plugins: None activated

[swissspidy]

What we want is the site locale however, and I'm not yet sure how to grab that. There's probably a way, I just ran out of time.

You'll need to switch to the locale first to find out. e.g.

$switched_locale = switch_to_locale( get_locale() );
$is_rtl = is_rtl();
if ( $is_switched ) {
if ( $switched_locale ) {
	restore_previous_locale();
}

I'm not sure yet, but I'm also wondering if different CSS needs to be loaded if the iframed editor's language direction differs from the parent.

I'd imagine you need to load all the blocks' RTL stylesheets.

Maybe some different translations too.

[OmerQadirFM]

I updated to 6.6.1 but still there is same issue

Environment

• WordPress: 6.6.1
• PHP: 8.1.29
• Server: nginx/1.16.0
• Database: mysqli (Server: 8.0.16 / Client: mysqlnd 8.1.29)
• Browser: Edge 126.0.0.0 (Windows 11)
• Theme: Twenty Twenty-Four 1.2
• MU-Plugins: None activated
• Plugins:
  • WordPress Beta Tester 3.5.6

[swissspidy]

@OmerQadirFM This is expected, as this issue is still open :-)

[ramonjd]

Thanks @swissspidy - I'd totally overlooked switch_to_locale(), thanks for the nudge.

I have a proof of concept:

• Editor: use site locale in editor iframe #63883

It probably raises more questions than answers, most notably how to handle block CSS and block placeholder text direction. There are without doubt many more that I've not thought of.

[ramonjd]

A bit of history: a bug was reported about similar behaviour in the classic editor:

• https://core.trac.wordpress.org/ticket/48996

[ndiego]

@ramonjd just checking in to see if we are still aiming to get this completed for 6.7, or whether it should be punted to 6.8. Thanks!

[ramonjd]

@ndiego Thanks for the ping. Unfortunately, I won't have time in the immediate future to take this further. I've punted it.

The status is that #63883 adds the correct lang attributes to the editor canvas, but more works is required so that the editor canvas is translated in the site language where the surrounding editor/admin language differs.

[ndiego]

Thanks for the update!