[wp-trac] [WordPress Trac] #35585: Support loading multiple languages to be loaded at the same time - rewrite the l10n to a class?

[WordPress Trac]

#35585: Support loading multiple languages to be loaded at the same time - rewrite
the l10n to a class?
--------------------------+-----------------------------
 Reporter:  jongleur1983  |      Owner:
     Type:  enhancement   |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  I18N          |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 Multi-language support in Wordpress still supports only easy solutions.

 One of the things I miss in the current case is: In my own plugin I want
 to get some strings in a different than the current UI language.
 Those are not strings of my own plugin, but e.g. from the wordpress core
 or other plugins.

 Basically I would like to have something like __($string, $domain,
 $locale).

 As far as I can see that's quite a lot of work to get done as with the
 current way i18n works (see i18n.php) it's one of the many parts heavily
 relying and hardly bound to globals.

 I therefore propose to:

 * keep the $i18n global to store the current UI language for compatibility
 purposes. For recall: $i18n currently is an associated array where the key
 denotes the domain and the value is the content of an MO file.
 * add another level on top to get an array of languages, so let e.g. the
 global $languages be instance of a class that contains all loaded
 languages, one of them being $i18n, but others as well, and another
 structure to keep what has been loaded for a particular language. (like:
 loaded domain 'x' from the set of paths's A, domain 'y' from the set of
 paths's B and so on.
 * on that class (and it's instance I called $languages above), enable the
 well known translation functions (_ _, _e and others), but overload those,
 adding a parameter for the locale. The helper structure (what has been
 loaded from where) allows to fetch missing translations without having to
 load all languages every time (this would support #6974 was well, as the
 helper structure supports delaying the load until a particular translation
 is requested.

 As a benefit it would

 * rely less on globals, usually a sign of more robust code (I understand
 why it has been done like it is, but with the current possibilities I'm
 pretty sure it would have been done as a class and better encapsulation of
 some of the globals if it would have been implemented from scratch).
 * allow multiple locales to exist side by side in memory, useful and often
 requested (when searching in google) e.g. for json apis and more.

 I would like to try it out, if I see any chance for a corresponding PR to
 be accepted in future.

 So please give your thoughts on this.
 Thanks.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/35585>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform