Defect #35802

Redmine profile language form lists non-localized languages as English

Added by Florian Krupicka 2 months ago. Updated 2 months ago.

Status:Needs feedbackStart date:
Priority:NormalDue date:
Assignee:Florian Krupicka% Done:

0%

Category:-
Target version:-
Resolution:Cant reproduce Affected version:

Description

In our Redmine installation we found, that the drop down for preferred language was listing "English" twice.

After some investigation, we found out, that Redmine, using the standard Rails I18N gem, takes all available locales from the I18N backend. A library dependency from one of our custom plugins actually provided I18N for the Khmer language (km). Since the displayed language name is localized in Redmine itself and the fallback mechanism is in place, it was displayed as "English", while still using the language code in several places, resulting in strange error messages in the log file.

History

#1 Updated by Mischa The Evil 2 months ago

  • Assignee set to Florian Krupicka

Just to make sure that I understand your report correctly, it actually is the library dependency (and not your custom Redmine plugin) that is providing a km.yml file?
Can you provide the name of / link to the library? I did a quick test trying to reproduce the issue and failed to do so.
Can you test if the following change fixes the observed behavior?

 config/application.rb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/config/application.rb b/config/application.rb
index fc6e6a33f..23f86ac6a 100644
--- a/config/application.rb
+++ b/config/application.rb
@@ -41,6 +41,7 @@ module RedmineApp

     # The default locale is :en and all translations from config/locales/*.rb,yml are auto loaded.
     # config.i18n.load_path += Dir[Rails.root.join('my', 'locales', '*.{rb,yml}').to_s]
+    config.i18n.load_path = Dir[Rails.root.join('config', 'locales', '*.{yml}').to_s]
     # config.i18n.default_locale = :de

     config.i18n.enforce_available_locales = true

#2 Updated by Florian Krupicka 2 months ago

The dependency in question is validate_url (locale file in question is validate_url-1.0.13/lib/locale/km.yml).

While I cannot verify your proposed configuration right now, it does look like it would break other Redmine plugins, which seldom add their own locales to the i18n load path but instead rely on the default behaviour of the I18N gem (simple grep -r load_path redmine/plugins didn't find anything related to i18n). So it would fix the observed behaviour but would leave us with broken I18N for the plugins themselves.

I guess the way forward would be to ensure, that Redmine only displays those locales as valid options, for which itself has appropriate translations. I would like to contribute a fix to Redmine, but since the project does not monitor the inofficial GitHub mirror and the actual way to contribute actual code patches is not documented in CONTRIBUTING.md, I could use some pointers on how to proceed here. Should I add a diff patch to this issue?

#3 Updated by Mischa The Evil 2 months ago

  • Status changed from New to Needs feedback
  • Resolution set to Cant reproduce

Florian Krupicka wrote:

The dependency in question is validate_url (locale file in question is validate_url-1.0.13/lib/locale/km.yml).

I just did a quick test pulling in that library from a custom Redmine plugin, but still wasn't able to reproduce the given behavior. What Redmine version are you observing this on?

Florian Krupicka wrote:

While I cannot verify your proposed configuration right now, it does look like it would break other Redmine plugins, which seldom add their own locales to the i18n load path but instead rely on the default behaviour of the I18N gem [...]

FTR: that change was just part of the steps of trying to pin down the cause of the behavior you are reporting. Nevertheless shouldn't it cause any issues with any regular Redmine plugins, since they don't (have to) tamper with the i18n load path themselfs. That is actually handled by the Redmine core plugin API itself (see source:/trunk/lib/redmine/plugin.rb@21201#L107).

Florian Krupicka wrote:

I guess the way forward would be to ensure, that Redmine only displays those locales as valid options, for which itself has appropriate translations.

Please feel free to propose alternative improvements to the Redmine i18n backend (residing in source:/trunk/lib/redmine/i18n.rb@21201), but what you're saying is that Redmine should ignore translation files that themselfs do not provide a custom translation string for the general_lang_name key? I doubt whether that is an actual improvement to be honest.

Florian Krupicka wrote:

I would like to contribute a fix to Redmine, [...]

As previously stated: you are welcome to do so. Thanks in advance.

Florian Krupicka wrote:

[...] and the actual way to contribute actual code patches is not documented in CONTRIBUTING.md, I could use some pointers on how to proceed here. Should I add a diff patch to this issue?

If you can attach a patch file that would be great. This "process" is documented as such on Contribute, which itself is linked to from source:/trunk/CONTRIBUTING.md@21201.
Please make sure to include sufficient test coverage that clearly demonstrates the actual issues you're solving and how you're solving them by showing what you're expecting from the respective code.

If you have any questions please let us know.

Also available in: Atom PDF