Readiness test
Separate language, locale, region and market decisions
These dimensions often overlap but are not interchangeable. Build explicit contracts so one translated string does not silently change currency, law or service availability.
Text architecture
Keep user-facing language outside component logic and sentence fragments.
- Test
- Long, short and grammatically reordered text
- Failure
- Concatenated fragments cannot translate naturally
- Proof
- Message catalog with context
Layout and direction
Allow text expansion, wrapping and right-to-left flow.
- Test
- Long labels, zoom and RTL direction
- Failure
- Fixed widths clip critical controls
- Proof
- Responsive direction-aware components
Formats and input
Treat names, dates, numbers and addresses as locale-sensitive.
- Test
- Multiple name, date and numeric conventions
- Failure
- US-specific validation rejects valid users
- Proof
- Locale-aware display and tolerant input
Routing and discovery
Give localized content stable, explicit URLs and metadata.
- Test
- Direct link, alternate language and canonical behavior
- Failure
- Browser language creates one changing URL
- Proof
- Indexable locale routes and user switch
Content operations
Define source language, owner, review and update propagation.
- Test
- One changed product claim across locales
- Failure
- Old translation remains materially misleading
- Proof
- Status, reviewer and fallback policy
Product and support
Align availability, policy and assistance with the promised locale.
- Test
- Signup, errors, email, help and cancellation
- Failure
- Translated marketing leads to unsupported product
- Proof
- End-to-end native-language review
Operating principle
Internationalize the product before translating the strings
If code assumes English length, left-to-right direction, one address structure and one date format, translation exposes architecture defects rather than solving them.
Run a pseudo-localization and RTL test before commissioning a market launch. Then use qualified native reviewers for meaning, tone, cultural fit and complete journey coverage.
- Use UTF-8 throughout
- Declare document language
- Support text expansion and RTL
- Keep locale URLs shareable
Applied example
Readiness example: translated landing page, English recovery
A team launches a Spanish homepage and signup form. Verification email, validation errors and password recovery remain English and support cannot handle Spanish requests.
- Acquisition promised a broader product than operations provide
- Critical journey content was outside the translation inventory
- Language ownership ended at the landing page
- User trust fails after commitment
Plain answers
Questions to resolve before shipping
Should we automatically redirect by browser language?+
You may suggest a relevant locale, but preserve user choice, stable URLs and an obvious language switch rather than trapping users.
Is machine translation enough for launch?+
It can assist drafting, but consequential product, policy and support content needs qualified review for meaning and regional suitability.
Do we need right-to-left support now?+
If future RTL languages are plausible, testing logical layout early can prevent expensive direction assumptions even before translation.