When in Rome, speak... maybe not Italian?
summary
Regularly encountered apps serve the wrong language despite the browser preferring English, so the recommendation is to use the Accept-Language header for server-driven negotiation and fall back to a client language selector. Set per-element language with the HTML lang attribute and translate="no" to keep auto-translate from mangling labels. On Android, respect device locales, handle API 24+ language fallback, manage app-bundle splits and fetch missing packs with the Play Core split install manager, and persist user choices server-side.
AI-written summary · about
chapters (10)
- 0:00Introduction and speakers
- 1:25Frustrating localization examples
- 8:30Problems with language-location assumptions
- 14:30Understanding the locale stack
- 19:22HTTP accept language header
- 26:08Content negotiation approaches
- 33:31UI considerations for localization
- 39:52Web apps and translation tools
- 44:56Persisting language settings
- 45:58Summary and key takeaways
related talks
15mGoing global: building for a multilingual world
14mBuilding for a multilingual world
10mAndroid app internationalization: users can now choose their application language
33mFearless Localization and Internationalization Across the Nations
38mTricky Backwards-Compatible Localization
48mTips for Multilingual Support in 17 Countries
41mBuilding Android Apps for a Global Audience
27mTexts, dates, numbers, currencies, plurals, etc. App internationalization guide