[Feature] Implement internazionalization for Decky Loader

[RodoMa92]

As promised, this is my prototype for translating this awesome piece of software.

For translating the codebase, I've chosen i18next as a framework.

Whats seems to work fine:

1. Backend serves json files corresponding to the Steam user language selected plus a fallback to english by default
2. Frontend had all strings replaced with the corresponding t() call (see below for details) in order to dynamically update the text in the UI.
3. English and Italian complete translation are already provided, although I will probably tweak it again as soon as I begin to test a lot more of the UI
4. Strings are automatically extracted using the action extracttext from vscode. This will scan the codebase, search for t() calls and fill automatically the json translation files with empty values (can be set to whatever we want).
5. AFAICS settings UI seems already to works perfectly fine.

Possible pitfalls left in this:

1. I have seen a lot of https://reactjs.org/docs/error-decoder.html/?invariant=321 in the console of chromium while debugging the backend, I might still have left some boobytraps around the codebase, I still need to actually check if they are still there and if they actually are an issue. UPDATE: This is caused by some components missing react hooks inside them (I think), for now I should have disabled the small translation stuff caused by this, and it's working fine now (but not translated). If someone wants to take a stab at it at fixing them, I left the translated part commented out here.
2. The whole codebase still needs to be heavily tested.

Information to the devs in order to translate text:

1. First you need to import the main function from i18next:
   import { useTranslation } from 'react-i18next';

2. After that you need to create a hook inside the corresponding react function like this:
   const { t } = useTranslation();

3. This will give you the function t that you can use inside react components in order to resolve text like this:
   t('ClassName.corresponding_string'). The first parameter is the identifier for resolving the desired text.

i18next have quite a lot of options for adapting to various languages, that can be specified after the string identifier. I recommend translators to go read the documentation, it's quite succinct and complete in that regard.

4. Once all parameters have been added to the file, run extracttext. This will parse the codebase and fill up all json files automatically.

If you want to add support for an additional missing language to the codebase, the steps are the following:

1. Add your language identifier (ex: en-US for american english, it-IT for italian, etc.) in the array at row 47 in the file called i18next-parser.config.mjs.

2. Run the activity extracttext in visual studio code. This will parse automatically the codebase and generate a corresponding json file in <root_codebase>/backend/locales for your languages, all with parameters set to MISSING (also configurable on demand).

3. If you can't translate everything, remember to remove the parts of the JSON not translated, in order to allow i18next to fallback to the default english language. Otherwise the UI in that specific language will look full of MISSING everywhere. This is the reason I've dropped the empty language files in the latest commits, to avoid any confusion. If anyone wants to translate it further, you just need to run extracttext again to get all the non translated strings back in the file. Not necessary anymore.

[RodoMa92]

I should have fixed everything, let me know if I have missed something.

[AAGaming00]

I feel like there may be a better way to handle translation in the modals to allow for usage of useTranslation, which I'll look into before merging this

[AAGaming00]

If you can't translate everything, remember to remove the parts of the JSON not translated.

Is there a way to automate this?

[RodoMa92]

If you can't translate everything, remember to remove the parts of the JSON not translated.

Is there a way to automate this?

In theory you can pass a function to default value that should allow to disable the output if needed.
// You may also specify a function accepting the locale, namespace, key, and value as arguments

I do not know however how this would be handled internally. Haven't looked that far.

EDIT: Few examples in tests: https://github.com/i18next/i18next-parser/blob/7289d29bbeae6a153738c0b6a1b2d7f2494b245c/test/parser.test.js#L1089

[RodoMa92]

Ok, found a way if we leave the default of the untranslated strings as blank strings:
https://www.i18next.com/principles/fallback#missing-values-for-existing-keys

[RodoMa92]

Just tested and can confirm it works, so now we can export languages even with empty strings.

[RodoMa92]

I feel like there may be a better way to handle translation in the modals to allow for usage of useTranslation, which I'll look into before merging this

A few pointers for you:
The only feasible way that I found to change the message programmatically in i18next is to use the count property. There are two ways of doing this:

• Native count: This is not deterministic, unfortunately (each language might have different ways to enumerate. Some gives a lot of them, other only two). It's not really useful in this case.
• Using a first party extension link: This allows exactly what we want (we can specify a defined interval and the associating text for each language freely), however I couldn't get to cooperate with the parser, and the defined strings would be seen as not used and removed each time I would run the parser. It's probably possible to coax the parser by specifying additional options to it (probably in i18nextOptions), but I didn't explore this further personally. This is probably the easiest route.
• Maybe a third party postprocessor? Still, similar issue as above.

Regarding the toaster, I've tried to inject the property in it to no avail, but since this is a interface to plugins, and not only internally to Decky, I'll prefer to leave this to someone who knows the code better than me.

Otherwise this branch has been merged again with the latest master.

[PartyWumpus]

This looks good to merge, I've been using this for a while without issue, and Train's been testing it over the weekend. Will merge (and publish a prerelease with it) if you think it's ready.

[RodoMa92]

Besides the two things above (the not ideal modal translation selection and the notifications not translated yet, but already integrated in the translation system) I do not see any other missing features or bugs left in this branch. In my opinion it's ready to merge.