WordPress.org
Get WordPress

Make WordPress Core

Opened 5 years ago

Last modified 7 months ago

#47546 new defect (bug)

The language used for the `lang` attribute isn't validated before being used

Reported by: johnbillion's profile johnbillion Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: I18N Keywords: needs-testing needs-patch
Focuses: Cc:

Description

In the admin area, the lang attribute can be populated directly from the WPLANG option or the user's locale meta field. In these cases, no check is performed to ensure that the corresponding language files exist before using the value for the lang attribute.

This can come about if the language files that are used by a user or the site are deleted, or the value is otherwise modified to include an incorrect value.

For example, running wp user meta update admin locale it_IT will result in lang="it_IT" being added to the <html> element, even if the corresponding language files don't exist. This can result in the browser being confused about the language of the page, and can also result in assistive technology handling or pronouncing text incorrectly.

It would be preferable if the existence of the corresponding language files was checked before the lang attribute was output, falling back to en_US as necessary. I'm not sure if it's best to make this change in the get_language_attributes() function, or lower in the determine_locale() or get_bloginfo() functions.

Attachments (1)

47546.diff​ (409 bytes) - added by krynes 5 years ago.
I suggest to check if core language is installed and then display. If not return default Wordpress language

Download all attachments as: .zip

Change History (5)

@krynes
5 years ago

I suggest to check if core language is installed and then display. If not return default Wordpress language

#1 @krynes
5 years ago

  • Keywords has-patch added; needs-patch removed

#2 @johnbillion
5 years ago

  • Keywords needs-testing added

Thanks for the patch @krynes.

Is there a performance overhead with calling get_available_languages()?

#3 @justinahinon
4 years ago

get_available_languages() takes ~1(exp-2) milliseconds more time to run than just get_locale().

Also I tested 47546.diff and it's applying correctly.

#4 @swissspidy
7 months ago

  • Keywords needs-patch added; has-patch removed

I wouldn't necessarily want to call get_available_languages() on the frontend. The function is cached now though in 6.5, which is good.

However, IMO this should be handled when saving the user meta, like edit_user() does.

That could be further improved by registering these options with register_meta / register_setting and a dedicated sanitization callback.

Note: See TracTickets for help on using tickets.