We're updating the issue view to help you get more done. 

Should use default translations when missing strings in i18n files

Description

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

Environment

None

Acceptance Test - Entry

None

Activity

Show:
Greg Thomas
February 13, 2019, 1:14 PM

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.

wroot
February 13, 2019, 2:16 PM

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

wroot
February 13, 2019, 2:20 PM
wroot
February 13, 2019, 2:31 PM
Edited

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.

wroot
April 23, 2019, 11:36 AM

Disregard my previous comment. This should be fixed in the next version.

Fixed

Assignee

Greg Thomas

Reporter

wroot

Labels

Expected Effort

None

Components

Fix versions

Affects versions

Priority

Minor
Configure