Page MenuHomePhabricator

Display localized content to readers
Open, Stalled, LowPublic


Event Timeline

Aklapper changed the task status from Open to Stalled.Jul 22 2021, 3:44 PM
Aklapper triaged this task as Low priority.
Aklapper created this task.
Aklapper renamed this task from Sort out displaying (non-English) translated content version to Display (non-English) translated content version in viewer's browser.Jul 27 2021, 4:24 PM
Aklapper renamed this task from Display (non-English) translated content version in viewer's browser to Display localized content to readers.Sep 7 2021, 4:36 PM

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,,, 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.