WordPress.org
Get WordPress

Make WordPress Core

Opened 8 years ago

Closed 5 years ago

#40715 closed defect (bug) (duplicate)

TinyMCE should use the site language instead of the user one

Reported by: 7studio's profile 7studio Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: I18N Keywords:
Focuses: accessibility, administration Cc:

Description

Since the change 36802, TinyMCE in the admin panel uses the language defined by the default translated string (html_lang_attribute) based on locale. In almost all cases, the locale is defined by the site language.

Except that since the 4.7, the user is able to select their preferred locale (language) when editing their profile.

In this specific case, if the selected language is different from the site language, TinyMCE will use a wrong locale (the user one) for the lang attribute on its <html> element.

This wrong behaviour is due to get_bloginfo( 'language' ) which is used to define the wp_lang_attr entry.

That's a shame especially when you want to use the :lang CSS pseudo-class and you get a different result in the admin panel and on your site.

For the moment, I'm able to resolve this issue by overriding the value via the filter tiny_me_before_init:

<?php

function fix_wp_lang_attr( $mceInit ) {
        $lang = get_locale();
        $lang = str_replace( '_', '-', $lang );

        $mceInit['wp_lang_attr'] = $lang;

        return $mceInit;
}
add_filter( 'tiny_me_before_init', 'fix_wp_lang_attr' );

Hope you will consider this ticket and it contributes to WP.

Change History (3)

#1 @sabernhardt
5 years ago

  • Component changed from General to I18N
  • Focuses accessibility added
  • Version 4.7 deleted

@7studio Hi and thanks for the report!

This would be good to consider along with other lang attribute settings (and a filter for multi-lingual sites) in ticket:48996.

This ticket was mentioned in ​Slack in #accessibility by afercia. ​View the logs.
5 years ago

#3 @afercia
5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Closing in favor of #48996 to avoid duplicates. While #48996 was created later, it has some more context and a broader scope. Please do feel free to join the conversation there.

Note: See TracTickets for help on using tickets.