'GNU gettext' as basis for translation into different languages

[GermanAizek]

@ad044, @elliotcraft79 Why do you not use a long-used standard for writing international applications that uses .pot (Portable Object Template) and .po (Portable Object) Reference here: https://en.wikipedia.org/wiki/Gettext#Translating

[ghost]

This solution would rise many problems that don't necessarily need to be this overcomplicated.

• gettext doesn't support grammatical gender.
• it would require a major rewrite of every string on the website, not just the game.
• integrating gettext would be a pain, by default it generates a separate build of the game, while we plan to have only one, with subtitles getting switched.
• this way, game sprites would still remain untranslatable.

Personally I prefer the current option which is just translating .vtt's and just changing them on the fly, since its more resource efficient while the game is adapted for web browsers.

[2-3]

The current way of doing things might not be perfect and going by absolute best practices for i8n. But it's simple and works very well for our case. I agree with @lelenium that using gettext would introduce unneeded complexity. It also would take quite a lot of effort and development time which is frankly better spent elsewhere.

As I see it: If we get to a point where our current implementation leads to impactful problems -- whether they be in UX or development -- then we should consider using GNU gettext or similar. But until then we gain nothing from it. And I doubt we'll ever get there, seeing how complete the game is at this point.

[ghost]

There is an option for more localized strings, for example the front page could be localized using a json file perhaps. Gettext would still feel unnecessary in that situation unless there's a framework for it, but that would still be an additional dependency.

Another example would be the keywords attached to a certain audio recording. Those technically could be stored as gettext, but more space and bandwidth efficient would be just another json file with them (that would also made it easy to parse through crowdin)