@wazir-dev/cli 1.0.0

package/expertise/i18n/PROGRESS.md

@@ -0,0 +1,65 @@
+# i18n/RTL Expertise Research Progress
+
+## Status
+- Total: 33
+- Done: 33
+- Remaining: 0
+
+## Modules
+
+### Foundations
+- [x] i18n-architecture.md (2026-03-08)
+- [x] unicode-and-encoding.md (2026-03-08)
+- [x] locale-and-language-tags.md (2026-03-08)
+- [x] string-externalization.md (2026-03-08)
+- [x] pluralization-and-gender.md (2026-03-08)
+- [x] date-time-calendars.md (2026-03-08)
+- [x] numbers-currency-units.md (2026-03-08)
+- [x] text-direction-bidi.md (2026-03-08)
+
+### RTL
+- [x] rtl-fundamentals.md (2026-03-08)
+- [x] rtl-layout-mirroring.md (2026-03-08)
+- [x] rtl-typography.md (2026-03-08)
+- [x] rtl-icons-and-images.md (2026-03-08)
+- [x] rtl-navigation-and-gestures.md (2026-03-08)
+- [x] rtl-forms-and-input.md (2026-03-08)
+- [x] rtl-animations-and-transitions.md (2026-03-08)
+- [x] rtl-testing-and-qa.md (2026-03-08)
+- [x] arabic-specific.md (2026-03-08)
+- [x] hebrew-specific.md (2026-03-08)
+
+### Platform
+- [x] flutter-i18n.md (2026-03-08)
+- [x] react-i18n.md (2026-03-08)
+- [x] native-ios-i18n.md (2026-03-08)
+- [x] native-android-i18n.md (2026-03-08)
+- [x] web-css-i18n.md (2026-03-08)
+- [x] backend-i18n.md (2026-03-08)
+
+### Content
+- [x] translation-management.md (2026-03-08)
+- [x] machine-translation-integration.md (2026-03-08)
+- [x] content-adaptation.md (2026-03-08)
+- [x] locale-specific-formatting.md (2026-03-08)
+
+### Advanced
+- [x] bidirectional-text-algorithm.md (2026-03-08)
+- [x] complex-scripts.md (2026-03-08)
+- [x] accessibility-and-i18n.md (2026-03-08)
+- [x] performance-and-i18n.md (2026-03-08)
+- [x] testing-i18n.md (2026-03-08)
+
+---
+
+## Final Summary (2026-03-08)
+
+All 33 i18n/RTL expertise modules are complete. The knowledge base covers:
+
+- **Foundations:** Architecture, Unicode, locale tags, string externalization, pluralization, dates, numbers, BiDi
+- **RTL:** Fundamentals, layout mirroring, typography, icons, navigation, forms, animations, testing, Arabic-specific, Hebrew-specific
+- **Platform:** Flutter, React, Web CSS, iOS, Android, Backend
+- **Content:** Translation management, MT, content adaptation, locale formatting
+- **Advanced:** BiDi algorithm, complex scripts, accessibility, performance, testing
+
+Use these modules during Clarifier (architecture) and Dev (implementation) to bake i18n in from day one.

package/expertise/i18n/advanced/accessibility-and-i18n.md

@@ -0,0 +1,28 @@
+# Accessibility and i18n — i18n/RTL Expertise Module
+
+> lang and dir attributes aid screen readers; RTL affects reading order. Ensure accessible labels, focus order, and semantic structure in all locales.
+
+> **Category:** Advanced
+> **Applies to:** All
+> **Key standards:** WCAG, W3C
+> **RTL impact:** High — focus order, reading order
+
+## 1. lang and dir
+
+- `lang` on html and elements with language change
+- `dir` for base direction
+- Screen readers use both for pronunciation and order
+
+## 2. Focus Order
+
+- Tab order should follow visual order
+- In RTL, that means right-to-left
+- Ensure focusable elements in correct sequence
+
+## 3. Labels and ARIA
+
+- Accessible names in correct language
+- Don't mix languages in single label without lang attribute
+
+---
+*Researched: 2026-03-08 | Sources: WCAG, W3C*

