Handling Pluralization in Arabic and Slavic Languages ¶

Morphological Mismatch in Standard Binary Pluralization ¶

Default singular/plural conditionals (count === 1 ? singular : plural) fail catastrophically against Semitic and Slavic grammatical structures. Arabic requires six distinct plural categories (zero, one, two, few, many, other), while Slavic languages (Russian, Polish, Czech) use a digit-dependent tripartite system where 1, 2–4, and 5+ dictate entirely different noun endings and verb agreements. Hardcoded binary logic causes silent UI truncation, broken accessibility labels, and failed l10n QA audits. Mapping these Pluralization Rules Across Languages is the mandatory prerequisite before scaling translation pipelines or deploying multi-region products.

CLDR-Driven ICU MessageFormat Resolution ¶

The production-ready architecture decouples numeric evaluation from string rendering using Unicode CLDR data. A runtime plural resolver ingests ICU MessageFormat strings, maps numeric inputs to locale-specific categories, and selects the correct grammatical form without DOM manipulation. This resolver must be integrated into the Core i18n Architecture & Locale Negotiation layer to guarantee deterministic fallback chains, lazy-loaded locale bundles, and consistent behavior across SSR hydration and client-side routing.

Ecosystem-Specific Plural Resolver Setup ¶

Each implementation requires build-time locale registration and explicit ICU backend configuration to prevent runtime fallback to the generic other form.

JavaScript / React (intl-messageformat) ¶

Modern versions of intl-messageformat (v9+) rely on the native Intl.PluralRules API, which is built into V8 (Node 10+) and all evergreen browsers. No separate CLDR data registration is needed in these environments. In Node.js environments older than v13 or environments with incomplete Intl data, use the @formatjs/intl-pluralrules polyfill.

import { IntlMessageFormat } from 'intl-messageformat';

// ICU MessageFormat string with explicit category definitions
const message = `{count, plural,
  =0 {لا توجد عناصر}
  one {عنصر واحد}
  two {عنصران}
  few {# عناصر}
  many {# عنصرًا}
  other {# عنصر}
}`;

// Initialize formatter with target locale
const formatter = new IntlMessageFormat(message, 'ar');
console.log(formatter.format({ count: 3 }));   // → "3 عناصر" (few)
console.log(formatter.format({ count: 100 })); // → "100 عنصر" (other)

For environments without full Intl.PluralRules support:

import '@formatjs/intl-pluralrules/polyfill';
import '@formatjs/intl-pluralrules/locale-data/ar';
import '@formatjs/intl-pluralrules/locale-data/ru';

Python / Django (Babel) ¶

Django’s built-in ngettext supports only binary plural forms. For languages requiring more than two forms, use Babel’s Plural utility to evaluate CLDR plural categories, then route to the appropriate string:

# requirements: babel
from babel.plural import PluralRule

# Load CLDR plural rule for Russian
ru_plural = PluralRule.parse('one: n % 10 = 1 and n % 100 != 11; '
                              'few: n % 10 in 2..4 and n % 100 not in 12..14; '
                              'many: n % 10 = 0 or n % 10 in 5..9 or n % 100 in 11..14; '
                              'other: @integer 0, 10~20, 100, 1000, 10000, 100000, 1000000, …')

# Translation catalog (keyed by CLDR category)
RU_MESSAGES = {
    'one':   '{count} файл',
    'few':   '{count} файла',
    'many':  '{count} файлов',
    'other': '{count} файлов',
}

def format_file_count(count: int) -> str:
    category = ru_plural(count)
    return RU_MESSAGES[category].format(count=count)

print(format_file_count(1))   # → "1 файл"
print(format_file_count(3))   # → "3 файла"
print(format_file_count(12))  # → "12 файлов"

For projects already using Django’s translation framework, django-rosetta or direct .po file management with Babel extraction (pybabel extract) provides the closest CLDR-aware workflow without replacing the existing stack.

Flutter / Dart (Intl.plural() with .arb) ¶

Define all six categories in .arb files and compile via the flutter_localizations package.

// lib/l10n/app_ar.arb
{
  "itemCount": "{count,plural, =0{لا توجد عناصر} =1{عنصر واحد} =2{عنصران} few{# عناصر} many{# عنصرًا} other{# عنصر}}",
  "@itemCount": {
    "description": "Arabic pluralization for item count",
    "placeholders": {
      "count": { "type": "int" }
    }
  }
}

// Usage in widget tree
import 'package:flutter_gen/gen_l10n/app_localizations.dart';

// ...
Text(AppLocalizations.of(context)!.itemCount(5)); // → "5 عناصر" (few)

Audit Workflow & Edge Case Validation ¶

Execute the following validation pipeline before merging i18n changes to production.

1. Verify CLDR Version Parity: Ensure frontend resolvers (e.g., @formatjs/intl-pluralrules) and backend TMS exports reference identical CLDR versions. Mismatched versions can cause silent category boundary shifts (e.g., few vs many thresholds shifting between CLDR releases).

2. Execute Boundary Integer Tests: Run automated scripts against the exact sequence: 0, 1, 2, 3, 4, 5, 11, 12, 13, 14, 15, 20, 100. Slavic rules depend on the last digit and the decade (e.g., 11–14 map to many, not few, despite ending in 1–4).

3. Validate Fractional Inputs: Test 1.5, 2.0, and 0.0. Floating-point values frequently trigger unexpected few or many categories in Arabic. Ensure your resolver applies explicit Math.floor() or integer parsing before plural evaluation when fractional counts are not meaningful.

4. Run Automated Snapshot Tests: Use jest or pytest to compare ICU output against expected grammatical forms. Configure CI to fail on any other fallback for explicitly defined categories.

   expect(formatter.format({ count: 3 })).toBe('3 عناصر'); // Arabic: few

5. Audit Translation Memory Exports: Implement a pre-commit hook to validate .po, .arb, or .json files against CLDR category requirements. Ensure zero missing plural keys. Gaps default to other, degrade accessibility labels, and trigger immediate l10n QA failures.