[wp-trac] [WordPress Trac] #26511: Introduce a locale-switching function

[WordPress Trac]

#26511: Introduce a locale-switching function
--------------------------------------+------------------------
 Reporter:  johnbillion               |       Owner:  ocean90
     Type:  feature request           |      Status:  reviewing
 Priority:  normal                    |   Milestone:  4.7
Component:  I18N                      |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------
Changes (by ocean90):

 * keywords:  has-patch dev-feedback has-unit-tests => has-patch has-unit-
     tests


Comment:

 Nice job!

 Feedback for [attachment:26511.2.diff]:

 * The property `$available_languages` has no `@since` tag.
 * The pomo library is an external library, it shouldn't get `@since` tags
 for a WP version.
 * `get_available_languages()` returns only core languages, something to
 keep in mind.
 * `has_translations_for_locale()` is an odd method. It's only used to
 check `$this->translations[ $locale ]`. I think we can remove it or should
 think about a getter/setter method for `$this->translations`.
 * The actions `restore_locale ` and `switch_locale` are running _after_
 the locale has been switched. Should they be named `locale_restored` and
 `locale_switched`?
 * The function/method name `restore_locale()` is ambiguous. Which locale
 is restored? For multisite we have `restore_current_blog()`. The DocBlock
 for `restore_locale()` mentions "previous locale". Maybe name it
 `restore_previous_locale()`?
 * When calling `load_default_textdomain()` we can pass the locale, this
 would avoid one `get_locale()` call.
 * While looking at #26511: It's likely that we'll have a new function
 `get_user_locale()` which should probably have it's own filter. Do we need
 context - site vs. user - support for the switcher? What would be required
 to make this possible?
 *  I'm wondering if we really have to cache the translations now that we
 have `_load_textdomain_just_in_time()`. Probably only because not all
 plugins/themes are using language packs, yet…
 * Do we have to care about unloaded text domains? See
 `unload_textdomain()` and the global `$l10n_unloaded`.
 * This really should be tested in combination with #29783 (needs-refresh).
 How does this work performance-wise for a regular site with 1 theme and
 maybe 10 plugins? (This should include one of the big ones like Jetpack or
 WooCommerce.)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/26511#comment:41>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform