[CHORE] Change translation JSON format (Easy but lot of changes)

[Zagrios]

Problem

At the beginning of the project, we chose this format for translations:

"search-bar": {
    "search-placeholder": "Search a map",
    "filters-btn": "Filters",
    "dropdown": {
        "export-maps": "Export maps",
        "delete-maps": "Delete maps",
        "delete-duplicate-maps": "Delete duplicates"
    }
},

So a translation key would be search-bar.dropdown.export-maps

This was a bad choice. This format introduces a lot of duplication, makes it time-consuming to find the right place to add new translations, and complicates inferring the correct translation key to use in React components. Additionally, it increases the risk of using invalid translation keys.

Solution

We need to switch to this format for translations:

"Search a map": "Search a map",
"Filters": "Filters",
"Export maps": "Export maps"
"Delete maps": "Delete maps"
"Delete duplicates": "Delete duplicates"

(For the English translation, keys and values will almost always be the same)

With this format, there's no need to figure out where to place new translations : just add them at the end. All duplicated translations will be merged into a single translation key. We can infer a Translatable type directly from the translation file:

And any invalid translation key will be handled by TypeScript:

[AltyFox]

Certainly doesn't look nearly as pretty, but certainly does make it easier

[silentrald]

@Zagrios would it be better to move out of JSON files as well? A file format that supports commenting when being parsed like cfg so we devs can still see what text are used in what screen to have some ideas on the translation.

# Home / Index Screen
Some text here=Some text here

# Mods Screen
Unselect mods=Unselect mods
Delete all mods=Delete all mods

The refactor shouldn't be hard though, we could create node or python script to convert them to thing we want. And do some search and replace within the the ts files.

[Zagrios]

@silentrald Yeah, but TypeScript won't be able to infer a type from it...
I really want a type inferred directly from the translations; I mean, look at that, isn't that cool? 😅

And I'm not sure comments would be that useful 🤔
A translation like Install a mod obviously belongs in the mod panel, and terms like Description or Install are general-purpose, so no need to put them under a # Global comment idk.

Yeah, most of the migration can be done by a script. Actually, I started the migration a few months ago using a Rust script, but I stopped it (v1.5 was more important 😅) and unfortunately didn't save my work 💀 x)

[silentrald]

@Zagrios yeah, infered types are really nice to have so I'm ok with the original change in that case 👌

[silentrald]

@Zagrios might take this article into account though when changing the translation framework: https://dev.to/spyke/localization-keys-vs-direct-text-keys-5i

There are also some links within that article that also discusses drawbacks on this approach ie.

• Install a mod changed to Install a mod. -> all of the translation on other locales will be affected.
• Same English text, different context. Like the verb or noun "map".

Might create more problems/issues in the future imo, but wdyt?