Repository navigation
Localization - challenges and opportunties #118
Description
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
.cfgfiles into the game database - Localizer is initialized, creating the localization table from the game database
- Mod plugins are loaded and initialized
- KSP reloads all
.cfgfiles 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
ConfigNodereading 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.TranslateBranchon 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?
Activity
gordonfpanam commentedon May 13, 2018
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.
infradmin4KSP commentedon Jun 4, 2026
I would like to change some settings names (Main menu -> Settings) just because it can be named more clear (IMHO).
Of course I can alter \GameData\Squad\Localization\dictionary.cfg file and this approach works fine. But I have few game instances in different languages, also I experiment with mods quite often and therefore create even more instances in order not to clog up the main ones. That's why I would like to make my configuration portable and reversible as much as possible. Overwriting existing files contradicts that. So I prefer to apply all changes with MM patches.
So, if game DB is already localized when ModuleManager starts, addressing "localization" object in the patch won't work, because it was already applied (localized variables were resolved to corresponding strings), right? Please advise where can I find game DB structure to find the proper objects names (settings in particular)? Then I could address target objects themselves.