[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        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Description changed by SergeyBiryukov:

Old description:

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

New description:

 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#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform