Unified locales

[LotP1]

Use 1 locales file instead of individual files for each langauge.
This makes it easier to keep track of what is missing.
The PR will automatically fix missing locales and throw an error if anything is incorrect, by running the emulator. That way the person adding a new locale or new language can just run the emulator once to populate all the fields, so they can easily begin translating.

[github-actions]

Download the artifacts for this pull request:

• ryujinx-Release-1.2.0+c830f50-linux_arm64
• ryujinx-Release-1.2.0+c830f50-linux_arm64-AppImage
• ryujinx-Release-1.2.0+c830f50-linux_x64
• ryujinx-Release-1.2.0+c830f50-linux_x64-AppImage
• ryujinx-Release-1.2.0+c830f50-macos_universal
• ryujinx-Release-1.2.0+c830f50-win_x64

GUI-less

• nogui-ryujinx-Release-1.2.0+c830f50-linux_arm64
• nogui-ryujinx-Release-1.2.0+c830f50-linux_x64
• nogui-ryujinx-Release-1.2.0+c830f50-macos_universal
• nogui-ryujinx-Release-1.2.0+c830f50-win_x64

Only for Developers

• ryujinx-Debug-1.2.0+c830f50-linux_arm64
• ryujinx-Debug-1.2.0+c830f50-linux_arm64-AppImage
• nogui-ryujinx-Debug-1.2.0+c830f50-linux_arm64
• ryujinx-Debug-1.2.0+c830f50-linux_x64
• ryujinx-Debug-1.2.0+c830f50-linux_x64-AppImage
• nogui-ryujinx-Debug-1.2.0+c830f50-linux_x64
• ryujinx-Debug-1.2.0+c830f50-macos_universal
• nogui-ryujinx-Debug-1.2.0+c830f50-macos_universal
• ryujinx-Debug-1.2.0+c830f50-win_x64
• nogui-ryujinx-Debug-1.2.0+c830f50-win_x64

[Fs00]

As a translator, I don't see how this can be considered an improvement over the previous way of storing translations.

The previous JSON format used a well-established convention which is understood by several tools for editing and managing translations. The custom format introduced in this PR leaves translators with no choice but to edit the JSON file directly, which is inefficient and error-prone (need to manually deal with newlines, escaping quotes, etc.).

The advantage of making it easier to keep track of missing strings can already be achieved by directing people to use a translation editor (such as Poedit or even a simple web-based one like this). These tools typically present all strings in a tabular format which makes it very easy to see "blank spots" where the translation is missing.

Furthermore, having strings belonging to different languages close to each other makes merge conflicts more likely to happen and IMO doesn't help with cognitive overhead when working on such a large file.

I do hope this gets reconsidered.

[LotP1]

This was originally done since we're using community translators and I wanted to ease the work of getting the correct translations by giving translators more context from other languages.
We also had problems with devs adding new locales only to en_US, or to only a set of the languages, which caused issues. And it's also easier to reset locales if that is necessary when ui elements get updated.
#444 should address the issue of tracking errors in the file. It will throw better errors when the file uses incorrect line endings, is missing fields or has duplicate fields. It will also fix missing or duplicate fields and incorrect line endings if you use a local build.

[Fs00]

I see your point, but these problems stem from the fact that translators edit the JSON file(s) directly, which is not what they should be supposed to do.

Why not set up Crowdin (or another translation platform)? That way, translators won't have to deal with JSONs because they will be automatically updated by the translation platform.
Even if you don't want to set up a platform, guiding people to use a translation editor will prevent many common issues and the validation step in the CI can catch the rest.

The biggest problem I have with this PR is that the custom JSON format prevents translators from using the proper tools to do their job, be it a local editor like Poedit or a translation platform.

[rrondo]

It’s truly much more easy and user-friendly to translate now, as you can instantly access examples from other languages. Thanks!