Mena product localization

MENA Product Localization

When To Use

Use this skill for product, UX, checkout, form, and UI localization work for Arabic or mixed Arabic-English products in MENA markets.

When Not To Use

• Do not process live payments, refunds, payouts, tax submissions, identity checks, or production customer-data changes.
• Do not invent payment availability, VAT rules, national ID rules, legal requirements, endpoint URLs, credentials, or compliance claims.
• Route payment implementation to mena-payments, tax/e-invoicing to arab-einvoicing-tax, logistics/address validation to mena-logistics, and identity/government ID work to arab-identity-gov.

Required Context

• Target country or locale, such as ar-SA, ar-AE, ar-EG, or cross-MENA.
• Surface type: app UI, checkout, form, dashboard, notification, policy, invoice summary, or support flow.
• Audience, channel, and risk level.
• Whether payments, tax, identity, delivery, payroll, or regulated customer data is involved.
• Sandbox vs production state if reviewing an implementation.

Common Workflows

• Review RTL, bidi isolation, logical layout, Arabic fonts, focus order, and mixed-direction values.
• Review Arabic copy, pluralization, numerals, dates, calendars, currency, VAT labels, and checkout messages.
• Review phone, address, name, title, gender, and national-ID fields for data minimization and country fit.
• Create a localization launch checklist with source-backed facts, assumptions, unknowns, and review gates.

Default Workflow

1. Read sources.yml and the reference file matching the request.
2. Capture country, locale, audience, surface, channel, and high-risk domains before making regional claims.
3. Use CLDR/Intl, Unicode bidi, W3C i18n, libphonenumber, and libaddressinput where applicable.
4. Mark legal, tax, payment, identity, and market-preference claims as Unknown from public docs unless a cited source or expert review supports them.
5. Use the scripts for deterministic examples or linting when reviewing files.
6. Answer with source-backed facts, assumptions, unknowns, validation steps, and review gates.

Decision Tree

• RTL or mixed text: read references/rtl-ux.md and references/bidi-text.md.
• Arabic wording: read references/arabic-ui-copy.md and require native review for public or high-impact copy.
• Forms: read phone, address, names, and calendar references as needed.
• Checkout or money display: read references/checkout-localization.md and references/currency-and-vat.md, then route regulated payment or tax implementation to the owning skill.
• Broad product launch: read references/product-localization-checklist.md.

Response Contract

• Start by naming skills/mena-product-localization/SKILL.md and the reference files used.
• Separate source-backed facts, implementation recommendations, assumptions, and unknowns.
• Include confidence labels for regional claims.
• Include native/expert review gates for Arabic copy, legal/tax/payment/identity content, and public campaigns.
• Include validation checks for sandbox/test and production readiness.
• Never provide live-action instructions that move money, tax documents, identity data, payroll data, customer data, or outbound messages without explicit human approval.

Source And Confidence Rules

• High-confidence claims require public sources or completed review evidence.
• Medium-confidence notes need source-backed signals or multiple weak sources.
• Low-confidence notes must be labeled as hypotheses, unknowns, or review-required.
• Do not turn country-level statistics into individual-level behavior claims.

Anti-Stereotype Rules

• Never assign traits to nationality, religion, ethnicity, dialect group, gender, age, or income group.
• Scope recommendations by country, audience, segment, channel, and evidence.
• Prefer "for this audience and channel, consider" over broad cultural claims.

Output Rules

• Give practical drafts, plans, templates, checklists, or QA steps.
• Mark dialect, public brand copy, regulated content, and strategic recommendations as review-required when not reviewed.
• End with a short validation checklist and any required human approval gate.

Files To Read

• Routing and process: SKILL.md.
• Source map: sources.yml.
• Topic references: references/*.md.
• Review example: examples/product-localization-review.md.
• Compatibility example: examples/source-backed-answer.md.
• Deterministic helpers: scripts/rtl_copy_lint.js, scripts/locale_format_examples.js, scripts/phone_format_examples.js.

Safety Rules

• Keep canonical stored data separate from localized display.
• Use sandbox/test environments before production changes.
• Protect secrets, credentials, customer addresses, phone numbers, national IDs, and payment references.
• Require explicit approval before publishing, sending, launching, changing checkout/payment copy, or changing production localization behavior.
• Use retries and idempotency for any integration-adjacent workflow that writes orders, addresses, payments, or tax artifacts.

Validation Checklist

• Locale, country, channel, and audience are explicit.
• Unknowns are labeled as Unknown from public docs or Needs vendor access.
• RTL and bidi behavior are tested with mixed Arabic/LTR values.
• Arabic plural, date, number, phone, address, and currency examples are tested.
• High-risk domains are routed to the owning skill and reviewed before production.
• Evals in evals/prompts.yml still cover the changed behavior.

Done Criteria

• The answer names files read and sources used.
• Recommendations distinguish source-backed facts from assumptions.
• The output includes practical checks, review gates, and no unsupported legal, tax, payment, identity, pricing, or endpoint claims.