In the future, both stable and unstable branch will have the ability to subscribe from the Steam Workshop. So there’s a question, how to provide correct translations for the correct branch?
For now, I can only imagine there will be 2 localization mods, one for stable, and one for unstable. And to better handle other mods’ translations, there will a 3rd mod.
So here we go:
- Mod 1: translations for stable branch.
- Mod 2: translations for unstable branch.
- Mod 3: translations for other awesome mods
Is there any better way to handle this situation?
Why not just one file with most recent update? The player in the most recent version will have all necessary strings, the one not on the recent version will also have all the necessary strings plus extra strings that he does not need yet.
Your current translations files can easily be used in older versions without a problem. The game will simple ignore the new strings that are aimed to the new versions.
Good point. But the problem is, as I remembered, the team did delete some strings and modified the structure with the updates. And I suppose it will keep happening in the future. Under this situation, if I kept the old strings, it will just increase the difficulty to maintain the mod.
I don’t think they delete strings anymore. Unused strings can simple be ignored in the file, and just keep adding the new ones. There are so many things in the locales that are not used anymore.
If you have to decide, I guess, target the stable version, that is where the majority of players are. Unstables are for tests only anyway.
This is a “temporary” issue that is affecting all mods, and like Bruno said, I think translations are the ones that get off the hook the easiest.
On one hand, it’s temporary in the sense that once there’s no unstables anymore (but rather just pushes to the stable branch/very short betas where mods would likely not work anyway), it’s not required to have a special system in place.
On the other, this might take some time and could be a deal breaker for mods.
Personally, I think a possible and quite good way to fix it would be to
- allow multiple manifest.jsons
- allow specifying a min and max game version in the manifest.jsons
- have the game load the one manifest that matches the version range
That way, you could have an e.g. manifest_23unstable.json, a manifest_22.json and a manifest_24.json. Using clever requires, mixintos and other shenanigans you could easily share resources between the manifests that are the same, and then have specific includes/excludes for content based on the game version.
You are right, it’s a temporary issue for sure. I guess, for now, I will take @BrunoSupremo’s advice, target the stable version for workshop. And perhaps update the unstable one on the discourse.