Flutter Internationalization Deep Dive: Handling Complex Locales (like Bosnian/Croatian/Serbian) for Global Apps

When building a global Flutter app, you’ll eventually encounter a fascinating localization challenge: handling a set of closely related languages that share significant overlap but are considered distinct by their speakers. A classic example is the trio of Bosnian (bs), Croatian (hr), and Serbian (sr). These languages are mutually intelligible, but each has its own cultural identity, subtle linguistic differences, and unique locale code.

The naive approach—treating them as a single locale—can lead to user dissatisfaction and a perception of cultural insensitivity. The technical approach—treating them as three fully separate locales—can triple your translation costs and maintenance overhead. Let’s explore the practical strategies and trade-offs for navigating this complexity in your Flutter app.

Understanding the Core Problem

Flutter’s internationalization (intl) system, powered by flutter_localizations and packages like intl or easy_localization, is designed around distinct locale codes (en_US, fr_CA). When your app supports hr, bs, and sr, you face a dilemma:

1. Three Separate Locales: You create three complete .arb files or string maps. This is the most respectful and accurate approach, but it means paying for three nearly identical translations and maintaining three separate files where 95% of the content is the same.
2. One Unified Locale: You pick one locale code (e.g., sr_Latn for Serbian Latin) and use it for all three. This saves significant cost and effort, but risks alienating users who see their specific language not being offered. It can also cause issues with app store listings if the language shown isn’t the one used in-app.

Strategy 1: The Shared Base with Overrides

A balanced, practical solution is to create a shared base translation for the commonalities and provide overrides for the key differences. This isn’t directly supported by gen-l10n, but you can implement it manually with a fallback chain.

Step 1: Define your translation maps.
Create a base map for the common language (bcs_common), and specific maps for the unique terms in each language.

// translation_maps.dart
const Map<String, String> _baseBcsTranslations = {
  'welcome': 'Dobrodošli',
  'settings': 'Postavke',
  'save': 'Spremi',
  // 95% of your strings go here
};

const Map<String, String> _croatianOverrides = {
  'currency': 'kuna (HRK)', // Specific term in Croatia
};

const Map<String, String> _serbianOverrides = {
  'currency': 'dinar (RSD)', // Specific term in Serbia
};

const Map<String, String> _bosnianOverrides = {
  'currency': 'konvertibilna marka (BAM)', // Specific term in Bosnia
};

Step 2: Build a locale-aware lookup function.
This function merges the base map with the correct overrides based on the active locale.

// localization_service.dart
String translate(String key, Locale activeLocale) {
  // 1. Start with the base translations
  Map<String, String> combinedMap = Map.from(_baseBcsTranslations);

  // 2. Apply the correct overrides
  switch (activeLocale.languageCode) {
    case 'hr':
      combinedMap.addAll(_croatianOverrides);
      break;
    case 'sr':
      combinedMap.addAll(_serbianOverrides);
      break;
    case 'bs':
      combinedMap.addAll(_bosnianOverrides);
      break;
  }

  // 3. Return the key, or a fallback if not found
  return combinedMap[key] ?? key;
}

// Usage in your UI
Text(
  translate('currency', Localizations.localeOf(context)),
)

Strategy 2: Conditional Logic Within Strings

For more complex differences—like date formats, grammatical variations, or entire phrases—you can embed conditional logic directly in your translation files if your chosen i18n package supports placeholders and formatting. With intl, you can use method signatures in your .arb file.

// app_en.arb
{
  "@@locale": "en",
  "itemCountMessage": "{count, plural, =0{No items} =1{1 item} other{{count} items}}"
}

// app_bcs.arb
{
  "@@locale": "sh", // Using Serbo-Croatian (sh) as a base, OR duplicate for hr/sr/bs
  "itemCountMessage": "{count, plural, =0{Nema stavki} =1{1 stavka} few{{count} stavke} other{{count} stavki}}"
}

You would then generate the Dart code and use it. The key here is that the pluralization rules (=1, few, other) are critical for South Slavic languages and differ from English. You must have separate .arb files for hr, bs, and sr if the pluralization categories differ (they generally follow the same rules, but it’s a point of verification).

Common Mistakes & Best Practices

• Mistake: Ignoring Script Variants. Serbian can be written in both Latin (sr_Latn) and Cyrillic (sr_Cyrl) scripts. If your target audience includes Serbia, you likely need to support both. Use Locale('sr', 'Cyrl') and Locale('sr', 'Latn') and prepare separate string resources.
• Mistake: Assuming Complete Sameness. While many words are identical, certain technical, legal, or cultural terms differ. Always have a native speaker from each region review the final strings.
• Best Practice: Let the System Choose. Use supportedLocales wisely. List all your specific locales (hr, bs, sr_Latn, sr_Cyrl), and let Flutter’s localeListResolutionCallback pick the best match based on the user’s device settings. This respects individual user choice.
• Best Practice: Be Transparent with Users. In your app’s language selection screen, you can add a note: “Bosnian, Croatian, and Serbian translations are largely unified with attention to regional differences.” This manages expectations.

Final Recommendation

For most apps, the optimal path is a hybrid approach:

1. Technically, treat them as separate locales (hr, bs, sr) in your pubspec.yaml and supportedLocales list.
2. Practically, manage the translations by creating a single source file (e.g., bcs_base.arb) and use a pre-generation script to duplicate it for bs and sr, then manually edit the files to incorporate the necessary regional variations for key terms.
3. Culturally, invest in a final human review by native speakers from each region to catch nuances you might have missed.

This method keeps your code clean, respects the distinct locales, and controls cost by focusing translation effort only on the parts that truly differ.