Module bindings are not translated when accessed from menu

[oniatus]

Module assets are not translated when the settings are opened from the menu. Opening the settings from a game with the module enabled shows the correct translation.

To reproduce, create a module, e.g. TestAndTryout. Create assets/i18n/input.lang:

{
    "category-exampleBindings" : "category-exampleBindings",
    "binding-greet": "binding-greet"
}

assets/i18n/input_en.lang:

{
    "category-exampleBindings" : "Example Bindings",
    "binding-greet": "Greet on console"
}

org.terasology.testandtryout.binds.GreeterButton:

@RegisterBindButton(id = "greet", category = "greeting", description = "${TestAndTryout:input#binding-greet}", mode = ActivateMode.PRESS)
@DefaultBinding(type = InputType.KEY, id = KeyId.G)
public class GreeterButton extends BindButtonEvent {

}

org.terasology.testandtryout.binds.package-info.java:

@InputCategory(id = "exampleBindings", displayName = "${TestAndTryout:input#category-exampleBindings}", ordering = {
        "TestAndTryout:greet"
}) package org.terasology.testandtryout.binds;

import org.terasology.input.InputCategory;

Then start the game and open the input settings from the menu. This binding strings are not translated and the TranslationSystem will log two warnings:

16:14:54.116 [main] WARN  o.t.i18n.TranslationSystemImpl - No translation for 'TestAndTryout:input#category-exampleBindings'
16:14:54.116 [main] WARN  o.t.i18n.TranslationSystemImpl - No translation for 'TestAndTryout:input#binding-greet'

Then start a game with the module enabled and open the settings from ingame again, now the settings are correctly translated.

The problem here is, that i18n files are assets, which are only available when the asset manager picks them from the enabled modules. But in the settings screen, we scrape the entire environment, including modules for all bindings.

I think it makes sense to show all available bindings from the menu, so that a client can configure for all modules and gets a notification if he has duplicate input bindings. We should check if there is a way to load the translation assets for all modules independent of a started game, either only for the input setting or in general.

[Cervator]

Similar issue: input bindings from modules can get all shuffled and problematic in the main menu. Two modules could declare the same key or use the same binding. Even if not enabled for an actual game that can still cause trouble. Also downloading a new module via in-game module browser doesn't update what's available as far as settings go.

I am skeptical of this being bite-sized since it may well involve better control of the context/environment while in the main menu :-) Some of the other on-going topics like the FlexibleConfig relates as does overhauling the new game screen.

Seemingly also related: #2309 (can we close that?), #2588

[oniatus]

I think #2309 is done, as there is i18n support for settings. Not sure about the other stuff which was discussed there.

Do we agree that we want to show all input bindings anytime? This could maybe be fixed in one change together with #2588. Maybe the fix for this one is as easy as loading the the translation assets and rendering them together with the module name for #2588. Needs a bit of research and digging in the asset stuff.

[Cervator]

Long overdue response: Yeah I think it is fine to show all input bindings. There shouldn't be that many from modules, at least not for a long time. If such a time rolls around we could probably add a filter to show/hide module bindings or group them in tabs somehow.

It would be nice to get some more technical guidance on this issue so somebody could try to approach it. I guess the main challenge would be having the assets available in the main menu on the first load. That might get into the various issues around how a game is prepared as far as environment/context goes.

(Edit: on a semi-related note I still had a pending bit of feedback linked on another UI/translation issue - https://github.com/MovingBlocks/Terasology/issues/2309#issuecomment-234458013 - which I'm cramming in here in case somebody notices and thinks up something cool. If not maybe after this issue is complete we'll just forget about it for now)

[syntaxi]

My personal thoughts on this is that ideally we would actually not show module bindings by default in the menu. I think they should only be accessible by deliberately going to access them. This could be achieved by simply say adding a list of all locally detected modules and then clicking on an entry in the list will show the module's settings.

This would solve multiple issues, including this one, #2309 and the issue of two modules having the same key bound.

Following a proper module overhaul and the movement of module selection from the newgame screen settings for modules could perhaps be moved to the module's page