Localization roadmap

[coppolaemilio]

Now that the initial localization system has been implemented with bf79f99 there are some tasks to consider so I'll open this issue to discuss it and to keep the roadmap somewhere.

Todo:

• Make the language selector accessible via the keyboard (right now it is just skipped)
• Recognize browser language to automatically redirect users to their language if available
• Save a cookie for what language preference
• Redirect user when they visit a page that's available in their preferred language. This should overwrite the automatic redirects from recognizing the browser in the previous point.
• Add a way to localize blogposts (not all blogposts will be localized, but for big releases we could and I'm sure the community will want to contribute to this)
• Write the information in the readme.md about how to translate the site
• Figure out a better system to handle updates of source strings and propagating to translation catalogs, e.g. with gettext POT/PO files (see Localization roadmap #1017 (comment))

[Calinou]

I noticed static pages other than the homepage (such as Features) can't be localized yet. I can look into implementing this if you'd like 🙂

[coppolaemilio]

Sure, give it a go!

[akien-mga]

With more languages being added, and as we eventually revise copy for translated strings, you'll soon see why hardcoding translations for keys like this quickly becomes a nightmare. We'll need to ask translators to provide new translations in the PR that modifies the English strings, or we'll need to come up with a system to track modified strings that require translation updates.

That's a solved problem with gettext and POT (template) and PO (translation) files as we use for the engine and the docs. So ideally we'd add support for that in the translation plugin, so we can extract all templates to a website.pot, and then language translations in es.po, fr.po, etc.

When updating the .pot file, gettext then automatically updates the .po files accordingly, marking modified strings as "fuzzy", so translators still have their old translation for it (if fuzzy matching works) but need to rework it before it's used live.

For the Godot editor we have some Python scripts that generate .pot files based on parsing source code (editor C++ code, or class ref XML) to extract strings: https://github.com/godotengine/godot-editor-l10n/tree/main/scripts

But here there are probably more clever ways to do this, I'm sure there are some web-friendly libraries to extract strings that are meant to be translated (with some template markup) and generate a POT file.

[Calinou]

I noticed we're using language-specific URLs too. While this is technically the more "web-y" way of proceeding, it often leads to poor UX due to users copy-pasting localized URLs on platforms like Discord or forums. This means users will see pages in the incorrect language if their system language isn't used to switch to the correct language (as opposed to English). If the system langauge is used, the language code in the URL just ends up being cruft.

In comparison, websites like Lichess have dropped language codes from their URLs a few years ago, making the language a client-side detail so to speak.