The plugin does not respect the user profile language setting in the backend

[lllopo]

Describe the bug

The plugin does not respect the user profile language setting in the backend.

Steps to Reproduce

1. Set the site language to language A
2. Set the, let's say Administrator language in his profile to language B
3. Login as the Administrator in the backend and go to plugin settings.

What happens: the plugin settings are displayed in language A
Expected behavior: the plugin settings should be displayed in language B

Screenshots, screen recording, code snippet

No response

Environment information

Doesn't matter

WordPress information

WordPress 6.0.2
Simple Local Avatars 2.6.0

Code of Conduct

• I agree to follow this project's Code of Conduct

[lllopo]

Same goes for the added settings in the "Discussion" section.

[jeffpaul]

@lllopo is there a translation on translate.wordpress.org available for language B?

[lllopo]

@jeffpaul Most certainly yes, since my profile language (or so-called language B) is the default Wordpress English. The site language is Dutch and unfortunately the whole admin shows in English (as per my profile preferences) bar the Simple Local Avatar settings which show in Dutch (also one more plugin that has the same problem, but that's irrelevant).

[lllopo]

@jeffpaul I'm the site technical administrator, but I don't speak Dutch. As you can imagine - it is not just a cosmetical annoyance, it is quite a problem for me to do configurations while settings show up in Dutch.

[faisal-alvi]

I have tested and I was able to regenerate this issue, it's a weird behavior - as IMO, it should be handled by the WordPress core itself, or perhaps I might be missing something.

[dkotter]

@faisal-alvi All right, I believe I have this one figured out. In doing some step through debugging, was seeing that our translations are being loaded prior to the function wp_get_current_user being available. This means we always end up using the site language translation files instead of the individual user's language.

This stirred a memory and I remembered we had a similar issue reported on .org that I added as an issue in #88. This was solved in #89 but since we still had strings being translated early, it seems we still have issues as reported here.

I think the easiest fix here is to remove the textdomain from those avatar rating fields, as these strings are the exact same as what core uses (I believe) and as such, there's no need for us to maintain those translations.

In testing locally, I changed:

$this->avatar_ratings = array(
	'G'  => __( 'G — Suitable for all audiences', 'simple-local-avatars' ),
	'PG' => __( 'PG — Possibly offensive, usually for audiences 13 and above', 'simple-local-avatars' ),
	'R'  => __( 'R — Intended for adult audiences above 17', 'simple-local-avatars' ),
	'X'  => __( 'X — Even more mature than above', 'simple-local-avatars' ),
);

to:

$this->avatar_ratings = array(
	'G'  => __( 'G — Suitable for all audiences' ),
	'PG' => __( 'PG — Possibly offensive, usually for audiences 13 and above' ),
	'R'  => __( 'R — Intended for adult audiences above 17' ),
	'X'  => __( 'X — Even more mature than above' ),
);

and it fixed the issue reported here. I also didn't see any other issues from that change but that should be tested a bit more thoroughly.

If this is the right approach, we may be able to undo some/all of the changes made in #89, as I think this solution might fix the issue we were attempting to fix there, though again, that would need tested.

[lllopo]

@dkotter This is probably the case. I have an even crazier situation. I'm writing a plugin and wanted to check for some dependencies. So, I do get_plugin_data when my plugin is loading. turns out that it calls get_user_locale at some point and at that stage (so before plugins loaded) wp_get_current_user is not present and the wrong locale is returned. Now the crazy part - it seems that not only the wrong locale is returned, but it is somewhat cached (or I don't know), BUT this call in my plugin messes up the subsequent plugins' translations too. For example - Elementor appears half translated in Dutch, half in English. Messy.

[dkotter]

but it is somewhat cached

Yeah, from what I found, the first time translatable strings are found for a specific text domain, that information is loaded into a global variable. Anytime additional strings are found in that same text domain, it doesn't rebuild that information it just uses what's already in that global variable. I'm sure this helps significantly with performance but what that does mean is if you have strings that are translatable that are loaded prior to wp_get_current_user being available, you'll end up with what you're seeing (potentially) where things are translated into two different languages.

We'll work on getting a PR in place to at least fix that here in Simple Local Avatars. Thanks for your report!

[lllopo]

@dkotter Yes, I got to the same conclusion. So now I've offset all of the bootstrapping of my plugin to plugins_loaded with prio 1. Not sure if it is a good solution but works for me - do nothing when plugin is read, just configure as much as possible and then kick the actual logic when all plugins are loaded. Had to use prio 1, though as I have some hooks on plugins _loaded within my plugin itself, but overall - it seems to work fine (haven't fully tested it yet).