- 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?)
|Resolved||Aklapper||T265018 Update redirect target of dev.wikimedia.org to Developer Portal|
|Resolved||Aklapper||T265019 Update several on-wiki link targets for "Developers" links (sidebars, footer, pages)|
|Resolved||Aklapper||T286568 Communicate launch|
|Resolved||Aklapper||T302809 Add dev portal to list of microsites on doc.wikimedia.org|
|Open||None||T299923 Update Zulip's welcomebot message and GSoC organization contact to point to dev portal|
|Resolved||Aklapper||T287030 Update or remove meta:Wikimedia_Resource_Center/For_developers|
|Resolved||Aklapper||T265017 Once developer.wikimedia.org is up, make https://www.mediawiki.org/wiki/API:Web_APIs_hub redirect to it|
|Resolved||Aklapper||T261510 Launch MVP of Developer Portal on https://developer.wikimedia.org/|
|Resolved||None||T290258 Workflow(s) how users experience content|
|Resolved||None||T287176 Display localized content to readers|
- Mentioned In
- T287501: Check RTL support on the developer portal
T290258: Workflow(s) how users experience content
T276708: Define content storage format (levels, data structure, hierarchy, categorization, etc)
- Mentioned Here
- T276708: Define content storage format (levels, data structure, hierarchy, categorization, etc)
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.
We went for a dedicated language switch / dropdown UI element.
That also means that sending accept-language: es does not automatically display the content in Spanish. If this was wanted, a separate enhancement request can be filed.
Resolving this task as displaying localized content to readers is implemented.