tarjmni

name	tarjmni
description	Use when translating, localizing, or adapting any website, web app, mobile app, native Android/iOS app, Flutter app, or agent-managed project into Arabic, Arabic dialects, RTL layouts, or Arabic language switchers. Use for Modern Standard Arabic, Tunisian, Moroccan, Algerian, Egyptian, Saudi, or Palestinian Arabic.

Tarjmni

Tarjmni helps agents localize software into Arabic and Arabic dialects with reviewable, framework-aware changes.

Use this skill when the user asks to:

• Translate an app, site, or codebase into Arabic or an Arabic dialect.
• Add Arabic locales, RTL support, or a language switcher.
• Convert hardcoded UI strings into i18n keys.
• Review Arabic/dialect translation quality.
• Adapt localization across React, Next.js, Vue, Angular, Svelte, Android, iOS, Flutter, React Native, Laravel, Rails, Django, static HTML, or unknown stacks.

Core Rules

1. Start with an intake question when the target locale is missing. Do not assume Tunisian, MSA, or all Arabic variants.
2. Present a short plan and wait for user approval before modifying files.
3. Prefer the existing i18n system. Detect before adding new libraries.
4. Do not blindly translate code. Scan, classify context, protect placeholders, then translate.
5. Keep Arabic dialect review required unless the user explicitly accepts machine-only output.
6. Preserve variables, ICU tokens, printf tokens, HTML tags, links, brand terms, and product names.
7. Apply RTL support with layout awareness, not only text replacement.
8. If a language switcher exists, extend it. If none exists, propose a dry-run before adding one.
9. Summarize all changed files and remaining QA risks.

Intake Gate

If the user has not clearly provided the target Arabic variant, ask one concise question before scanning or editing:

Which Arabic target do you want first: ar, ar-TN, ar-MA, ar-DZ, ar-EG, ar-SA, ar-PS, or all?

If the user has not said whether to change code or only report, ask:

Should I only analyze and plan, or should I apply changes after showing the plan?

Do not run translation, add i18n libraries, inject switchers, or edit files until the user answers enough to choose scope.

Agent Workflow

After the intake answer, run detection and planning first:

tarjmni detect --json
tarjmni scan --json
tarjmni switcher detect --json

Then present a plan containing:

• Detected framework/platform
• Existing i18n system, if any
• Target locale(s)
• Files likely to change
• Whether a switcher exists
• RTL/QA risks
• The exact Tarjmni commands you will run

Wait for approval. After approval, continue:

tarjmni init --source <source-locale> --targets <approved-locales>
tarjmni translate --to <approved-locales> --dry-run
tarjmni switcher add --dry-run
tarjmni qa --rtl --json

Then decide what to edit based on the project type and existing localization setup.

Use --json when you need machine-readable output. Use --dry-run before UI injection or broad file changes. Only remove --dry-run after the user approves the plan.

Supported Locales

Default target set:

• ar: Modern Standard Arabic
• ar-TN: Tunisian Arabic
• ar-MA: Moroccan Arabic
• ar-DZ: Algerian Arabic
• ar-EG: Egyptian Arabic
• ar-SA: Saudi Arabic
• ar-PS: Palestinian Arabic

Read references/locales.md before producing dialect-specific output.

Project Handling

Detection priority:

1. Existing locale files and i18n libraries
2. Framework or platform
3. Source-code text extraction
4. Language switcher and RTL support
5. QA gaps

Read references/framework-detection.md when detection is ambiguous.

Translation Quality

Before translating, collect:

• Source text
• UI context
• Tone
• Placeholder list
• Glossary or locked product terms
• Target locale
• Review status

Read references/dialect-quality.md for the translation review process.

i18n Adapters

Tarjmni is not tied to one i18n library. It should adapt to the project:

• Next.js: prefer existing setup; otherwise next-intl
• React/Vue/Svelte/Angular: prefer existing setup; otherwise JSON/i18next-style files
• Android: strings.xml
• iOS: Localizable.strings and .stringsdict
• Flutter: .arb
• Backend frameworks: native locale files when present

Read references/i18n-adapters.md before adding or changing i18n infrastructure.

Language Switcher

If the user asks for Arabic to be visible in the UI:

1. Run tarjmni switcher detect --json.
2. If found, extend the existing switcher.
3. If not found, run tarjmni switcher add --dry-run.
4. For web, place it in the top navigation by default.
5. For native/mobile, prefer Settings unless the app already has onboarding locale selection.

Read references/switcher-injection.md before modifying UI.

QA

Always run or simulate:

tarjmni qa --rtl --json

Check missing translations, placeholder mismatches, untranslated English, RTL direction, layout overflow, and pluralization. Read references/rtl-qa.md for visual QA rules.