Terasology: No i18n support for Settings → Input

[rzats]

Classes from the org.terasology.rendering.nui.layers.mainMenu.inputSettings package currently use hardcoded English strings to display UI elements. These need to be replaced with internationalizable keys and translated, if possible.

[Cervator]

Cool, thanks for volunteering for this one :-)

Related: #2226, #2243, #2285, #2207, #2028, maybe #2145 - if any of those are easy to throw in feel free, but no obligation!

[rzats]

@Cervator: turning this into a Grand I18n Fix is fine by me (:
Although some of the issues you've mentioned have pending PRs open - what's the best way to handle this?

[Cervator]

I included the two PRs for that reason - they're essentially issues with attached code at this point as it seems the original authors are out of touch or time at the moment :(

I would try to merge/rebase them on top of the latest develop before/after you make some of your desired changes, maybe in a separate PR. Then adjust as needed to finalize.

If you simply merge the commits the older PRs should auto-close as merged if you make a newer PR containing the merges + your adjustments. Alternatively if they are hitting too severe conflicts at this point (mainly meaning the one that splits the .lang files some) then limited copy-paste or redo + credit in the commit message should be alright.

Edit: Looks like @msteiger has work pending on #2243 now, I see new stuff on the network graph

[flo]

@rzats thanks for this PR. I had a look at it although there isn't really much "logic" for review in it. @Cervator I will leave it up to you to merge it as you seem to have a good overview what should be merged in what order.

[Cervator]

Bit of an update here since this seems the most relevant open issue :-)

PR #2404 has been merged and updated a few drop-downs/enums to respect the translation system, introducing a new utility class.

Based on a comment by @msteiger it could still be enhanced a bit more:

I'd prefer to have two separate TextRenderer instances for the two use cases: as-is/translated. The ToStringTextRenderer could remain untouched and a new TranslatingTextRenderer could perform the translation work.

The object of this issue is very similar to that PR since it points out a bunch more UI elements currently hard coded despite translations being available (at least in some cases I think). @Margretor you had a bit more covered in your PR #2226 - want to grab latest code and add translation for a few more? Alternatively @indianajohn if you feel like a round two go for it, just comment here so we know who is working on it :-)

I noticed the screenshot sizes had been touched in #2226 and @emanuele3d has snuck in a nice new 4k entry there as well with PR #2411 so be aware and try to avoid that field until PR #2411 is merged.

_Important note:_ With PR #2404 the default.cfg needed changes to cover the new translation field names. This may also happen again with some of these fields (maybe?). When such a change is made any users with an existing config.cfg need to delete it (or adjust manually, but deleting is easier) and we should be sure to communicate that clearly to avoid issues :-)

Edit: #2285 may also be relevant to this issue if it isn't complete yet.

[Margretor]

@Cervator I will look into this in the weekend to add the missing translations.

[Margretor]

I managed to get gradle to build to project (some jar problems with the servers that provided them), as I looked into the code base, @msteiger mentioned that he wants two TextRenderer instances and I have a couple of questions.
I am not sure if I am getting this right but:

• One should display the text as it is
• The other should translate the text then display it ?
  Please correct me if I am wrong about this: I think this is a bit strange since both use cases would need to look into the specific default language file thus doing similar work.

_Also_ I have noticed that for each UIDropdown element there is a new ToStringTextRenderer attached. Wouldn't be more efficient if we had a single text for all of them? (Could concurrency be a problem?)
Based on my previous PR #2226 @msteiger mentioned that I should use a general approach towards the org.terasology.rendering.nui.layers.mainMenu.videoSettings.VideoSettingsScreen on the blur switch that now is based on numbers :smile: is this the way I should carry on, with an enum or there is another approach?

[rafajaques]

How is that going? Is it possible to translate the application?

[SkySom]

@rafajaques A lot of portions of the Terasology already support translations. You can take a look at http://translate.terasology.org/

[Cervator]

Bump - @rzats do you think we need more work on this still? During GCI we were converting more fields to add translation support, to the point where there seemingly weren't more easy fields to find. Yet I don't see any GCI related history entries for the org.terasology.rendering.nui.layers.mainMenu.inputSettings package and sure enough there are still hard coded strings in there. Do we want to convert them or are they too technical or in a spot we wouldn't want to translate?

[rzats]

@Cervator: let's not close this for now - it's _halfway_ done so we know there aren't any fundamental issues with translating some of the strings. Just need to wrap up the remaining ones - and yes it's a little surprising that no GCI student ever found this class 🙂

[Cervator]

@rzats I think I may just have mistaken some id Strings for translatable fields - I can't easily spot any now. Can you confirm and if so we can close this and retroactively assign it to Alpha 7?

@msteiger: up above I reiterated a comment from you about a possible improvement - do you think that's still valid and if so should we submit a separate issue for it so this can be closed? https://github.com/MovingBlocks/Terasology/issues/2309#issuecomment-234458013