sina_sajjadi
/
marriage
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
280 Commits
3 Branches
0 Tags
46 MiB
 
 
 
 
 
Branch: master
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'master'
${ noResults }
marriage/.agents/AGENTS.md

2.6 KiB
Raw Permalink Blame History

This is NOT the Next.js you know

This version has breaking changes — APIs, conventions, and file structure may all differ from your training data. Read the relevant guide in node_modules/next/dist/docs/ before writing any code. Heed deprecation notices.

Translations and Locale Management Rule

  • All translation files must be located in src/translations/ (NOT src/i18n/).
  • Inside src/translations/locales/, there are NO subdirectories. Each language has a single, flat key-value JSON file (ar.json, az.json, bn.json, zh.json, da.json, de.json, en.json, es.json, fa.json, fr.json, gu.json, ha.json, he.json, hi.json, id.json, ks.json, pt.json, ru.json, sw.json, tg.json, tr.json, ul.json, ur.json, uz.json).
  • 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.