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

[WordPress Trac]

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

Comment (by swissspidy):

 Replying to [comment:41 ocean90]:
 > * 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.

 Fixed in the latest patch. Renamed the method to
 `restore_previous_locale()`. The hooks run before setting the global, like
 in `switch_to_blog()` for example.

 > * While looking at #29783: 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?

 Do you have a use case for temporarily switching the user locale? If yes,
 a context switch could make sense and is fairly easy. Just needs a second
 stack.

 Otherwise I was more thinking that developers could use it like this:

 {{{#!php
 <?php
 $switched = switch_to_locale( get_user_locale() );
 // Do stuff
 if ( $switched ) {
   restore_previous_locale();
 }
 }}}


 > *  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`.

 It'd be awesome if we don't have to cache translations. This would allow
 us to basically remove all complexity from this class. Otherwise we'd
 really have to check the `$l10n_unloaded` global.

 Citing @ocean90 from #29783:

 > We should avoid loading multiple languages into memory, only one at the
 same time.

 > * This really should be tested in combination with #29783. 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.)

 This shouldn't really affect #29783 right now. Regarding testing, I'll
 first add some unit tests and afterwards we can do some benchmarks.

 As these two tickets are so tied to each other, should we perhaps merge
 the patches?


 Replying to [comment:43 johnjamesjacoby]:
 > Is it too late to recommend a `WP_Switcher` base class that sites can
 use, too?
 >
 > Related: #19572 <3

 You're right, there are lots of similar cases in core and some kind of
 abstraction could certainly help. If we don't mess up badly now, we can
 also do this later I think.

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