WordPress' code just... wasn't.
This is now dealt with.
Props jrf, pento, netweb, GaryJ, jdgrimes, westonruter, Greg Sherwood from PHPCS, and everyone who's ever contributed to WPCS and PHPCS.
Fixes#41057.
git-svn-id: https://develop.svn.wordpress.org/trunk@42343 602fd350-edb4-49c9-b593-d223f7449a82
"Install" is not a noun, and while it might be acceptable to use the verb as a noun, it is not correct. Using the correct
noun, "installation", increases clarity, especially for non-native English speakers.
This change fixes the usage in user-facing text and in developer documentation.
Fixes#41620
git-svn-id: https://develop.svn.wordpress.org/trunk@41289 602fd350-edb4-49c9-b593-d223f7449a82
Previously, if no translation files exist for a text domain, `_load_textdomain_just_in_time()` went through the entire process each time it was called. This results in an increased call to `get_locale()` and its `locale` filter.
This change splits the logic into `_get_path_to_translation()` and `_get_path_to_translation_from_lang_dir()`. The former, which is used by `_load_textdomain_just_in_time()`, caches the result of the latter. It also removes some non-working code from `WP_Locale_Switcher::load_translations()`.
Props jrf, swissspidy, sharkomatic, ocean90.
Fixes#37997.
git-svn-id: https://develop.svn.wordpress.org/trunk@39330 602fd350-edb4-49c9-b593-d223f7449a82
Sometimes, a language file may not exist in exactly the format or location that `get_available_languages()` expects it to be in - for sites with this level of customisation, they need to be able to add their own language files to the list of those available.
Props yoavf.
Fixes#38788.
git-svn-id: https://develop.svn.wordpress.org/trunk@39235 602fd350-edb4-49c9-b593-d223f7449a82
`get_available_languages()` is only designed to work with translations for core. Using it for plugins/themes means unnecessary `strpos()` checks and incomplete results for plugins/themes whose names are beginning with `admin-` or `ms-`.
Props swissspidy, ocean90.
Fixes#38590.
git-svn-id: https://develop.svn.wordpress.org/trunk@39230 602fd350-edb4-49c9-b593-d223f7449a82
Previously there was no way to remove the user locale setting again, even though that might be desirable.
This adds a new 'Site Default' option to the user-specific language setting by introducing a new `show_site_locale_default` argument to `wp_dropdown_languages()`.
Props ocean90.
See #29783.
Fixes#38632.
git-svn-id: https://develop.svn.wordpress.org/trunk@39169 602fd350-edb4-49c9-b593-d223f7449a82
Leverages `get_user_locale()` in `load_*_textdomain()` and `_load_textdomain_just_in_time()` to always load translations in the user's language when in the admin.
This re-introduces [39069], but now with additional tests and a `function_exists( 'wp_get_current_user' )` check in `get_user_locale()` in case it gets used early.
Props swissspidy, ocean90.
Fixes#38485.
git-svn-id: https://develop.svn.wordpress.org/trunk@39127 602fd350-edb4-49c9-b593-d223f7449a82
Leverages `get_user_locale()` in `load_*_textdomain()` and `_load_textdomain_just_in_time()` to always load translations in the user's language when in the admin.
Fixes#38485.
git-svn-id: https://develop.svn.wordpress.org/trunk@39069 602fd350-edb4-49c9-b593-d223f7449a82
`wp_load_translations_early()` is used when WordPress isn't fully initialized. Therefore using the `WP_Locale_Switcher` with `get_locale()`/`get_user_locale()` can cause PHP fatal errors.
This reverts [38976] and [38977], and instead removes `WP_Locale_Switcher` from `wp_load_translations_early()`.
See #29783.
Fixes#38535.
git-svn-id: https://develop.svn.wordpress.org/trunk@39005 602fd350-edb4-49c9-b593-d223f7449a82
If WPDB needs to bail early, it loads the translations, which need to load the locale. Without WPDB, we can't get any database options, so can only rely on what's been loaded so far.
Fixes#29783.
git-svn-id: https://develop.svn.wordpress.org/trunk@38976 602fd350-edb4-49c9-b593-d223f7449a82
With the introduction of user-specific languages in [38705] it's necessary to be able to switch translations on the fly. For example emails should be sent in the language of the recipient and not the one of the current user.
This introduces a new `WP_Locale_Switcher` class which is used for switching locales and translations. It holds the stack of locales whenever `switch_to_locale( $locale )` is called. With `restore_previous_locale()` you can restore the previous locale. `restore_current_locale()` empties the stack and sets the locale back to the initial value.
`switch_to_locale()` is added to most of core's email functions, either with the value of `get_locale()` (site language) or `get_user_locale()` (user language with fallback to site language).
Props yoavf, tfrommen, swissspidy, pbearne, ocean90.
See #29783.
Fixes#26511.
git-svn-id: https://develop.svn.wordpress.org/trunk@38961 602fd350-edb4-49c9-b593-d223f7449a82
By enabling the user to select their preferred locale when editing the profile, we allow for greater personalization of the WordPress admin and therefore a better user experience.
The back end will be displayed in the user's individual locale while the locale used on the front end equals the one set for the whole site. If the user didn't specify a locale, the site's locale will be used as a fallback. The new `locale` property of the `WP_User` class can be used to retrieve the user's locale setting.
Props ocean90, ipm-frommen, swissspidy.
Fixes#29783.
git-svn-id: https://develop.svn.wordpress.org/trunk@38705 602fd350-edb4-49c9-b593-d223f7449a82
[37415] removed the requirement to call `load_plugin_textdomain()` / `load_theme_textdomain()`. This caused `unload_textdomain()` to not work properly anymore in these cases.
With this change, unloaded text domains need to be explicitly loaded manually if you want to use them again.
Props swissspidy, ocean90.
Fixes#37113. See #34114.
git-svn-id: https://develop.svn.wordpress.org/trunk@37855 602fd350-edb4-49c9-b593-d223f7449a82
`load_theme_textdomain()`, `load_plugin_textdomain()` and `load_muplugin_textdomain()` now try to load the .mo file from the `wp-content/languages` directory first. After the introduction of language packs, translation files are more likely to be located there.
Props swissspidy, sebastian.pisula.
Fixes#34213.
git-svn-id: https://develop.svn.wordpress.org/trunk@37414 602fd350-edb4-49c9-b593-d223f7449a82
Known functions, classes, and methods are now auto-linked in Code Reference pages following #meta1483.
Note: Hook references are still linked via inline `@see` tags due to the unlikelihood of reliably matching for known hooks based on a RegEx pattern.
See #32246.
git-svn-id: https://develop.svn.wordpress.org/trunk@37342 602fd350-edb4-49c9-b593-d223f7449a82
In `get_translations_for_domain()` don't fill the global `$l10n` with `NOOP_Translations` instances, return a `NOOP_Translations` instance instead.
Props nacin, jrf.
Fixes#21319.
git-svn-id: https://develop.svn.wordpress.org/trunk@36538 602fd350-edb4-49c9-b593-d223f7449a82
The `_network_option()` parameter order will be changing to accept `$network_id` first. The `_site_option()` functions will remain in use throughout core as our way of retrieving a network option for the current network.
See #28290.
git-svn-id: https://develop.svn.wordpress.org/trunk@34912 602fd350-edb4-49c9-b593-d223f7449a82
The `WP_INSTALLING` constant is a flag that WordPress sets in a number of
places, telling the system that options should be fetched directly from the
database instead of from the cache, that WP should not ping wordpress.org for
updates, that the normal "not installed" checks should be bypassed, and so on.
A constant is generally necessary for this purpose, because the flag is
typically set before the WP bootstrap, meaning that WP functions are not yet
available. However, it is possible - notably, during `wpmu_create_blog()` -
for the "installing" flag to be set after WP has already loaded. In these
cases, `WP_INSTALLING` would be set for the remainder of the process, since
there's no way to change a constant once it's defined. This, in turn, polluted
later function calls that ought to have been outside the scope of site
creation, particularly the non-caching of option data. The problem was
particularly evident in the case of the automated tests, where `WP_INSTALLING`
was set the first time a site was created, and remained set for the rest of the
suite.
The new `wp_installing()` function allows developers to fetch the current
installation status (when called without any arguments) or to set the
installation status (when called with a boolean `true` or `false`). Use of
the `WP_INSTALLING` constant is still supported; `wp_installing()` will default
to `true` if the constant is defined during the bootstrap.
Props boonebgorges, jeremyfelt.
See #31130.
git-svn-id: https://develop.svn.wordpress.org/trunk@34828 602fd350-edb4-49c9-b593-d223f7449a82
* Corrects phrasing used in the descriptions for and filters in `_n()` and `_nx()`, particularly with regard to the use of 'singular' instead of 'single' or '1', and 'plural' instead of 'not 1'.
* Adds example usage to `_n()`, `_nx()`, `_nx_noop()`, and `translate_nooped_plural()`.
* Adds hash notation `@return` doc for `_n_noop()` and `_nx_noop()`.
* Adds missing default values for the optional `$domain` parameter in several places.
Props johnbillion.
Fixes#34127.
git-svn-id: https://develop.svn.wordpress.org/trunk@34781 602fd350-edb4-49c9-b593-d223f7449a82
Replaces all uses of `*_site_option()` with the corresponding "network" function.
This excludes one usage in `wp-admin/admin-footer.php` that needs more investigation.
Props spacedmonkey.
See #28290.
git-svn-id: https://develop.svn.wordpress.org/trunk@34778 602fd350-edb4-49c9-b593-d223f7449a82
