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: Frontend-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.

Internationalized design#

  • I18N-021 Keep user-facing strings in localization resources instead of hard-coding them into UI layouts or business logic.
  • I18N-031 Account for script-specific fonts, glyph coverage, fallback fonts, line height, and text rendering behavior.
  • I18N-033 Use responsive layouts and flexible spacing instead of fixed widths based on one language.
  • I18N-034 Support right-to-left base direction where required using semantic direction attributes and suitable layout conventions.
  • I18N-035 Use logical CSS properties or equivalent layout abstractions for start/end spacing, alignment, and positioning where appropriate.
  • I18N-037 Test punctuation, neutral symbols, numbers, placeholders, and inline code in mixed right-to-left/left-to-right text.
  • I18N-038 Distinguish icons that should mirror in right-to-left layouts from branding, media controls, numbers, and other icons that should not.
  • I18N-042 Test pseudo-localized long strings, accented characters, non-Latin scripts, and right-to-left simulations before linguistic QA.

Translation and content quality#

  • I18N-051 Detect missing keys, unapproved source-language fallback, obsolete translations, and untranslated UI elements in builds or tests.
  • I18N-056 Verify localized accessibility text, image alternatives, captions, and screen-reader descriptions convey the intended meaning.

Locale-specific experience#

  • I18N-075 Check local keyboard input, input methods, composition events, character selection, and paste behavior.
  • I18N-078 Make language-switcher options recognizable in their own language and script, not only in the current UI language.
  • I18N-063 Verify dates and times display with appropriate locale patterns and an explicit or inferable time zone.
  • I18N-064 Test timestamps around daylight-saving transitions, midnight, year boundaries, and other relevant calendar edge cases.
  • I18N-065 Use appropriately defined calendar systems and week-start conventions when supported, rather than assuming Gregorian dates and Monday/Sunday defaults.
  • I18N-066 Format monetary amounts with the correct ISO currency code or symbol, minor-unit precision, and localized separators.
  • I18N-067 Preserve exact monetary amounts and currencies in calculations while varying only localized presentation as appropriate.
  • I18N-068 Test decimal and grouping separators, native digits, negative values, percentages, and high-precision numbers.
  • I18N-069 Present measurement units and unit conversions that match supported market preferences without changing underlying values unexpectedly.
  • I18N-070 Validate address entry and display for local order, variable line counts, postal codes, regions, and optional fields.
  • I18N-071 Support culturally appropriate personal names, scripts, spacing, and name-order conventions without requiring first/last name where unnecessary.
  • I18N-072 Use suitable international telephone-number handling and do not infer physical residence solely from number prefix.
  • I18N-073 Review local payment methods, taxes, invoicing, and refund display with regional business/legal approvers where relevant.
  • I18N-074 Confirm sorting, filtering, case-insensitive search, and text matching behave as users of each language expect.
  • I18N-076 Verify mixed-script strings and bidirectional identifiers remain readable and do not mislead users about account or transaction details.
  • I18N-077 Test localized account creation, authentication, recovery, checkout, and other critical workflows end to end.
  • I18N-079 Preserve user's current task or equivalent content when switching language whenever a localized counterpart exists.
  • I18N-080 Test supported locales with realistic datasets, local addresses, names, currencies, time zones, and long translations.
  • I18N-081 Verify market-specific legal notices, price displays, eligibility restrictions, and support paths using qualified regional review.
  • I18N-082 Ensure missing translations and region-specific outages have a documented, understandable fallback experience.

Frontend Checks#

  • I18N-103 Set and update document or view language metadata correctly, including language changes within mixed-language content.
  • I18N-104 Apply appropriate base text direction for right-to-left pages and semantic direction isolation for user-generated snippets.
  • I18N-105 Verify every supported locale loads intended message catalogs, with visible review of missing or fallback strings.
  • I18N-106 Test language switching from deep links and authenticated flows without unexpectedly losing state.
  • I18N-107 Ensure responsive layouts tolerate long translations, localized number formats, and expanded buttons or navigation labels.
  • I18N-108 Check fonts and glyph fallback for every supported script, including combined marks, emoji, and complex shaping.
  • I18N-109 Verify text direction and logical spacing across dialogs, forms, tabs, menus, carousels, tables, and notifications.
  • I18N-110 Confirm keyboard focus order and visual reading order remain understandable in right-to-left and multilingual layouts.
  • I18N-111 Test labels, placeholders, form hints, validation messages, and errors using localized rather than hard-coded strings.
  • I18N-112 Render dates, prices, percentages, units, and relative times using approved locale-aware formatting libraries.
  • I18N-113 Show timezone or currency context when omission could cause materially wrong user decisions.
  • I18N-114 Test text input, IME composition, cursor motion, deletion, selection, and copy/paste in non-Latin scripts.
  • I18N-115 Verify sorting and search UI communicate the locale-sensitive behavior actually implemented by the backend.
  • I18N-116 Check translated image alternatives, captions, transcripts, and accessible announcements for meaning and completeness.
  • I18N-117 Make locale-specific content, downloads, help links, and external disclosures available where advertised.
  • I18N-118 Prevent language-specific scripts, fonts, or extra resource bundles from causing major unreviewed performance regressions.
  • I18N-119 Verify localized route metadata, canonical/alternate links, and indexing controls for public sites where SEO is relevant.
  • I18N-120 Test fallback behavior for unavailable locale bundles or broken translations without leaving critical controls unusable.
  • I18N-121 Review localized consent, payment, identity, safety, and error-recovery flows with qualified testers for launch markets.
  • I18N-122 Run pseudo-localization and representative manual linguistic checks in supported browsers and devices before release.

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 browser and client 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 frontend 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.