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.