Internationalization

Internationalization (i18n) and localization (l10n) best practices for Flutter applications using Flutter's built-in localization system with ARB files as the single source of truth.

Core Standards

Apply these standards to all internationalization work:

• Never hardcode user-facing strings — all text must go through the l10n system
• Use Flutter's built-in localization system — flutter_localizations + intl, never third-party i18n libraries
• ARB files are the single source of truth for all translations
• BuildContext extension for cleaner l10n access — use context.l10n instead of AppLocalizations.of(context)
• Pass localized strings as parameters to reusable widgets — never couple shared widgets directly to AppLocalizations
• Use EdgeInsetsDirectional (start/end) instead of EdgeInsets (left/right) — ensures correct layout in RTL languages
• Handle RTL layout properly — use directional widgets for padding, positioning, and alignment
• Implement i18n early — even if only one language is planned initially, the overhead is small and the long-term benefit is significant
• Dart 3.13 primary constructors — on a Dart 3.13+ baseline, declare a reusable widget's localized-string fields as primary-constructor declaring parameters (class const ConfirmDialog({required final String title, super.key}) extends StatelessWidget) rather than this.field; keep the classic form only below 3.13

Setup Pipeline and ARB File Format