القائمة
Internationalizes and localizes products — strings, locales, formats, RTL, and translation workflow. Use when adding languages, fixing locale bugs, or expanding to non-English markets.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | i18n-l10n |
| description | Internationalizes and localizes products — strings, locales, formats, RTL, and translation workflow. Use when adding languages, fixing locale bugs, or expanding to non-English markets. |
English-only caps your market. i18n (internationalization) makes the app locale-ready; l10n (localization) delivers each language correctly — including dates, numbers, currency, and layout direction.
Pairs with [[ui-craft]] for UI implementation, [[accessibility]] for RTL and language attributes, [[technical-writing]] for translated docs, and [[test-first]] for locale-specific tests.
Skip for internal English-only tools with documented scope.
| Approach | Best for |
|---|---|
| Key-based JSON/PO files | Web (react-i18next, next-intl) |
| Platform native (Android strings.xml, iOS Localizable.strings) | Mobile |
| DB-backed strings | CMS-heavy, frequent copy changes |
Rule: no user-facing string literals in components after i18n pass.
namespace.feature.element
auth.login.title
auth.login.submit
errors.network.timeout
"Hello, {{name}}"Centralize:
Test with de-DE, ja-JP, ar-SA at minimum.
dir="rtl" on <html> or root when locale is RTL[[!!]])"Hello " + nameMeta-skill that routes a task to the right engineering skill. Load this at the start of a session or when unsure which skill applies — it maps intent to the process that should govern the work.
Catches breaking changes between services before they ship, by testing the contract each consumer actually depends on instead of spinning up the whole system. Use when services deploy independently, when a provider API change could break a consumer, or when end-to-end integration tests are too slow and flaky to guard every service boundary.
Proves whether a change actually moves the metric, with a valid A/B test instead of a guess — a hypothesis, a primary metric, a pre-computed sample size, guardrail metrics, and an honest readout. Use when shipping a change meant to improve a number (conversion, retention, performance), running an A/B or holdout, or deciding whether a feature "worked."
Decouples deploy from release using feature flags — ship code dark, roll out gradually, kill instantly, and remove the flag once it's done. Use when releasing risky or large changes, rolling out by percentage/cohort, delivering A/B variants, or when stale flags are accumulating as debt.
Finds security risks at design time — before code exists — by mapping the system, enumerating how it could be attacked, and deciding what to do about each threat. Use when designing a feature that touches auth, data, money, or external input, when changing a trust boundary, or when a security-sensitive change needs a structured risk pass rather than a code-level review.
Designs durable, curated memory that an agent carries across sessions — what to persist, how to scope and retrieve it, and how to stop it from drifting or poisoning later runs. Use when an agent needs to remember decisions, preferences, or project facts beyond one context window, or when stale/over-generalized memory is corrupting its behavior.