@ -10,3 +10,12 @@ This version has breaking changes — APIs, conventions, and file structure may
- Registration form structure data is kept separately in `src/data/questions/`.
- CRITICAL AUTOMATION RULE: Whenever any new static text, data, field, component label, tooltip, help description, key, or text item is added or updated in the project, its translation key and values MUST automatically be added/updated in ALL 24 locale JSON files (`src/translations/locales/` &`src/data/questions/`).
- QUESTION HELP & TOOLTIPS RULE: All question help texts, tooltips, and modal descriptions must be stored with key-value entries in the respective locale JSON files, ensuring complete synchronization across all supported languages.
# Logic and UI Language Separation Rule (Language-Agnostic Contract)
- **Goal**: Create a language-agnostic contract between frontend and backend for field mappings and logic.
- **Strict Logic Isolation**: Program logic (e.g. conditional visibility, backend validations, validations, and step progressions) MUST NEVER depend on localized UI strings/labels (e.g., Farsi or Arabic text).
- **System Keys Usage**: All business logic and API payloads must rely exclusively on fixed English identifiers called **System Keys** (e.g., `email`, `phone_number`, `marital_status`).
- **Frontend Role**: When submitting data, the frontend must send values associated only with these fixed System Keys. The localized view the user interacts with (Persian, Arabic, Turkish, etc.) is strictly for presentation.
- **Backend Role**: All DB operations, validation rules, condition checks, and calculations must be run exclusively on the System Keys. The backend must never receive, process, or validate display labels.
- **i18n Mapping**: Localization/localization translation is handled solely in the frontend presentation layer via translation keys/files (e.g., `en.json`, `fa.json`, `ar.json`) mapping back to the same System Keys.