Redmine

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

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.