awesomechecklists
llms.txtGitHub ↗
/

04 — 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: Shared / cross-cutting. This file is one part of the 04_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-001 List supported languages, scripts, regions, locales, and launch markets with a named owner for each supported experience.
  • I18N-002 Define language support independently from country, region, currency, and legal-market eligibility.
  • I18N-003 Use interoperable BCP 47 language tags for interfaces and content, including script or region subtags only where needed.
  • I18N-004 Document the default locale and explicit fallback chain for unsupported or incomplete translations.
  • I18N-006 Allow users to override automatically selected language without unnecessarily changing their account, location, or region.
  • I18N-007 Persist explicit language choices across sessions and devices where appropriate and authorized.
  • I18N-008 Describe how localized URLs, deep links, language-switching links, and redirects preserve the user's intended content.
  • I18N-009 Define availability when a feature, help resource, or legal document is not supported in the selected language.
  • I18N-010 Document which currencies, calendars, numbering systems, measurement systems, and time zones each product supports.
  • I18N-011 Identify markets requiring different pricing, taxes, payment methods, address fields, disclosures, or customer-support processes.
  • I18N-012 Specify the localization policy for customer-entered content, including whether it must remain in its original language.
  • I18N-013 Define behavior for mixed-language records and content containing multiple scripts.
  • I18N-014 Distinguish translation, transliteration, locale formatting, and cultural adaptation in requirements and review ownership.
  • I18N-015 Identify audiences with low literacy, multilingual needs, or assistive-technology requirements during market research.
  • I18N-016 Define the expected consistency of localization across web, mobile, transactional emails, documents, and support channels.
  • I18N-017 Document whether regional or language changes affect data storage, legal terms, service availability, or account eligibility.
  • I18N-018 Decide which data should be stored in locale-neutral form, such as timestamps, money amounts with currency, and identifiers.
  • I18N-019 Track rollout readiness for each supported locale separately rather than inferring readiness from the source language.
  • I18N-020 Reassess supported locale requirements after expanding to new markets, changing regional regulations, or adding major workflows.

Internationalized design#

  • I18N-022 Use stable, descriptive message keys and provide context for translators where wording could be ambiguous.
  • I18N-023 Avoid constructing sentences by concatenating independently translated fragments with fixed grammatical order.
  • I18N-024 Support variable placement, gender-sensitive wording, and cardinal/ordinal plural categories through an appropriate message formatting system.
  • I18N-025 Use locale-aware number, currency, unit, relative time, and date formatting rather than manually assembling locale-specific strings.
  • I18N-026 Separate stored values from presentation formatting to prevent localized display strings becoming authoritative application data.
  • I18N-027 Use Unicode-compatible encoding end to end, and declare UTF-8 or the appropriate Unicode encoding at system boundaries.
  • I18N-028 Preserve combining characters, emoji sequences, and scripts during input, validation, truncation, storage, and display.
  • I18N-029 Use Unicode-aware grapheme segmentation when limits or editing behavior are intended to reflect user-perceived characters.
  • I18N-030 Apply language-appropriate case folding, comparison, collation, and search rather than assuming ASCII rules work for every language.
  • I18N-032 Allow labels, buttons, fields, tables, and notifications to expand or wrap for translations of different lengths.
  • I18N-036 Isolate user-generated, numeric, Latin-script, or otherwise mixed-direction strings to prevent bidirectional text spillover.
  • I18N-039 Design forms for local names, address structures, phone numbers, postal codes, and different writing systems instead of enforcing one national format.
  • I18N-040 Ensure error messages, validation rules, and help text can be translated without weakening meaning or user safety.
  • I18N-041 Provide appropriate reading order, language metadata, and semantic structure for assistive technologies in multilingual views.

Translation and content quality#

  • I18N-043 Establish a localization workflow with designated source-content owners, translators, reviewers, and release responsibilities.
  • I18N-044 Create a maintained terminology glossary for product concepts, technical terms, feature names, and prohibited translations.
  • I18N-045 Provide translators with screenshots, message descriptions, placeholders, target audience, and surrounding interaction context.
  • I18N-046 Maintain consistent tone, product terminology, and reading level across localized pages and user flows.
  • I18N-047 Specify which strings must remain untranslated, such as technical identifiers, trademarks, code tokens, and certain legal names.
  • I18N-048 Review culturally sensitive examples, imagery, symbols, humor, gestures, and assumptions for each target audience.
  • I18N-049 Apply qualified human review to high-impact safety, medical, financial, legal, or contractual content where required.
  • I18N-050 Verify placeholders, markup, variables, and message-format syntax survive translation without changing their semantics.
  • I18N-052 Version translation catalogs with the related product release and preserve traceability to source changes.
  • I18N-053 Define whether machine translation may be used and what post-editing, confidentiality, and quality review it requires.
  • I18N-054 Review translated calls to action, form guidance, error handling, confirmations, and destructive-action warnings within complete user journeys.
  • I18N-055 Check localized help articles, onboarding emails, notification templates, transactional messages, and PDF/download content for consistency.
  • I18N-057 Check locale-specific links, contact information, customer-support channels, and references to services actually offered in that market.
  • I18N-058 Use native speakers or qualified reviewers for representative linguistic QA, including comprehension and idiomatic usage.
  • I18N-059 Test contextual ambiguity, grammatical agreement, pluralization, and short/long forms with representative real data.
  • I18N-060 Define the process and priority for correcting harmful, misleading, or culturally inappropriate translations.
  • I18N-061 Track translation completeness and unresolved quality issues by locale, feature, severity, and owner.
  • I18N-062 Recheck affected translations when terminology, design, pricing, legal content, or source strings change.

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 shared/cross-team controls 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 shared / cross-cutting 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.