package/expertise/i18n/advanced/bidirectional-text-algorithm.md

@@ -0,0 +1,38 @@
+# Bidirectional Text Algorithm — i18n/RTL Expertise Module
+
+> Unicode UAX #9: how the BiDi algorithm resolves display order from logical order. Character types, embedding levels, and when to use overrides (LRI, RLI, PDI, LRM, RLM).
+
+> **Category:** Advanced
+> **Applies to:** All
+> **Key standards:** Unicode UAX #9
+> **RTL impact:** Critical — foundation of BiDi
+
+## 1. Algorithm Overview
+
+1. **Classify** characters (L, R, AL, EN, AN, NSM, etc.)
+2. **Resolve** embedding levels from base direction
+3. **Reorder** for display
+
+## 2. Character Types
+
+- **L (strong LTR):** Latin, digits in LTR context
+- **R (strong RTL):** Hebrew
+- **AL (Arabic letter):** Arabic
+- **EN (European number):** 0-9
+- **AN (Arabic number):** ٠-٩
+- **NSM:** Combining marks
+
+## 3. When Algorithm Fails
+
+- Neutral characters between runs
+- Spillover (number after RTL phrase)
+- Use RLI/PDI (isolate) or LRM/RLM (mark)
+
+## 4. Control Characters
+
+- LRI, RLI, FSI, PDI — isolate (prefer)
+- LRE, RLE, PDF — embed (legacy, spillover risk)
+- LRM, RLM — single-character marks
+
+---
+*Researched: 2026-03-08 | Sources: Unicode UAX #9, W3C BiDi*

package/expertise/i18n/advanced/complex-scripts.md

@@ -0,0 +1,30 @@
+# Complex Scripts — i18n/RTL Expertise Module
+
+> Arabic shaping, Hebrew final forms, Indic conjuncts, and CJK: OpenType, HarfBuzz, and rendering requirements. Font and engine support matter.
+
+> **Category:** Advanced
+> **Applies to:** All
+> **Key standards:** OpenType, Unicode
+> **RTL impact:** High — Arabic, Hebrew are complex scripts
+
+## 1. Script Requirements
+
+- **Arabic:** Contextual forms, ligatures, shaping
+- **Hebrew:** Final forms, niqqud
+- **Indic:** Conjuncts, reordering
+- **CJK:** Ideographs, line breaking
+
+## 2. Implementation
+
+- Use fonts with OpenType support
+- HarfBuzz (or platform shaper) for shaping
+- Test with real text
+
+## 3. Anti-Patterns
+
+- Font without script support
+- Truncation that splits grapheme clusters
+- Assuming 1 char = 1 glyph
+
+---
+*Researched: 2026-03-08 | Sources: OpenType, Unicode*

package/expertise/i18n/advanced/performance-and-i18n.md

@@ -0,0 +1,27 @@
+# Performance and i18n — i18n/RTL Expertise Module
+
+> Lazy load locale data; avoid bundling all languages. Split by locale or namespace. Measure bundle size impact.
+
+> **Category:** Advanced
+> **Applies to:** All
+> **RTL impact:** Low
+
+## 1. Lazy Loading
+
+- Load translation files on demand
+- Dynamic import per locale
+- Don't bundle ar, he, zh if user only needs en
+
+## 2. Bundle Size
+
+- Each locale adds KB
+- Split by namespace (auth, dashboard, etc.)
+- Tree-shake unused keys if supported
+
+## 3. Caching
+
+- Cache loaded locale data
+- CDN for static locale JSON
+
+---
+*Researched: 2026-03-08*

package/expertise/i18n/advanced/testing-i18n.md

