ملفات ARB ومسار توطين gen_l10n

Hard-coding strings like Text('Welcome') makes an app impossible to translate. Flutter's official solution is gen_l10n: you write translations in ARB (Application Resource Bundle, a JSON format) files, and the build tool generates a typed Dart class so typos become compile-time errors.

Two pieces are required in pubspec.yaml. The flutter_localizations SDK package supplies Material/Cupertino/Widgets translations, and the generate: true flag turns on the gen_l10n build step.

• intl is pulled in because generated code uses it for plurals and dates.
• After editing, run flutter pub get.

Create an l10n.yaml file at the project root. It tells gen_l10n where your ARB files live and what to name the generated class.

• arb-dir — folder holding the .arb files.
• template-arb-file — the source-of-truth locale that defines keys and metadata.
• output-localization-file — name of the generated Dart file.
• output-class — the class name you import in code.

The template locale (here app_en.arb) defines every key. Each key maps to a translated value. Keys starting with @ are metadata: they describe the entry but produce no string.

• @@locale declares which locale this file is.
• @welcome can carry a description to help translators.

The filename pattern is app_<localeCode>.arb.

For each additional language, add a sibling file with the same keys but translated values. Metadata (the @ keys) is only required in the template; translations may omit it.

• Here app_tr.arb provides Turkish strings.
• Missing keys fall back to the template locale, so keep the template complete.

Code generation runs automatically during flutter run or flutter build when generate: true is set. You can also force it with flutter gen-l10n.

• Output lands in .dart_tool/flutter_gen/gen_l10n/ by default.
• The generated AppLocalizations class exposes one getter per key.
• Add the generated path to your IDE's import suggestions; do not commit generated files.

Register the generated delegates and supported locales on MaterialApp. AppLocalizations.localizationsDelegates bundles your delegate plus the Material/Widgets/Cupertino ones, and supportedLocales lists what you ship.

• Flutter picks the best match between the device locale and supportedLocales.
• If none match, the first entry in supportedLocales is used.

Inside a widget you fetch the localized instance with AppLocalizations.of(context) and read a getter. The call is null only if the delegates are missing, so the common idiom uses !.

• Each key from the ARB becomes a strongly-typed getter.
• Rename a key in the ARB and every wrong usage fails to compile.

To inject values, declare placeholders in the template metadata. The value uses {name} syntax, and gen_l10n turns the getter into a method.

• Each placeholder needs a type (e.g. String, int, DateTime).
• The generated method signature follows the placeholder order.

Because greeting takes an argument, the generated member is a method, not a getter. You pass the value at the call site.

• l10n.greeting('Ada') returns "Hello, Ada!".
• Types are enforced: passing an int where a String is expected fails to compile.

ARB supports ICU message syntax for plurals. A {count, plural, ...} block selects the right wording per language. Declare the placeholder as num (or int).

• =0, one, and other are common categories.
• # is replaced by the formatted number.
• Different locales have different plural rules — ICU handles them automatically.

The selection logic ICU performs is just rules over a number. Here is a tiny standalone Dart program that mimics English plural selection — useful for understanding what gen_l10n generates under the hood.

• Real apps use the generated method; this is only for intuition.

You built the full Flutter localization pipeline:

• Added flutter_localizations + intl and set generate: true.
• Configured l10n.yaml (arb-dir, template, output class).
• Wrote a template ARB plus per-locale translations.
• Let gen_l10n create the typed AppLocalizations class.
• Registered localizationsDelegates and supportedLocales, then read strings via AppLocalizations.of(context)!.
• Used placeholders for dynamic values and ICU plurals for count-aware text.

The payoff: translations are type-checked, missing template keys are caught early, and translators work in a clean JSON format.