Check a page for accessibility
Review supplied markup or descriptions for practical accessibility issues and fixes.
5,080,346 AI resources indexedWorking toward the world’s largest AI resource index.
Complete guide for internationalizing Flutter apps using gen-l10n and intl packages. Use when Claude needs to add localization support to Flutter applications, translate UI text, format numbers/dates for different locales, or configure multi-language support for Material/Cupertino apps.
--- name: flutter-internationalization description: >- Add, fix, audit, and maintain Flutter internationalization with gen-l10n, ARB files, AppLocalizations, flutter_localizations, intl formatting, plural/select messages, RTL support, locale-specific number/date formatting, and localization build errors. Use when asked to add l10n or i18n, translate Flutter UI text, configure l10n.yaml, manage ARB translations, migrate away from package:flutter_gen imports, or troubleshoot generated localization code. metadata: author: Stanislav [MADTeacher] Chernyshev version: "2.0" --- # Flutter Internationalization You are a Flutter localization implementer. Make localized apps build, generate, and read naturally across target locales. ## Principle 0 Generated localization code must match the current Flutter project and SDK. Do not copy stale `package:flutter_gen` imports or enable `synthetic-package`; use source-generated `AppLocalizations` imports unless the project proves it is on an older pinned Flutter workflow. ## Decision Guide - Use `gen-l10n` for new work, most migrations, ARB management, plural/select messages, generated `AppLocalizations`, and Material/Cupertino apps. - Use legacy `intl_translation` only when the project already uses `Intl.message()` plus generated `messages_all.dart`, or the user explicitly asks to keep that workflow. Confirm `intl_translation` is a dependency before running its generators. - Use custom map-based localizations only for tiny prototypes or existing code that intentionally avoids code generation. Name this limitation in the final response. - If the project has an existing localization setup, follow its paths, class names, locale list, and generation style before introducing defaults. ## Workflow 1. Inspect `pubspec.yaml`, `l10n.yaml`, existing `*.arb` files, generated imports, `MaterialApp`/`CupertinoApp` setup, and current translation usage. 2. Identify the requested change: bootstrap l10n, add a locale, replace hardcoded UI text, add placeholders/plurals/selects, format values, fix generation, or migrate stale imports/config. 3. Use the decision guide to choose `gen-l10n`, legacy `intl_translation`, or a custom fallback. Prefer the smallest change that fits the existing project. 4. Read only the routed references needed for the task. 5. Make the localization change: - add `flutter_localizations` and `intl:any` when missing; - set `flutter: generate: true`; - create or update `l10n.yaml`; - create or update ARB files with descriptions and placeholder metadata; - wire `AppLocalizations` into `MaterialApp` or `CupertinoApp`; - replace hardcoded UI strings with generated getters or methods. 6. Generate and validate with `flutter gen-l10n`. Then run the narrowest relevant project check, usually `flutter analyze` or affected tests. 7. Report changed files, generated behavior, validation run, and any locales or translation gaps that remain. ## Resource Routing | Task | Read or use | Why | |---|---|---| | Configure or debug `l10n.yaml`, generated output paths, nullable getters, deferred loading, or untranslated tracking | `references/l10n-config.md` | Current gen-l10n options and safe defaults | | Create or repair ARB messages, placeholders, plurals, selects, escaping, or metadata | `references/arb-format.md` | ARB schema patterns and translator context rules | | Add number, currency, percent, or date/time formatting | `references/number-date-formats.md` | Supported `NumberFormat` and `DateFormat` values | | Bootstrap a new gen-l10n setup or run a smoke fixture | `assets/l10n.yaml`, `assets/app_en.arb` | Reusable minimal templates | ## gen-l10n Contract For new gen-l10n setup, the minimum current configuration is: ```yaml flutter: generate: true ``` ```yaml arb-dir: lib/l10n template-arb-file: app_en.arb output-localization-file: app_localizations.dart ``` Use source imports that match the generated location, commonly: ```dart import 'l10n/app_localizations.dart'; ``` Prefer generated lists when possible: ```dart localizationsDelegates: AppLocalizations.localizationsDelegates, supportedLocales: AppLocalizations.supportedLocales, ``` If generated files are written to a custom `output-dir`, update imports to that directory. Do not import `package:flutter_gen/gen_l10n/app_localizations.dart` unless the local project is intentionally pinned to an older Flutter workflow. ## Legacy Intl Fallback When preserving `Intl.message()`: - require `intl_translation` in dev dependencies before extraction/generation; - keep generated files and imports consistent with the existing project; - run extraction before generation; - on Windows or shells without wildcard expansion, list ARB files explicitly. Typical commands: ```bash dart run intl_translation:extract_to_arb --output-dir=lib/l10n lib/main.dart dart run intl_translation:generate_from_arb --output-dir=lib/l10n --no-use-deferred-loading lib/main.dart lib/l10n/intl_*.arb ``` If this workflow is not already present, explain why `gen-l10n` is the safer default. ## Constraints - Do not invent translations. If target-language text is not supplied, add clear placeholder translations only when the user approved that, or report the missing translations. - Do not concatenate localized strings. Use placeholders, plural, or select messages. - Do not manually format numbers, currency, percentages, dates, or times when gen-l10n placeholder formatting can do it. - Do not add `synthetic-package: true`; current Flutter marks synthetic package generation as deprecated and unavailable. - Set `nullable-getter: false` only when the project accepts non-null generated getter behavior. Otherwise keep the project default and use the required null handling in code. - Keep translator-facing descriptions and examples in the template ARB file. - For RTL locales, check text direction, layout assumptions, mirrored icons, and locale-specific widgets. ## Validation Always validate a completed localization change: - `flutter gen-l10n` succeeds with the project's `l10n.yaml`; - generated import paths compile; - every new ARB key exists in the template file and needed locale files; - placeholders in translated ARB values match template metadata; - plural/select messages include `other`; - number/date placeholders use supported formats from `references/number-date-formats.md`; - relevant `flutter analyze` or tests pass, or blockers are reported. For skill maintenance, also check YAML frontmatter, local markdown links, JSON validity for ARB assets, YAML validity for `l10n.yaml`, resource routing, and layer coherence between `SKILL.md`, references, and assets.--- name: flutter-internationalization description: >- Add, fix, audit, and maintain Flutter internationalization with gen-l10n, ARB files, AppLocalizations, flutter_localizations, intl formatting, plural/select messages, RTL support, locale-specific number/date formatting, and localization build errors. Use when asked to add l10n or i18n, translate Flutter UI text, configure l10n.yaml, manage ARB translations, migrate away from package:flutter_gen imports, or troubleshoot generated localization code. metadata: author: Stanislav [MADTeacher] Chernyshev version: "2.0" --- # Flutter Internationalization You are a Flutter localization implementer. Make localized apps build, generate, and read naturally across target locales. ## Principle 0 Generated localization code must match the current Flutter project and SDK. Do not copy stale `package:flutter_gen` imports or enable `synthetic-package`; use source-generated `AppLocalizations` imports unless the project proves it is on an older pinned Flutter workflow. ## Decision Guide - Use `gen-l10n` for new work, most migrations, ARB management, plural/select messages, generated `AppLocalizations`, and Material/Cupertino apps. - Use legacy `intl_translation` only when the project already uses `Intl.message()` plus generated `messages_all.dart`, or the user explicitly asks to keep that workflow. Confirm `intl_translation` is a dependency before running its generators. - Use custom map-based localizations only for tiny prototypes or existing code that intentionally avoids code generation. Name this limitation in the final response. - If the project has an existing localization setup, follow its paths, class names, locale list, and generation style before introducing defaults. ## Workflow 1. Inspect `pubspec.yaml`, `l10n.yaml`, existing `*.arb` files, generated imports, `MaterialApp`/`CupertinoApp` setup, and current translation usage. 2. Identify the requested change: bootstrap l10n, add a locale, replace hardcoded UI text, add placeholders/plurals/selects, format values, fix generation, or migrate stale imports/config. 3. Use the decision guide to choose `gen-l10n`, legacy `intl_translation`, or a custom fallback. Prefer the smallest change that fits the existing project. 4. Read only the routed references needed for the task. 5. Make the localization change: - add `flutter_localizations` and `intl:any` when missing; - set `flutter: generate: true`; - create or update `l10n.yaml`; - create or update ARB files with descriptions and placeholder metadata; - wire `AppLocalizations` into `MaterialApp` or `CupertinoApp`; - replace hardcoded UI strings with generated getters or methods. 6. Generate and validate with `flutter gen-l10n`. Then run the narrowest relevant project check, usually `flutter analyze` or affected tests. 7. Report changed files, generated behavior, validation run, and any locales or translation gaps that remain. ## Resource Routing | Task | Read or use | Why | |---|---|---| | Configure or debug `l10n.yaml`, generated output paths, nullable getters, deferred loading, or untranslated tracking | `references/l10n-config.md` | Current gen-l10n options and safe defaults | | Create or repair ARB messages, placeholders, plurals, selects, escaping, or metadata | `references/arb-format.md` | ARB schema patterns and translator context rules | | Add number, currency, percent, or date/time formatting | `references/number-date-formats.md` | Supported `NumberFormat` and `DateFormat` values | | Bootstrap a new gen-l10n setup or run a smoke fixture | `assets/l10n.yaml`, `assets/app_en.arb` | Reusable minimal templates | ## gen-l10n Contract For new gen-l10n setup, the minimum current configuration is: ```yaml flutter: generate: true ``` ```yaml arb-dir: lib/l10n template-arb-file: app_en.arb output-localization-file: app_localizations.dart ``` Use source imports that match the generated location, commonly: ```dart import 'l10n/app_localizations.dart'; ``` Prefer generated lists when possible: ```dart localizationsDelegates: AppLocalizations.localizationsDelegates, supportedLocales: AppLocalizations.supportedLocales, ``` If generated files are written to a custom `output-dir`, update imports to that directory. Do not import `package:flutter_gen/gen_l10n/app_localizations.dart` unless the local project is intentionally pinned to an older Flutter workflow. ## Legacy Intl Fallback When preserving `Intl.message()`: - require `intl_translation` in dev dependencies before extraction/generation; - keep generated files and imports consistent with the existing project; - run extraction before generation; - on Windows or shells without wildcard expansion, list ARB files explicitly. Typical commands: ```bash dart run intl_translation:extract_to_arb --output-dir=lib/l10n lib/main.dart dart run intl_translation:generate_from_arb --output-dir=lib/l10n --no-use-deferred-loading lib/main.dart lib/l10n/intl_*.arb ``` If this workflow is not already present, explain why `gen-l10n` is the safer default. ## Constraints - Do not invent translations. If target-language text is not supplied, add clear placeholder translations only when the user approved that, or report the missing translations. - Do not concatenate localized strings. Use placeholders, plural, or select messages. - Do not manually format numbers, currency, percentages, dates, or times when gen-l10n placeholder formatting can do it. - Do not add `synthetic-package: true`; current Flutter marks synthetic package generation as deprecated and unavailable. - Set `nullable-getter: false` only when the project accepts non-null generated getter behavior. Otherwise keep the project default and use the required null handling in code. - Keep translator-facing descriptions and examples in the template ARB file. - For RTL locales, check text direction, layout assumptions, mirrored icons, and locale-specific widgets. ## Validation Always validate a completed localization change: - `flutter gen-l10n` succeeds with the project's `l10n.yaml`; - generated import paths compile; - every new ARB key exists in the template file and needed locale files; - placeholders in translated ARB values match template metadata; - plural/select messages include `other`; - number/date placeholders use supported formats from `references/number-date-formats.md`; - relevant `flutter analyze` or tests pass, or blockers are reported. For skill maintenance, also check YAML frontmatter, local markdown links, JSON validity for ARB assets, YAML validity for `l10n.yaml`, resource routing, and layer coherence between `SKILL.md`, references, and assets.
Imported from the listed AgentSkill.sh category. Complete supplied package files and notices are retained. Required external tools and credentials are not installed. No bundled code was executed during import. Individual agent task behavior has not been tested.
Resource notes updated 2026-10-27 · Original instructions by MADTeacher