Internationalisation
Locale, direction, pluralisation and dates as structural concerns, not string tables.
5 to work through
-
intermediate
09:10 a release adds Portuguese for Angola. 09:40 support in Luanda reports prices shown in Brazilian reais with Brazilian tax wording. 10:05 one page shows English legal copy inside an otherwise Portuguese flow. No pricing or tax code changed in the release and every response is HTTP 200. What failed and which design decision allowed it?
2 min answer -
intermediate
A learning platform must support many languages including ones with different scripts and text directions. What must be architectural rather than cosmetic?
2 min answer -
intermediate
A release goes out and checkout fails for users in one market only - Turkey. The code path is identical for everyone and no market-specific logic was changed. The error is a failed comparison against a string constant. What happened?
3 min answer -
intermediate
What must be designed for internationalisation on day one, and what can genuinely wait?
2 min answer -
advanced
A commerce platform expands across markets with different languages, scripts, currencies and layout directions. What breaks that teams do not anticipate?
1 min answer
4 terms in this topic
Internationalisation
Designing so that language, region and culture are parameters rather than assumptions — cheap upfront and very expensive to retrofit.
practiceLocale Aware Formatting
Rendering dates, numbers, currencies and names according to the user's locale rather than the developer's, using the platform rather than hand-writte…
patternLocale Fallback Chain
The declared order in which a system degrades from a requested locale to one it can actually serve - and the decision about which values are allowed …
practicePseudo-Locale Testing
Rendering the interface with algorithmically transformed strings - lengthened, accented, direction-reversed - to expose internationalisation defects …
Neighbouring topics
Frontend & Experience Architecture
General material on architecting the surface the user actually touches.
Rendering Strategies
Client, server, static and incremental rendering, and what each costs on first paint.
Edge Rendering
Running the render close to the user, and the personalisation and cache trade it implies.
Hydration Cost
The gap between visible and interactive, and the JavaScript that closes it.
Micro-Frontends
Independent deployment of UI slices, and the shared runtime that undermines it.
Module Federation
Loading code from another build at runtime, with versioning and failure to think about.
UI Monorepo Strategy
One repository for many front ends, and the build graph that makes it viable.
Design Systems
Components as a versioned internal product, with adoption and deprecation like any API.
Component Contracts
Props, slots and events as an interface, and the breaking change hidden in a style.
Client State Architecture
Server state, UI state and derived state, and why conflating them causes most bugs.
Client Caching & Data Layer
Stale-while-revalidate, invalidation and optimistic updates on the client.
BFF for Experience
One backend per experience, shaped by the screen rather than by the domain.
API Shapes for UI
REST, GraphQL and RPC judged by over-fetching, round trips and client coupling.
Web Performance Budgets
A number a build can fail against, rather than a performance sprint once a year.
Core Web Vitals
LCP, INP and CLS — what they measure, and the architecture that moves them.
Accessibility Architecture
Semantics, focus management and announcements designed in rather than audited in.
Client Feature Flags
Flag evaluation on a device you do not control, and the flicker and staleness it brings.
Real User Monitoring
Field data from real devices and networks, against the synthetic run that looked fine.
Frontend Security
CSP, XSS, CSRF, token storage, and the trust boundary that ends at the browser.