Support loading multiple languages to be loaded at the same time - rewrite the l10n to a class?

[jongleur1983]

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.

[dd32]

Multiple Locales is something that I'd been experimenting with in an alternate MO reader for WordPress - ​https://github.com/dd32/ginger-mo/pull/1

what's your actual use-case? Displaying multiple translated phrases from different languages from a different textdomain sounds like something that isn't directly supported easily.
It could be useful to have a switch_to_locale() function (WordPress.com includes one for example), however there's limited use-case for it in WordPress core at present without per-user locales.

[SergeyBiryukov]

Replying to dd32:

It could be useful to have a switch_to_locale() function (WordPress.com includes one for example)

Related: #26511

[jongleur1983]

Hi again,
sorry for the delay but thanks for your response so far.

@dd32 asked for my actual use case, so here it is:
In my own blog I write posts in English and in German. With kind of a accessibility background (wrote my master thesis about accessibility for blind and visually impaired people) and a faible for clean code - in it's syntax as well as in it's semantics, writing blog posts in wordpress in different languages lacks proper lang="*" attributes in themes.

Looking over the alternatives all I found was more than I needed and it misused the wordpress interna in some way I didn't like, so I started my own plugin (for more details about why and what I did, see my blog post ​http://www.jugglingsource.de/blog/simple-language-defined-posts-in-wordpress/ about it.

One thing that I would like to make better now is the "read-more"-link.
Blog posts are now correctly tagged with the right "lang" attribute using my post, even for different languages, but the "read more" always uses the language set in wordpress.

I would like to use the language of the article it refers to as from a users perspective it is part of that article and therefore it should continue the text in the same language.

On the other hand I would like to keep the plugin separate from any theming stuff, so I have to change the read-more generated by the wordpress api, and if the language of the post is available, I don't want to change how the current theme would generate it in that language.

That's why it's not an option for me to include the corresponding strings in the plugin and use it language-independently.

switch_to_locale() as mentioned by @SergeyBiryukov might be part of a solution here, yes - but if I imagine right how it would work, it might be a bad idea to switch the locale more than once while generating the same output page as it would have to switch for some strings and back again.
The way it is described in #26511 would be supported by how I imagine it to work, but what I need - being able to control the language of some strings without having to switch the whole locale - should not be more expensive in terms of memory and runtime than the other way, but more flexible in what's possible.

[grapplerulrich]

@jongleur1983 This sounds interesting. There is a group of us who are working on putting together a basic multilingual API for WordPress. ​https://multilingualwp.wordpress.com/

[jongleur1983]

thanks @grapplerulrich for the hint. the proposal sounds as it target's the same goal, so I'm going to look into it in the next days.

Am I right that no future meeting of that group is scheduled yet? and: how to join the group (although I'm not sure how much time I'll be able to invest as I'm a .NET developer in my daily job).

[grapplerulrich]

@jongleur1983 - There are no sechedualed chats at the moment. Hopefully we can work on it a bit more. The chats take place in Slack(​https://chat.wordpress.org) in the #i18n-core channel. There is also a GitHub repo where we are discussing a few technical aspects. ​https://github.com/simonwheatley/wp-post-term-locale/issues To joing the team you just need to be present and give your opinion. :D

[swissspidy]

Given that there isn't a use case for this in core right now, switch_to_locale might suffice. Hence suggesting to close as maybelater.