Lobby translation

[Anarchid]

Currently the lobby is not translatable at all. This is a sad state because the lobby is the first thing that the player sees. Additionally, not having a language selector in lobby is super counterintuitive. Very few users realise that the small flag icon ingame controls translation.

These things are needed for it to become open to translation:

• Add language selection UI option - somewhere in here, perhaps.

• On change, the option should immediately switch the language for menu and, ideally, the game.

• Find all untranslated texts in Chobby and replace them with i18n calls. For example, "Keep these settings?" should become i18n("keep_these_settings").

• Find all i18n-wrapped strings, and compile them into a single json file for chobby that can be uploaded to Transifex as a source json file. This could be a start (just split out the english strings from the german ones and into a separate file)

• Make the language files load separately/automatically (see here and figure out what is this supposed to do).

• Convert lua tables into keyvaluejson format.

[Legomenon-gh]

As I mentioned in #zkdev, I'm working on implementing i18n for gui_settings_window.lua and will ask for feedback once I've got something working functional. Please ping me if you're also working on this so I don't step on anybody's toes!

[Legomenon-gh]

Swapping strings in on language change is a bit more annoying than I expected... I got the lobby settings functional using a similar pattern to what the game does based on @sprunk's advice but there's some boilerplate involved.

I'd appreciate if somebody could have a look at Legomenon-gh@cfabc52 and verify if it's a sane approach before I carry on further (if nothing else, this was a pretty good exercise in figuring out how the lobby works but hopefully my code can be made useful too!)

[GoogleFrog]

Writing a version of local function languageChanged() inside every widget does not look sane to me. Writing a custom update function for all the elements of the UI will take a while and require a lot of attention to detail in each instance, since you need to implement checks for all the various states that the UI could be in. Requiring new widgets to implement a custom languagedChanged function alongside is also a hurdle to new development.

I have not looked at what the ZK game does to get around this. My recollection is that it ignores the problem and hopes/asks users to luaUI reload.

I think the solution should be within chili, as it already knows the structure of the UI and deals with updates.

• Give chili a language parameter. Perhaps it can just be a property of screen0 or a WG. Maybe a chili function. I don't know exactly where it would most make sense.
• Give controls a parameter that means "text translation key" or "label translation key". Controls that display text or labels should set those texts or labels to be the key.
• Make an event that updates the language of a control and its children.
• Make an OnLanguageChanged function that lets the widget author update the language for more complex cases, such as when a control text is the concatenation of a fixed string and a number.

[sprunk]

A potential task with this approach would be to see if there are any strings which are not Chili controls but which still need translations (which would keep the local function languageChanged() approach necessary). Ingame we do it manually because there are strings for things like chat messages or labels which are not Chili objects.

[Anarchid]

I have not looked at what the ZK game does to get around this. My recollection is that it ignores the problem and hopes/asks users to luaUI reload.

ZK the game swaps languages on the fly, using the languageChanged approach.

The recursive control-based solution does sound more elegant, though.

[Legomenon-gh]

I was focusing on the details of revamping i18n in a single widget to see if I wasn't missing anything and my general string organization was workable, so I didn't cover multiple widgets yet (I'll implement that now and apply it to a second small widget).

@GoogleFrog's solution matches what I had in mind for the most common case. I'm passing caption/tooltipKeys to the basic controls already, so it's easy to have them handle calling WG.Translate instead of the widget. languageChanged will still be needed for manual string concatenation (like the default taskbar tooltip) but hopefully I can minimize how often special handling is needed since the lobby doesn't need to do that as much as the game itself.

Thanks for the feedback, and let me know if you have any more suggestions (especially on the i18n details)!

[sprunk]

A thing to keep in mind with the Chili control OnLanguageChanged approach: controls can be hidden and thus not children of screen0 (even indirectly) which makes them unreachable from the basic Chili hierarchy. Possibly this event should also be fired when a child is being added to a control since that's how things get added to the hierarchy, which has the added bonus of automatically taking care of initializing things the first time a control is added.

[GoogleFrog]

Yes. For adding children to the hierarchy perhaps every control should have a current language variable. If the variable does not match its new parent then it should do language changed for it and its children.

[Legomenon-gh]

I'm not working on this ticket anymore for now, I might pick it back up later but no promises, so feel free to take it up

[sprunk]

Got any WIP commits to push?

[Anarchid]

There's the one linked earlier; looks like a decent start. Legomenon-gh@cfabc52

[GoogleFrog]

Making language change require a restart actually would not be too bad, provided a popup was written that told people this.

[Anarchid]

Notably, Recoil has absolved us of the fontconfig problem (at least on Windows, it might be conversely broken on Linux now instead).