Internationalization

Add the locale

AppLocale is a sealed class, so every supported locale is a named subclass. This is what stops a typo'd locale code from reaching the widget tree.

final class SpanishLocale extends AppLocale {
  const SpanishLocale() : super('es'); // 👈 the language code
}

Add the language to the AppLanguage enum

• code is the language code, and it is the value written to the database.

• name is what the language picker shows, so write it in that language.

• The analyzer will then flag toLocale() as non-exhaustive.

  enum AppLanguage {
    /// English language.
    english('en', 'English'),
  
    /// French language.
    french('fr', 'Français'),
  
    /// Spanish language.
    spanish('es', 'Español'), // 👈 new language
  
    /// System language.
    system('system', 'System');
  
    const AppLanguage(this.code, this.name);
  
    // ...existing code
  
    Locale? toLocale() {
      return switch (this) {
        AppLanguage.english => const EnglishLocale(),
        AppLanguage.french => const FrenchLocale(),
        AppLanguage.spanish => const SpanishLocale(), // 👈 new locale
        AppLanguage.system => null,
      };
    }
  }

Update the appLocale getter

context.appLocale maps the active Locale back onto an AppLocale subclass. It is a second exhaustive switch over AppLanguage, so the analyzer flags this one too.

extension BuildContextX on BuildContext {
  AppLocale get appLocale {
    final locale = Localizations.localeOf(this);

    return switch (AppLanguage.fromString(locale.languageCode)) {
      AppLanguage.english => const EnglishLocale(),
      AppLanguage.french => const FrenchLocale(),
      AppLanguage.spanish => const SpanishLocale(), // 👈 new locale
      AppLanguage.system => const EnglishLocale(),
    };
  }

  // ...existing code
}

Duplicate app_fr.arb

Copy lib/core/presentation/l10n/app_fr.arb to app_<language_code>.arb, app_es.arb here.

Copy the French file rather than the English one on purpose. app_en.arb is the template-arb-file, so it carries an @key metadata entry for every message, descriptions and placeholder types that only the template needs. app_fr.arb holds the same messages with none of that overhead.

Set the locale and translate

Change @@locale, then replace every value. LLMs are good at this, and the file is large enough that you will want the help.

{
  "@@locale": "es",
  "aboutToQuitPage": "Estás a punto de salir de la página.",
  "account": "Cuenta"
  // ...the rest
}

Keep every key. A message missing from app_es.arb falls back to the template's English text at runtime rather than failing the build, so an incomplete file shows up as stray English in the UI, not as an error.

Generate

flutter gen-l10n

The Dart output lands in lib/core/presentation/l10n/generated, per l10n.yaml. pubspec.yaml also sets generate: true, so flutter pub get and a normal build regenerate it for you, running the command directly is just the fastest way to see the result.

Add the language to the Language union

export type Language = "en" | "fr" | "es"; // 👈 "es" added

Ask Deno what is now incomplete

cd supabase/functions
deno task check

Every block that still lacks the new language is reported as a TS2741, with its path and line:

TS2741 [ERROR]: Property 'es' is missing in type '{ readonly en: ...; readonly fr: ...; }'
but required in type 'Record<Language, EmailContent>'.
const translations: Record<Language, EmailContent> = {
      ~~~~~~~~~~~~
    at .../send-email/_templates/sign-up/confirm-email.tsx:93:7

The subject lines in l10n.ts are reported the same way, because subjects is a Record<Language, …> too.

Work down the list, then re-run

Fill in the new key in each reported object and run deno task check again. When no TS2741 naming your language code is left, every typed email string has been translated.

How many blocks that is depends on which layers your project was generated with, which is exactly why this page does not enumerate them.

Before you have ever applied the migration, edit the line above in place: language TEXT DEFAULT 'en'. Afterwards, add a migration instead:

ALTER TABLE public.users_prefs
  ALTER COLUMN language TYPE TEXT;

Nothing to regenerate on the TypeScript side. supabase/functions/_shared/database.types.ts already types the column as string | null, because VARCHAR(2) and TEXT are both string there; the cap was never expressed in the types, which is part of why it is easy to miss.

On the Flutter side, AppLanguage.code is what gets written, so a regional code only needs the enum entry and a matching AppLocale subclass. Note that context.appLocale switches on locale.languageCode alone, which is pt for both pt and pt-BR, distinguishing them means matching on countryCode or scriptCode there as well.