- Accept-Language request HTTP header? - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language
- Dedicated language switch / dropdown UI element? (more maintenance work; adding languages etc?)
|Stalled||None||T265018 Update redirect target of dev.wikimedia.org to Developer Portal|
|Stalled||None||T265019 Update several on-wiki link targets for "Developer" links|
|Stalled||None||T286568 Communicate launch|
|Stalled||None||T261510 MVP Launch|
|Open||None||T290258 Workflow(s) how users experience content|
|Stalled||None||T287176 Display localized content to readers|
|Open||None||T290256 Workflow for translators how to translate content|
|Stalled||None||T276700 Content localization infrastructure setup (export, import, deploy)|
|Open||None||T276708 Define content storage format (levels, data structure, hierarchy, categorization, etc)|
|In Progress||bd808||T297168 Write localization/internationalization mkdocs plugin|
|Resolved||Spike||bd808||T295832 Evaluate improving/replacing mkdocs-mdpo-plugin to better support TWN integration|
Language code and webservers: If we go for static (!) side generation, then we'd either end up with the language code as part of the URL, or we'd need a webserver which can hide that fact.
Users changing language: If this was part of the URL, would it be needed to switch the language? If yes, how? Some dropdown (additional development costs)?
Storage of served localized content: Depending on how we store all the content entries (see T276708: Define content storage format (levels, data structure, hierarchy, categorization, etc), we may have a directory full of files (each file being one content entry), then aggregate template files for an entry, then generate files for each language (entry.cs, entry.de, entry.es, etc).
Fallbacks for unlocalized strings: We'd need a fallback lookup (English?) for each piece of content. For simplicity, this fallback should be English language.
Potential custom fallback chains/cascades (like zh-hans to zh-hant) are post-MVP and need further investigation.
Language coverage thresholds: If it was URL based, would we generate pages for each of the dozens or hundreds of languages? Ideally I'd like a threshold (e.g. 50% of strings translated to a language) before generating pages with only three translated strings.