# 2. Localization

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*

---

## 2. Localization

### 2.1 Configure Supported Interface Languages
**What it does:** Defines which languages the platform interface and communications are available in. The Super Administrator enables or disables interface languages platform-wide, sets the default, and tracks translation coverage so users can choose their language and the platform knows where translations are complete or pending.

**Sub-features:**
- Enable/disable interface languages platform-wide
- Default language setting (applied when a user has no preference)
- Per-user language preference (users choose from the enabled set)
- Translation coverage view: per language, the share of interface strings and templates translated
- Pending-translation tracking with routing to the translation process
- Content-language distinction: interface language is separate from content/course language
- Audit logging of language configuration changes

**Super Administrator User Journey:**
1. The platform expands into a new region. Super Admin opens Localization and enables the new language in the interface language set.
2. Sets the default language appropriately for the region (or keeps the global default; users can still choose).
3. Reviews the translation coverage for the new language: 60% of interface strings translated, 40% pending. The pending set is routed to the translation process.
4. As translations land, the coverage view updates; at 100%, the language is fully available.
5. Before full coverage, the platform falls back to the default language for untranslated strings (no missing/garbled text).
6. Users in the region choose the new language in their preferences; their interface renders in it (with fallback where a string is untranslated).
7. For email templates, the language variants follow the same coverage tracking (see Platform Branding).
8. The language configuration change is audit-logged with the languages enabled/disabled and the timestamp.

**Rules & Edge Cases:**
- A disabled language is not offered to users; existing user preferences in a disabled language fall back to the default.
- Untranslated strings fall back to the default language; they are never shown blank or as keys.
- Translation coverage is tracked per language and per surface (interface, templates), so gaps are visible.
- Interface language is distinct from content language: a course's language is a content attribute, not the interface setting.
- The default language applies only when a user has no preference.
- Language configuration changes are audit-logged.

### 2.2 Configure Default Currency and Multi-Currency Support
**What it does:** Sets the platform's default currency and enables multi-currency operation: which currencies are supported, how prices are expressed per currency, and how amounts are displayed and processed for users in different currency contexts. It underpins pricing, billing, and financial display across the platform.

**Sub-features:**
- Default currency setting (the platform's base currency)
- Supported currency list (enable/disable currencies)
- Per-currency price expression (prices defined per currency where multi-currency is on)
- Display rules: amounts shown in the user's/context's currency
- Exchange-rate handling: rate source and update cadence for cross-currency display
- Consistency: billing, receipts, and financial views use the configured currencies
- Audit logging of currency configuration changes

**Super Administrator User Journey:**
1. The platform operates in one market with a single currency. Super Admin confirms the default currency is set correctly and only that currency is enabled.
2. For a multi-currency expansion, Super Admin enables the additional currencies in the supported list.
3. Sets the exchange-rate handling: the rate source and the update cadence (e.g., daily), so cross-currency displays are current.
4. Reviews the price expression: prices are defined per currency for the markets that use them (a plan has a price in each supported currency where sold).
5. Checks the display rules: a user in currency context A sees amounts in A; the financial views show the base currency with per-currency breakdowns.
6. Verifies a receipt and a financial view render in the correct currencies with the current rates.
7. For a rate update, the cadence applies automatically; Super Admin reviews the rate-change log for anomalies (a sharp move is investigated).
8. The currency configuration change is audit-logged with the currencies enabled and the rate handling, and the timestamp.

**Rules & Edge Cases:**
- The default (base) currency is the platform's accounting currency; per-currency display is derived from it via rates.
- A disabled currency is not used for new pricing; existing amounts in it are handled per the transition plan.
- Exchange rates have a defined source and cadence; they are not manually editable ad hoc (changes are logged).
- Prices are expressed per currency where multi-currency is on; there is no implicit auto-pricing without a defined rate.
- Billing, receipts, and financial views are consistent with the currency configuration.
- Currency configuration changes are audit-logged.

### 2.3 Configure Time Zones
**What it does:** Sets the platform's time-zone handling: the default time zone for system displays and scheduling, and the per-user/per-context time zone so times (schedules, deadlines, logs) are shown in the viewer's context. It ensures time-based features (scheduling, deadlines, reporting) are correct for users in different regions.

**Sub-features:**
- Default system time zone (for displays and scheduling where no context applies)
- Per-user time zone preference (set at registration or in preferences)
- Per-context time zone (e.g., an institute's time zone for its schedules)
- Display rules: times rendered in the viewer's/context's time zone
- Scheduling correctness: a scheduled event is anchored in absolute time and displayed per viewer
- Deadline and reporting time-zone consistency
- Audit logging of time-zone configuration changes

**Super Administrator User Journey:**
1. The platform serves users across regions. Super Admin confirms the default system time zone is set (the operating base) and that per-user time zones are captured at registration.
2. Reviews a user's preference: a user in region X has their time zone set; their interface shows times in X.
3. For an institute, sets the institute's context time zone so its schedules and deadlines display correctly for its staff and students.
4. Checks a scheduled event: it is anchored in absolute time; a viewer in region X sees the local X time, a viewer in region Y sees the local Y time — the same event, correctly rendered for each.
5. Verifies deadlines: a course deadline displays in the student's time zone, and the enforcement uses the absolute anchor (no off-by-region errors).
6. Reviews reporting: date-boundary reports use the configured time zone consistently (a "daily" report boundary is well-defined).
7. For a user who moves regions, their time zone preference is updated (self-service or admin), and their displays follow.
8. The time-zone configuration change is audit-logged with the setting changed and the timestamp.

**Rules & Edge Cases:**
- Times are anchored in absolute time; time zones affect display, not the underlying instant.
- A missing per-user time zone falls back to the default system time zone.
- Scheduling and deadline enforcement use the absolute anchor, so time-zone display never changes when something happens.
- Reporting date boundaries use a defined time zone, so "daily" and "monthly" are unambiguous.
- Per-context (institute) time zones apply to that context's schedules and displays.
- Time-zone configuration changes are audit-logged.