i18n: Translate the website (excluding blogs)

[danielhjacobs]

Fixes #110

Screencast.from.2024-11-21.15-34-34.online-video-cutter.com.mp4

[danielhjacobs]

martinkr/next-export-i18n#78

[danielhjacobs]

Switched to my own logic for translations.

[danielhjacobs]

Going to mark this PR ready for review. The only untranslated content are blogs 2-5, and they can be translated later if we decide translating blogs is something we want to do. Due to the logic of the code, blogs without {{...}} strings remain untranslated. I did add translations for the blog titles for blogs 2 to 5. Even if I didn't, the translation function would look for the title as a key in the JSON file, not find it, and fall back to the title itself.

[danielhjacobs]

https://github.com/ruffle-rs/ruffle-rs.github.io/blob/253b15cf54fd28b7ec3600fda94b4330fa1b6625/src/i18n/translations.en.json will need to be added to Crowdin.

[danielhjacobs]

This hard-coded list of languages and language codes should exactly match the extensions for the JSON language files we add.

Due to the way the logic is, it's probably best we use shorter codes whenever possible, so we may want to change:

"es-ES" to "es"
"sv-SE" to "sv"
"pt-PT" to "pt"
"zh-CN" to "zh"

[torokati44]

Do you think it would be possible to keep the original (English) text in the sources?

The translations could still be looked up using some sort of ID (potentially auto-generated, or manually disambiguated where necessary), you would just have to do a "reverse lookup" first to get the ID.

Similar to how it works in Qt: https://doc.qt.io/qt-5/i18n-source-translation.html#using-tr-for-all-literal-text

[torokati44]

The reason I think this would be preferred here is that the website is "text first, with some markup and logic sprinkled in", vs. the main Rust code, where it's "code first, which happens to present some text from time to time".

[danielhjacobs]

Do you think it would be possible to keep the original (English) text in the sources?

The translations could still be looked up using some sort of ID (potentially auto-generated, or manually disambiguated where necessary), you would just have to do a "reverse lookup" first to get the ID.

Similar to how it works in Qt: https://doc.qt.io/qt-5/i18n-source-translation.html#using-tr-for-all-literal-text

I'm a bit confused on the idea here in terms of Crowdin/bot integration. Are you suggesting something a bit like what the Desktop in/xml files do, where the .in files generate the .xml files? I'm not sure how the tsx files would generate the JSON file.

Basically I'm just asking what file(s) would https://crowdin.com/project/ruffle/es-ES track? If the strings stay in the tsx, we wouldn't want to duplicate them in a JSON file manually, and I'm not sure how we'd automate the JSON file creation. I don't know if Crowdin can directly track and translate based on tsx.

I think I'd prefer the t() function take both the English string and the id as parameters if we wanted to keep the strings in the tsx file, but the question is how Crowdin would work with this.