Practice English vocabulary for locale content negotiation: Accept-Language headers, server matching, fallback chains, untranslated string fallback, and locale detection order.
0 / 5 completed
1 / 5
What does 'the Accept-Language header requests the preferred locale' mean?
The HTTP Accept-Language header is automatically sent by browsers based on the user's language settings. It lists preferred locales with quality weights (q values). Servers use this to select the best matching language for the response.
2 / 5
What does 'the server returns the best matching locale' mean?
Locale negotiation uses BCP 47 lookup algorithms. If the user requests 'pt-BR' and only 'pt' is available, the server falls back to 'pt'. If nothing matches, the server falls back to the default locale (usually English).
3 / 5
What is a 'fallback language when translation is missing'?
Fallback languages ensure the app remains functional even with incomplete translations. A common pattern: try the full locale (fr-BE), then the language (fr), then the default (en). This prevents users from seeing raw translation keys like 'homepage.hero.title'.
4 / 5
What does 'the app falls back to English for untranslated strings' mean?
Granular fallback means only the missing strings fall back to English, not the whole interface. This is a common strategy during phased rollout of new locales — shipping a partially translated locale is acceptable if untranslated strings gracefully fall back.
5 / 5
What is 'locale detection order (URL > cookie > browser)' in an i18n app?
Locale detection follows a priority order: URL (/fr/ or fr.site.com) is most explicit and should always win. A locale cookie stores the user's explicit choice. The Accept-Language header provides the browser default. This order respects explicit user preferences over inferred ones.