Plugins should use Openfire Locale instead of systems's Locale for translations


As was pointed out in related ticket comments, it seems that Openfire is checking system's locale for plugins, so they use translations based on locale and not the main translation language set for the whole Admin Console. This seems inconsistent and confusing to users.

By fixing that will close tickets filed for separate plugins:




Greg Thomas
February 13, 2019, 5:04 PM

OK, having looked again at the code, I'm now doubly confused. Using the master branch of Openfire, and the most recently released plugins;

a) My earlier assertion that Openfire was looking at the browser locale is simply wrong. The comments talk about it ("we might want to honor a preference to get the user's locale based on request headers.") which was what threw me, but in practice the code in LocaleFilter does use the Openfire Locale.

b) I'm unable to reproduce the problem. If I set Openfire Locale to (e.g.) Russian, I see Russian for the Search/Monitoring/Registration plugin pages. If I set Openfire back to English and my browser to Russian ( confirms) then I see English everywhere.

c) However the registration plugin is showing "garbled Russian", cf. - I don't know if a simple re-release will pick up enough to fix that as the registration plugin hasn't been released for over a year, or if more effort is required.

February 13, 2019, 8:01 PM

Ok, i have worded this ticket based on your assumption that browser locale is in use. Then it must be OS locale. That would be harder to test as you would have to change your OS locale to Russian.

February 14, 2019, 5:56 AM

Changed name and description to "system's locale".


Dave Cridland



Expected Effort


Ignite Forum URL