wp_load_translations_early does not work without WPLANG defined

[szepe.viktor]

In the Hungarian WP 4.0 the maintenance text appears in english.

[nacin]

This is once WordPress is installed, yes?

[nacin]

And installed with the English package but then choosing Hungarian during install, rather than using the Hungarian package.

[szepe.viktor]

Yes, the Hungarian packages has $wp_local_package = 'hu_HU';

[SergeyBiryukov]

Related: #30382

[kidsguide]

This is a problem with all the language packages not just Hungarian.

[temuag]

I may have found the solution, see:
​https://wordpress.org/support/topic/translation-of-the-maintenance-mode?replies=19

You need to make sure $wp_local_package = 'YOUR LOCAL'; is defined at the end of wp-includes/version.php

The error may come from an upgrade, I had the same issue, and I could fix it this way.

[ocean90]

Replying to temuag:

You need to make sure $wp_local_package = 'YOUR LOCAL'; is defined at the end of wp-includes/version.php

This global variable is defined when you download a localized package from a local site like hu.wordpress.org.

Sadly, there is nothing we can do. We can't access the locale option because wp_maintenance() is loaded before a database connection can be initialized. wp_load_translations_early() is also used for database errors so we can't access the database here too.

Closing as a wontfix, but feel free to reopen if you have a patch ready.

[ocean90]

Replying to ocean90:

Sadly, there is nothing we can do.

Maybe $_SERVER['HTTP_ACCEPT_LANGUAGE'] could be an alternative source for setting the locale.

[SergeyBiryukov]

#41823 was marked as a duplicate.

[SergeyBiryukov]

Reopening to look into comment:10.

[soulseekah]

HTTP_ACCEPT_LANGUAGE

[soulseekah]

Attached a simple HTTP_ACCEPT_LANGUAGE-based locale detection.

Regular expression based on a locale list from here ​https://stackoverflow.com/questions/3191664/list-of-all-locales-and-their-short-codes#3191729

This is in no way a substitute for the deprecated WPLANG constant. We need to find a way to set the language for those notices without using WPLANG now.

[swissspidy]

Using the heder for this could be interesting. If moved to a separate function, the logic can be testable.

To-do:

• Decide what to do with values such as de. I think treating those as de_DE makes for the best experience, even though it's not super accurate.

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

[ramon fincken]

I have read ISO documentation and simplified and somewhat improved the regex a bit ( which was pretty good to be honest ).

Also I allowed for commandline WP-CLI / PHP where this header is not even present ( PHP Warning: Undefined array key "HTTP_ACCEPT_LANGUAGE" )

[swissspidy]

@ramon-fincken Mind providing any suggestions on the existing PR instead? It is more sophisticated and includes tests already.

[ramon fincken]

I am open for your suggestions if that is what you mean @swissspidy

There is already great progress over at #6623 with more edge cases covered and proper tests. I suggest focusing on that PR instead.

[swissspidy]

No, I mean focusing our effort on the existing PR at ​https://github.com/WordPress/wordpress-develop/pull/6623 which is nearly complete.

[ramon fincken]

Ok what do you need ?

​https://github.com/WordPress/wordpress-develop/pull/6623/files#diff-31cd15428a59baa3494149d7ccf047ce80c8d7783d6e889c80d118043548ee1aR2005

empty is not the correct check ( i.e. command-line )

The regex might need some explaining.
Do you have an example where we actually have 3, 4 or 5 for the country ISO wise?

[swissspidy]

empty is just fine and works in CLI context where the header is absent. The tests prove that.