@@ -0,0 +1,28 @@
+# Testing i18n — i18n/RTL Expertise Module
+
+> Pseudo-localization, missing key detection, locale switching tests, and RTL visual regression. Automate what you can.
+
+> **Category:** Advanced
+> **Applies to:** All
+> **RTL impact:** Critical — RTL needs dedicated tests
+
+## 1. Pseudo-Localization
+
+- Expand/accent strings to find truncation
+- RTL pseudo (ar-XB) for layout
+- Bracket keys to find untranslated
+
+## 2. Automated Checks
+
+- Lint for physical CSS properties
+- CI: run with RTL locale
+- Snapshot/visual regression for RTL
+
+## 3. Manual
+
+- Real Arabic/Hebrew
+- Forms, navigation, mixed content
+- Screen reader with RTL
+
+---
+*Researched: 2026-03-08 | Sources: Android pseudolocales, testing guides*

package/expertise/i18n/content/content-adaptation.md

@@ -0,0 +1,23 @@
+# Content Adaptation — i18n/RTL Expertise Module
+
+> Beyond translation: cultural adaptation of images, colors, symbols, and formats. What works in one market may not in another.
+
+> **Category:** Content
+> **Applies to:** All
+> **RTL impact:** High — RTL markets have distinct cultural norms
+
+## 1. Cultural Adaptation
+
+- **Images:** Avoid culture-specific gestures, symbols
+- **Colors:** Red = luck (China) vs danger (West)
+- **Dates/calendars:** Hijri, Hebrew where relevant
+- **Numbers:** Eastern vs Western Arabic numerals
+
+## 2. RTL-Specific
+
+- Layout mirrors; content may need different imagery
+- Icons: directional vs universal
+- Text in images: avoid; use overlay
+
+---
+*Researched: 2026-03-08*

package/expertise/i18n/content/locale-specific-formatting.md

@@ -0,0 +1,23 @@
+# Locale-Specific Formatting — i18n/RTL Expertise Module
+
+> Date, number, currency, list, and unit formatting vary by locale. Use CLDR/Intl; document locale-specific expectations.
+
+> **Category:** Content
+> **Applies to:** All
+> **RTL impact:** Medium — numeral system, date format
+
+## 1. Formatting by Locale
+
+- **Date:** Gregorian, Hijri, Hebrew, etc.
+- **Number:** Decimal (.,), grouping, numerals
+- **Currency:** Symbol position, spacing
+- **List:** And/or/conjunction rules
+
+## 2. Implementation
+
+- Intl.DateTimeFormat, Intl.NumberFormat
+- Pass locale explicitly
+- Never hardcode formats
+
+---
+*Researched: 2026-03-08 | Sources: CLDR*

package/expertise/i18n/content/machine-translation-integration.md

@@ -0,0 +1,28 @@
+# Machine Translation Integration — i18n/RTL Expertise Module
+
+> MT for scale; human for quality. When to use MT vs human, post-editing, and integration patterns. MT helps volume; doesn't fix architectural mistakes.
+
+> **Category:** Content
+> **Applies to:** All
+> **RTL impact:** Medium — MT supports Arabic, Hebrew
+
+## 1. When to Use
+
+- **MT:** High volume, low risk, internal tools
+- **Human:** Marketing, legal, UX-critical
+- **Hybrid:** MT + human review
+
+## 2. Integration
+
+- TMS often has MT built-in (Google, DeepL, etc.)
+- API integration for custom flows
+- Post-edit workflow
+
+## 3. Limitations
+
+- Doesn't fix concatenation, wrong plural
+- Context matters; provide it
+- RTL: MT outputs correct script; layout is separate
+
+---
+*Researched: 2026-03-08*

package/expertise/i18n/content/translation-management.md

