awesomechecklists
llms.txtGitHub ↗
/

06 — Internationalization and Localization Checklist#

Verify that supported languages, writing systems, locales, and markets have functional and comprehensible end-to-end experiences. Internationalization makes a system adaptable; localization delivers language- and market-appropriate experiences. Translation alone is not sufficient.

Scope: Backend / API-specific. This file is one part of the 06_Internationalization_and_Localization.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

  • Project / product:
  • Release / version / environment:
  • Supported languages, scripts, locales, and markets:
  • Default locale and fallback policy:
  • Localization / translation / engineering owners:
  • Reviewer / owner:
  • Review date:
  • Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

  1. Create a project-specific copy of this reusable template; keep all repository checkboxes unchecked.
  2. Define explicitly supported languages, regions, and market obligations rather than assuming they map one-to-one. Record excluded markets or languages as out of scope.
  3. Verify checks with locale matrices, resource files, automated pseudo-localization tests, formatted-data tests, real browser/device observations, and qualified linguistic review. Record failures, accepted exceptions, evidence, and justified N/A outside the shared template keyed by I18N ID.
  4. Assess ## API Checks and ## Frontend Checks separately where applicable. Document why checks do not apply for API-only, non-UI, or single-locale products.
  5. Reassess after changing supported markets, locales, translation sources, date/currency rules, user flows, or external integrations. Coordinate regional legal, accessibility, security, and SEO compliance reviews with their dedicated checklist owners.

Language and regional requirements#

  • I18N-005 Define how initial language and locale are selected from user preferences, account settings, device settings, and request headers.

API Checks#

  • I18N-083 Accept and return Unicode text without loss or corruption across request, validation, database, and response boundaries.
  • I18N-084 Document the language and locale conventions for API inputs, outputs, errors, and localized display fields.
  • I18N-085 Use valid, consistently interpreted language tags in locale preferences and applicable resource metadata.
  • I18N-086 Define locale negotiation, fallback, and explicit override behavior where APIs provide localized messages or content.
  • I18N-087 Keep machine-readable errors and business identifiers stable across languages while supplying localized human-readable messages where relevant.
  • I18N-088 Preserve numeric precision, currency identity, units, and canonical timestamps independently of locale-specific display strings.
  • I18N-089 Specify timezone and offset semantics for all externally exchanged timestamps and date-only values.
  • I18N-090 Test ambiguous local times, daylight-saving changes, calendar boundaries, and date-only scheduling semantics as applicable.
  • I18N-091 Handle localized search, collation, comparison, and sorting consistently with documented backend behavior.
  • I18N-092 Validate names, addresses, phone numbers, and other user-entered fields without imposing inappropriate single-country ASCII patterns.
  • I18N-093 Define storage and transport size limits independently of UI character counts, considering UTF-8 byte length and grapheme clusters.
  • I18N-094 Ensure pagination and cursor ordering remain stable when locale-sensitive sorting or collation changes.
  • I18N-095 Test that API outputs and JSON serialization preserve combining marks, non-Latin characters, emoji, and mixed-script data.
  • I18N-096 Provide localized resource variants or content language metadata for content-oriented APIs where supported.
  • I18N-097 Guard against cache cross-contamination by locale, language, region, or entitlement when localized responses are cached.
  • I18N-098 Validate webhooks, exports, documents, and asynchronous jobs for multilingual payload consistency.
  • I18N-099 Include locale-relevant tests for input validation errors, rate-limit messages, and failure recovery.
  • I18N-100 Document and version changes to locale negotiation, formatting contracts, and localized enum display labels.
  • I18N-101 Ensure API telemetry can diagnose locale-specific defects without collecting unnecessary sensitive language or identity data.
  • I18N-102 Coordinate with clients on language fallback, localized content missing states, and supported regional operations.

Release gate#

  • The release has an approved matrix of supported locales, regions, relevant market-specific requirements, language selection behavior, and fallback rules.
  • Critical user journeys are verified end to end in representative supported languages and scripts, including relevant right-to-left and non-Latin scenarios.
  • Stored data and API contracts preserve Unicode text, timestamp/currency semantics, and required locale metadata without loss or unauthorized cross-locale leakage.
  • Locale formatting, names/addresses, plural forms, sorting, and input methods have passed targeted tests appropriate to the supported market mix.
  • High-impact translations (consent, payment, legal notices, safety instructions, and destructive actions where applicable) have qualified review and no unresolved misleading text.
  • Frontend labels, layout, navigation, accessibility metadata, and fallback behaviors remain usable under translation expansion and missing-resource scenarios.
  • Localization defects are tracked by locale and severity with accountable owners, retest evidence, and approval for any remaining exceptions.

Domain-specific approval rule: Block localization sign-off if a supported-market critical journey is unusable, payments/amounts or times are materially misrepresented, data is corrupted, or high-impact language/region requirements are misleading or unreviewed. A language being selectable is not evidence that it is ready for release.

Trusted references and scope#

The following authoritative standards and guidance support these project-level review questions. Some are normative technical specifications; others are practical guidance and must not be treated as universal legal requirements.

Applicability: Locale data and display conventions evolve. Unicode CLDR 49 was current at the November 2026 review, but applications must validate the library/runtime versions they actually ship. BCP 47 language tags do not encode all legal, currency, market, or user-preference requirements. RTL support, public search annotations, alternative calendars, and multi-language translation workflows are conditional on the product's supported audience and interfaces. Detailed WCAG conformance, SEO, and jurisdictional requirements belong in their dedicated checklists.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

  • Test focus: plural rules, locale formatting, missing strings, RTL, and long-text layouts; include API and service behavior where applicable.
  • Cross-stack: Playwright.
  • Python: Babel + pytest; for pytest-based suites, run python -m pytest -q.
  • TypeScript: FormatJS + Playwright + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
  • JavaScript: i18next + Playwright + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
  • Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

  • internationalization — Audit locales, hreflang, RTL, and formatting (rampstackco/claude-skills, 1,063 repo stars).
  • i18n-expert — Inspect translation-key coverage and plural rules for supported frameworks (daymade/claude-code-skills, 1,524 repo stars).
  • webapp-testing — Exercise language switching and localized UI (anthropics/skills, 193,495 repo stars).

How to check: In a project-specific copy, have the agent audit the backend / API scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.

Reference, not a certification. Check applicability, verify important claims against current primary sources, and seek expert review where necessary. Suggest an improvement.