add text input validation

input-validation-plan.md

@@ -54,3 +54,68 @@ Only touch the files responsible for these fields: the form component(s), the AP
 - Confirm each rule above has a corresponding check in frontend AND backend (list them field by field in your report).
 - Confirm existing tests still pass; add new tests only for the fields touched here.
 - Report any field where the existing DB column type/length conflicts with the rule above, rather than silently changing it.
+
+
+# Task: Add Language-Aware Input Handling (EN / FR / AR)
+
+## Objective
+Each record has ONE selected language (EN, FR, or AR). Free-text fields are typed and stored in that language's script. Add a `language` field to the record, validate free-text fields against the script rules for the selected language, and handle RTL display for Arabic. This extends `input-validation-plan.md` — do not redo work already covered there; only add what's described here.
+
+## Scope
+Touch only: the form component(s) already handling these fields, the language selector (add one if it doesn't exist), the validation schema from the previous task, the API endpoint(s), and the DB column for storing the selected language. Do not touch fields/logic unrelated to language handling.
+
+---
+
+## 1. Data model change
+- Add a `language` column/field to the record: enum, one of `en`, `fr`, `ar`. Required, no default — must be explicitly selected (unless the project already has a default locale convention; ask if unsure).
+- This is a single value per record, not per field. All free-text fields in that record are assumed to be in this language/script.
+
+## 2. Which fields are affected
+Only **free-text, human-language fields** are language/script-dependent:
+- firstName, lastName, address, city
+
+These are **not** language-dependent — keep exactly as specified in `input-validation-plan.md`, do not add script validation to them:
+- email, phoneNumber, driverLicense, idPassport, vinNumber, amount, all dates, nationality, country
+
+`nationality` and `country` stay as ISO codes regardless of selected language — only their *displayed label* is translated (a UI/i18n concern, not a data validation concern). Do not store translated country names as the value.
+
+## 3. Script validation per language
+Update the charset rule for firstName, lastName, address, city based on the record's `language` value:
+
+| Language | Allowed script | Notes |
+|---|---|---|
+| en | Latin (a-z, A-Z), spaces, hyphens, apostrophes | Same as current rule in input-validation-plan.md |
+| fr | Latin + French diacritics (à, â, ç, é, è, ê, ë, î, ï, ô, œ, ù, û, ü, ÿ, etc.), spaces, hyphens, apostrophes | Do not reject accented characters |
+| ar | Arabic script (Unicode range `\u0600-\u06FF` and `\u0750-\u077F` for extended Arabic), spaces, standard Arabic punctuation | Do not force Latin transliteration |
+
+Implement this as a per-language regex/charset map, not a single hardcoded regex — so a future 4th language is a config addition, not a rewrite. Length limits (50 for names, 255 for address, 85 for city) stay the same as `input-validation-plan.md` regardless of language — do not add or remove digits from those limits.
+
+Do not attempt to auto-detect the language from the text itself — the `language` field is user-selected and is the source of truth for which validation rule applies.
+
+## 4. Frontend
+- Add a language selector if one doesn't already exist (dropdown or toggle: EN / FR / عربي).
+- When `ar` is selected, apply `dir="rtl"` to the affected text inputs (firstName, lastName, address, city) and their containing form section. Do not flip the entire page layout unless explicitly asked — scope this to the form only.
+- Switch the input validation pattern (`pattern` attribute / live validation) to match the table above based on the current language selection.
+- If the project already has an i18n/translation library in use (e.g. i18next, react-intl), use it for labels and error messages. Do not introduce a new i18n library if one already exists.
+
+## 5. Backend
+- Validate `language` is one of `en`/`fr`/`ar`.
+- Apply the matching charset rule from the table above to firstName, lastName, address, city based on the submitted `language` value — reject if the text doesn't match the selected language's script (don't silently strip characters).
+- Store the text as submitted (UTF-8), no transliteration or normalization beyond standard Unicode NFC normalization (consistent with the rest of the validation plan).
+
+## 6. Database
+- Ensure the column encoding/collation supports UTF-8 fully (`utf8mb4` if MySQL; Postgres is UTF-8 by default) — Arabic and accented French characters will break under older `utf8`/`latin1` collations. Only change this if it's actually currently a problem; check first, don't assume.
+- Add the `language` column via migration if it doesn't exist. Do not alter unrelated columns in the same migration.
+
+## Explicitly out of scope (ask before doing)
+- Translating the actual stored data between languages (e.g. auto-translating an English name to Arabic) — this task is about validating/storing what the user typed, not translation.
+- Full-page RTL layout changes beyond the form fields listed.
+- Adding a new i18n library if the project doesn't already have one — flag and ask which one to use.
+- Any language beyond en/fr/ar.
+- Changing how nationality/country are stored (they remain ISO codes).
+
+## Validation before reporting done
+- Confirm each of firstName/lastName/address/city is validated against the correct script for the selected `language` value, in both frontend and backend.
+- Confirm `language` is required and validated as an enum.
+- Confirm DB encoding supports Arabic/French characters (test by saving a record with Arabic text and reading it back unchanged).
+- Confirm unrelated fields (email, phone, VIN, dates, amount, nationality, country) are untouched by this change.