@@ -0,0 +1,29 @@
+# Translation Management — i18n/RTL Expertise Module
+
+> Translation workflow: TMS (Crowdin, Lokalise, Phrase), key naming, context for translators, and continuous localization. Integrate early; avoid batch-at-end.
+
+> **Category:** Content
+> **Applies to:** All
+> **Key standards:** XLIFF, TMS APIs
+> **RTL impact:** Medium — TMS must handle RTL preview
+
+## 1. Workflow
+
+- Extract strings → Push to TMS → Translate → Pull to repo
+- Continuous: sync on commit; batch: before release
+- Key naming: semantic, hierarchical
+
+## 2. Tools
+
+- Crowdin, Lokalise, Phrase, Transifex
+- Integrate via API or CLI
+- Provide context: screenshots, descriptions, max length
+
+## 3. Quality
+
+- Glossary, style guide
+- Review workflow
+- QA for RTL, truncation
+
+---
+*Researched: 2026-03-08 | Sources: TMS vendors*

package/expertise/i18n/foundations/date-time-calendars.md

@@ -0,0 +1,67 @@
+# Date, Time, and Calendars — i18n/RTL Expertise Module
+
+> Never hardcode date formats. Use `Intl.DateTimeFormat` or equivalent. Calendars vary: Gregorian, Hijri, Hebrew, Persian, Buddhist, Japanese Imperial. Locale determines default format and calendar.
+
+> **Category:** Foundation
+> **Applies to:** All
+> **Key standards:** CLDR, Intl API
+> **RTL impact:** Low — dates are locale-specific, not direction-specific
+
+## 1. Core Concepts
+
+### Calendars in Use
+
+| Calendar | Locales | Use |
+|----------|---------|-----|
+| **Gregorian** | Most | Default for en, fr, de, etc. |
+| **Hijri (Islamic)** | ar-SA, religious | Saudi civil, Muslim religious |
+| **Hebrew** | he-IL | Jewish holidays, traditional |
+| **Persian (Solar Hijri)** | fa-IR | Iran |
+| **Buddhist** | th-TH | Thailand |
+| **Japanese Imperial** | ja-JP | Japan (optional) |
+
+### Intl.DateTimeFormat
+
+```javascript
+new Intl.DateTimeFormat('ar-SA', {
+  calendar: 'islamic',
+  year: 'numeric',
+  month: 'long',
+  day: 'numeric'
+}).format(new Date());
+
+new Intl.DateTimeFormat('he-IL', {
+  calendar: 'hebrew',
+  year: 'numeric',
+  month: 'long'
+}).format(new Date());
+```
+
+### Format by Locale
+
+- **en-US:** MM/DD/YYYY
+- **en-GB:** DD/MM/YYYY
+- **de-DE:** DD.MM.YYYY
+- **ja-JP:** YYYY年M月D日
+- **ar-SA:** Often Hijri; format varies
+
+---
+
+## 2. Anti-Patterns
+
+1. **Hardcoded MM/DD/YYYY** — Wrong for 96% of world
+2. **Assuming Gregorian** — Offer Hijri for ar-SA, Hebrew for he-IL
+3. **No timezone** — Use `timeZone` option or store UTC, display local
+4. **12h vs 24h** — Locale-dependent; use `hour12` from locale or user pref
+
+---
+
+## Quick Reference Checklist
+
+- [ ] Use Intl.DateTimeFormat (or platform equivalent)
+- [ ] Pass locale explicitly
+- [ ] Support non-Gregorian calendars where relevant
+- [ ] Handle timezone
+
+---
+*Researched: 2026-03-08 | Sources: MDN Intl.DateTimeFormat, CLDR calendars*

package/expertise/i18n/foundations/i18n-architecture.md

