Localization - challenges and opportunties

[blowfishpro]

Heard a couple of requests to be able to patch localization with ModuleManager. One was for part titles, one was for craft titles. Both were to modify them in ways based on conditions that have nothing to do with the active language. Neither are currently possible. Just for reference, here's an overview of how things currently happen:

• KSP loads all .cfg files into the game database
• Localizer is initialized, creating the localization table from the game database
• Mod plugins are loaded and initialized
• KSP reloads all .cfg files into the game database, localizing them as they are loaded
• KSP localizes the entire game database again for some reason < more stuff >
• ModuleManager patches the game database < much later >
• Craft files are parsed and localized either in the editor or in the flight scene

In order to support patching localized craft names, it would be sufficient to reload the localization table from the game database after ModuleManager runs (this can be accomplished by telling it to switch languages, even if you're switching to the already-current language).

Part names are more complicated, because they're stored in the game database. By the time ModuleManager sees them, they are already localized. The only way I can see to do it is this:

• Before patching, ModuleManager reloads all configs from disk, with localization disabled (certain ConfigNode reading methods allow it to be disabled, and some don't interact with localization)
• After patching, reload the localization table per above
• Localize the game database (call Localizer.TranslateBranch on each root node).

I don't have a sense of what the performance impact of doing the above would be, but given that KSP does the 1st and 3rd bits twice anyway, maybe it's not that much. Those steps can also be parallelized if need be.

Anyone else have thoughts on this? Would it even be valuable?

[gordonfpanam]

I'd be interested in changing the localization strings for other in-game UI text as well as for parts. For instance, references to Kerbin in error messages could get replaced with Gael or another home world name in a Kopernicus planet pack.

This doesn't seem possible based on the current order of operations. I suppose one could create a supplemental dictionary file to replace these; I've managed to do this with Kanadian Dictionary and replace the "NA" backstory strings for C7, Maxo, Kerbal Motion and Goliath, even if en-us is still the active language. This works whether Module Manager is in use or not.