Page MenuHomePhabricator

Display localized content to readers
Open, Stalled, LowPublic

Description

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