@@ -0,0 +1,272 @@
+# i18n Architecture — i18n/RTL Expertise Module
+
+> The foundational architecture for internationalization: separation of concerns, standards alignment, and design decisions that prevent technical debt. Getting this wrong means every subsequent i18n effort is fighting the codebase.
+
+> **Category:** Foundation
+> **Applies to:** All (Mobile, Web, Backend)
+> **Key standards:** Unicode, CLDR, BCP 47 (RFC 5646), ICU, W3C i18n
+> **RTL impact:** High — architecture must accommodate bidirectional layout from day one
+
+## 1. Core Concepts
+
+### What This Area Covers and Why It Matters
+
+Internationalization (i18n) is the design and development of software so it can be adapted for users from any culture, region, or language without engineering changes. Localization (L10n) is the actual adaptation of content and formats for a specific locale. Architecture determines whether i18n is a first-class concern or an expensive retrofit.
+
+**Why architecture matters:**
+- Retrofitting i18n costs **3–5× more** than building it in from the start
+- Every hardcoded string, format assumption, and layout direction creates debt
+- Poor architecture forces translators to work around code instead of with it
+
+### Fundamental Rules and Standards
+
+| Standard | Purpose |
+|----------|---------|
+| **Unicode** | Character encoding; every character has a code point; UTF-8 is the default encoding |
+| **CLDR** (Common Locale Data Repository) | Locale-specific data: plural rules, date/number formats, currency, collation |
+| **BCP 47** (RFC 5646) | Language tags: `en-US`, `ar-SA`, `zh-Hans-CN` — structure and lookup |
+| **ICU** (International Components for Unicode) | MessageFormat for plurals/gender/select; formatting APIs |
+| **W3C i18n** | Web-specific guidelines: HTML `lang`/`dir`, CSS logical properties, BiDi |
+
+### Common Misconceptions
+
+1. **"i18n is just translating strings"** — False. i18n encompasses text direction, number/date/currency formats, pluralization, gender agreement, collation, input methods, fonts, and layout. String translation is one slice.
+
+2. **"We'll add i18n later"** — The most expensive approach. Strings are embedded in components, formats are hardcoded, layouts assume LTR. Later = hunt-and-replace across the codebase.
+
+3. **"UTF-8 is enough"** — UTF-8 handles encoding. It does not handle RTL, pluralization, locale-specific formatting, or mixed-script text.
+
+4. **"One translation file per language"** — Flat files don't scale. Namespacing, lazy loading, and key organization matter.
+
+5. **"Machine translation will fix it"** — MT helps with volume; it does not fix architectural mistakes (concatenation, missing context, wrong plural forms).
+
+---
+
+## 2. Implementation Patterns
+
+### Separation of Concerns
+
+**Rule:** All locale-specific elements live outside application logic.
+
+| Element | Locale-Specific | Where It Lives |
+|---------|-----------------|----------------|
+| User-facing strings | Yes | Translation files (ARB, JSON, XLIFF, PO) |
+| Date formats | Yes | CLDR / `Intl.DateTimeFormat` |
+| Number/currency formats | Yes | CLDR / `Intl.NumberFormat` |
+| Plural rules | Yes | CLDR / ICU MessageFormat |
+| Layout direction | Yes | `dir` attribute, logical CSS, `Directionality` widget |
+| Collation (sort order) | Yes | `Intl.Collator` |
+| Font selection | Yes | Per-script font stacks |
+
+### Key Organization
+
+**Semantic naming, not positional:**
+
+```
+❌ button_1, screen_3_title, modal_close
+✅ auth.login.submit, dashboard.welcome.title, common.close
+```
+
+Keys are a three-party contract: systems, translators, and developers. Structure by feature domain:
+
+```
+locales/
+  en/
+    auth.json      → auth.login, auth.register, auth.forgotPassword
+    dashboard.json → dashboard.welcome, dashboard.stats
+    common.json    → common.save, common.cancel, common.loading
+  ar/
+    auth.json
+    ...
+```
+
+### Data Structures and Formats
+
+**ICU MessageFormat** — For complex messages (plurals, gender, select):
+
+```
+// Plural (Arabic has 6 forms)
+{count, plural, zero {لا رسائل} one {رسالة واحدة} two {رسالتان} few {# رسائل} many {# رسالة} other {# رسالة}}
+
+// Select (gender)
+{gender, select, male {قام بزيارة} female {قامت بزيارة} other {زار}} {place}
+```
+
+**Simple interpolation** — For straightforward strings:
+
+```
+"Hello, {{name}}!"
+"{{count}} items in cart"
+```
+
+**Never concatenate:**
+
+```
+❌ "You have " + count + " new messages"
+✅ t('messages.count', { count })  // "You have {count} new messages"
+```
+
+### Framework-Agnostic Patterns
+
+1. **Locale as explicit parameter** — Never infer locale from global state when formatting; pass it explicitly for testability.
+2. **Fallback chain** — `ar-SA` → `ar` → `en` (or project default).
+3. **Missing key policy** — Return key, return default, throw, or log — decide once and enforce.
+4. **Lazy loading** — Load locale data on demand; don't bundle all languages in the initial payload.
+
+### Code Examples
+
+**Dart (Flutter):**
+```dart
+// ARB file: app_en.arb
+"welcomeMessage": "Hello, {name}!",
+"@welcomeMessage": { "placeholders": { "name": {} } }
+
+"itemCount": "{count, plural, =0{No items} one{1 item} other{# items}}",
+"@itemCount": { "placeholders": { "count": {} } }
+
+// Usage
+Text(AppLocalizations.of(context)!.welcomeMessage('أحمد'))
+Text(AppLocalizations.of(context)!.itemCount(5))
+```
+
+**TypeScript (react-intl):**
+```tsx
+<FormattedMessage
+  id="welcomeMessage"
+  defaultMessage="Hello, {name}!"
+  values={{ name: 'أحمد' }}
+/>
+<FormattedMessage
+  id="itemCount"
+  defaultMessage="{count, plural, =0{No items} one{1 item} other{# items}}"
+  values={{ count: 5 }}
+/>
+```
+
+**Swift (iOS):**
+```swift
+String(format: NSLocalizedString("welcome_message", comment: ""), "أحمد")
+String(format: NSLocalizedString("item_count", comment: ""), count)
+// Use .stringsdict for plurals
+```
+
+**Kotlin (Android):**
+```kotlin
+getString(R.string.welcome_message, "أحمد")
+resources.getQuantityString(R.plurals.item_count, count, count)
+```
+
+---
+
+## 3. Locale Variations
+
+### Arabic
+- **Script:** Right-to-left, connected (cursive)
+- **Numerals:** Western Arabic (0123) and Eastern Arabic (٠١٢٣) — user or region choice
+- **Plurals:** 6 forms (zero, one, two, few, many, other)
+- **Calendar:** Gregorian and Hijri (Islamic)
+- **Example:** `ar-SA`, `ar-EG`, `ar-AE`
+
+### German
+- **Compound words:** Long (e.g., "Schlittschuhlaufen" vs "skating") — layout must accommodate 30%+ expansion
+- **Decimal:** Comma as separator (1.234,56)
+- **Date:** DD.MM.YYYY
+- **Example:** `de-DE`, `de-AT`, `de-CH`
+
+### Japanese / Chinese
+- **No spaces:** Word boundaries differ; line breaking is script-specific
+- **Vertical text:** Optional for Japanese
+- **Multiple scripts:** Japanese mixes Hiragana, Katakana, Kanji
+- **Example:** `ja-JP`, `zh-Hans-CN`, `zh-Hant-TW`
+
+### Hindi
+- **Complex conjuncts:** Devanagari script; conjunct formation affects rendering
+- **Counting:** Different number words (e.g., lakh, crore)
+- **Example:** `hi-IN`
+
+### Turkish
+- **Dotted vs dotless i:** `İ`/`i` vs `I`/`ı` — case conversion is locale-specific; `toUpperCase('i')` in Turkish yields `İ`, not `I`. Classic i18n bug.
+- **Example:** `tr-TR`
+
+---
+
+## 4. Anti-Patterns
+
+1. **String concatenation for sentences** — Breaks in every language with different word order. Use parameterized strings.
+
+2. **Hardcoded date formats** — `MM/DD/YYYY` is wrong for 96% of the world. Use `Intl.DateTimeFormat` or equivalent.
+
+3. **Assuming text length** — German ~30% longer, Chinese ~50% shorter. Design for expansion; avoid fixed-width containers.
+
+4. **Assuming left-to-right** — Arabic, Hebrew, Persian, Urdu are RTL. Use logical properties from day one.
+
+5. **Assuming single script** — Mixed content (e.g., English brand names in Arabic UI) requires BiDi handling.
+
+6. **English plural rule** — `count === 1 ? 'item' : 'items'` fails for Arabic (6 forms), Russian (3 forms), etc. Use ICU plural.
+
+7. **No locale in URLs/APIs** — Backend must know locale for formatting. Pass `Accept-Language` or explicit `locale` param.
+
+8. **Keys as English text** — `"Welcome back"` as key ties you to English. Use semantic keys: `auth.welcomeBack`.
+
+9. **Translating in the UI layer only** — Error messages, validation, API responses, logs shown to users must also be externalized.
+
+10. **Ignoring RTL in layout** — `margin-left`, `padding-right`, `text-align: left` break in RTL. Use `margin-inline-start`, `padding-inline-end`, `text-align: start`.
+
+11. **Single locale in backend** — User preference, not server default. Store and respect per-user locale.
+
+12. **No fallback for missing translations** — Show key or default locale; never blank or crash.
+
+13. **Synchronous loading of all locales** — Bundle size and memory. Lazy load by locale.
+
+14. **Concatenating format strings** — `"Date: " + format(date)` — the format itself may need reordering. Use complete messages.
+
+15. **Assuming ASCII for sorting** — Use `Intl.Collator` for locale-aware collation.
+
+---
+
+## 5. Testing Approach
+
+### Pseudo-Localization
+
+- Replace strings with expanded/accented versions to detect truncation and layout bugs
+- Example: `Hello` → `Ĥéļļö` or `[Héllo]` with brackets to detect untranslated strings
+
+### Character Coverage
+
+- Test with real Arabic (العربية), Hebrew (עברית), and CJK text
+- BiDi algorithm behaves differently with real text than with placeholders
+
+### Edge Case Locales
+
+- `ar-SA` (RTL, Arabic numerals, Hijri)
+- `de-DE` (long compound words)
+- `ja-JP` (no spaces, vertical text)
+- `tr-TR` (dotted i)
+- `hi-IN` (complex script)
+
+### Verification Checklist
+
+- [ ] All user-facing strings externalized
+- [ ] No concatenation for building sentences
+- [ ] Date/number/currency use locale APIs
+- [ ] Pluralization uses ICU/CLDR
+- [ ] RTL layout uses logical properties
+- [ ] Missing keys have defined fallback
+
+---
+
+## Quick Reference Checklist
+
+- [ ] Strings extracted from day one; no hardcoded user-facing text
+- [ ] Keys are semantic; structure by feature domain
+- [ ] ICU MessageFormat for plurals, gender, select
+- [ ] No string concatenation for sentences
+- [ ] Date/number/currency via `Intl` or platform equivalent
+- [ ] Layout uses logical properties (start/end, not left/right)
+- [ ] Locale passed explicitly; fallback chain defined
+- [ ] Missing keys handled; no blank or crash
+- [ ] Lazy load locale data
+- [ ] Test with real Arabic/Hebrew and pseudo-localization
+
+---
+*Researched: 2026-03-08 | Sources: W3C i18n (w3.org/International), CLDR/ICU, BCP 47 (RFC 5646), IntlPull ICU MessageFormat guide, Locize/EzGlobe i18n anti-patterns*