In 4.2.3 Openfire would use translations from the default (EN) file, if some strings were missing in a particular language file. In 4.3.0 it displays — ?string_name? instead. It seems that it can't find default translation file or maybe something else has changed about translations. A workaround for this would be to add new string with English translation to every language file when it appears (or do google translate maybe).
The "plugin uses browser Locale not Openfire Locale" appears to be a issue in LocaleFilter in core Openfire. When accessing a plugin page, Openfire deliberately uses the browsers Locale in the place of the Openfire Locale. It's easy enough to fix, but this was looks like it was done deliberately and I'm not sure of the reasoning behind it.
Interesting. So i have to file it against Openfire, not against every plugin, though i think it is not happening with every plugin, but maybe other just don't have translations. As for reasoning, not sure either. But this seems not logical that you can set locale for Admin Console, but some parts are on their own. To users everything shown in Admin Console is one thing, they don't see separation plugins/core. So it is perceived as a bug. I would change that. And maybe then we would receive different reports
So, the latest information about missing translation strings. It can be fixed by renaming en files for all plugins. But then it won't be compatible with older versions of Openfire (so these versions will probably show ??? or something like that). We can consider upping minimum required version for plugins to 4.3 after renaming the file. But it feels like an overkill just because of the translation and no real API change.
It seems that going with Won't Fix looks like the only reasonable option.
Disregard my previous comment. This should be fixed in the next version.