Instruction file imported from KickBoxingCats/Oryx-Mobile (.github/instructions/translation.instructions.md). Copyright stays with the author.

Flow Translation Instructions (Generic)

Follow this workflow whenever you add or update user-facing text for any flow.

Runtime Input

When using this instruction, the prompt should include:

1. Flow name: FLOW_NAME (for example: auth, onboarding, student main, mentor main).
2. Optional route scope: FLOW_ROUTE_GLOB (for example: src/app/(auth)/** or src/app/(mentor)/(main)/**).
3. Optional screen scope: FLOW_SCREEN_GLOB (for example: src/components/screens/auth/**).

If exact file paths are not provided, infer them from the route and screen structure before editing.

Scope Resolution Rules

1. Apply translation updates only to files relevant to FLOW_NAME.
2. Prioritize these areas when present:

• Route files under FLOW_ROUTE_GLOB.
• Screen components under FLOW_SCREEN_GLOB.
• Flow-specific validation/schema files.
• Translation resources that compose app locales.

3. Keep changes minimal and avoid unrelated refactors.

Required Translation Structure

1. Add or update keys in English and Arabic resources with matching shape.
2. Keep composer files as composers; place flow-specific keys in flow-specific resource modules when that pattern exists.
3. Use a stable namespace rooted at FLOW_NAME.
4. Prefer nested semantic groups:

• FLOW_NAME.common
• FLOW_NAME.fields
• FLOW_NAME.actions
• FLOW_NAME.
• validation

In-Component Usage Rules

1. Use tx for Text and Button whenever possible.
2. Use labelTx and placeholderTx for Input/ControlledInput fields.
3. Avoid hardcoded user-facing strings in route and screen files for FLOW_NAME.
4. Keep brand names unchanged unless explicitly requested.
5. For accessibility text (for example accessibilityLabel), use translate("...") with a key.

Validation Message Rules

1. Use translate("validation...") for user-facing validation messages.
2. Avoid hardcoded validation sentences.
3. Ensure every validation key exists in both English and Arabic resources.

Key Naming Conventions

1. Use stable semantic keys, not sentence-as-key.
2. Keep action keys under FLOW_NAME.actions.
3. Keep form fields under FLOW_NAME.fields..label|placeholder.
4. Keep route copy under matching namespaces, such as FLOW_NAME..title.

Completion Checklist

1. No hardcoded user-facing strings remain in touched files for FLOW_NAME.
2. Every new key exists in both English and Arabic resources with matching structure.
3. Updated screens/components use tx/labelTx/placeholderTx/translate consistently.
4. Validation messages are translation-driven.
5. Changes preserve RTL behavior and existing flow logic.

Icon Direction Rules

1. Directional icons must follow the active language direction.
2. In LTR, keep icon directions as defined by the icon set.
3. In RTL, mirror left/right directional icons.
4. Apply this to ArrowLeft, ArrowRight, ChevronLeft, and ChevronRight.
5. Do not hardcode one visual direction for shared directional icons.
6. Use i18n direction (RTL/LTR) as the single source of truth.

Examples:

• LTR: ArrowLeft points left and ArrowRight points right.
• RTL: ArrowLeft is mirrored to point right and ArrowRight is mirrored to point left.