i18n-readylisted

# Internationalization ready Generated UI is English-shaped. Strings are baked into components, plurals are a ternary, dates are `toLocaleDateString()` with no locale, and every margin is `margin-left`. All of it works, right up to the day someone asks for a second language, and then it is a rewrite instead of a translation. The cost of fixing this is roughly ten times higher after launch than during. That is the entire argument for this skill. ## Scan first ```bash node "${CLAUDE_PLUGIN_ROOT}/skills/i18n-ready/scripts/i18n-scan.mjs" . ``` It finds hardcoded user-facing strings, ternary pluralization, physical CSS properties, and locale-naive formatting. `--json` for machine output. Read `references/rules.md` for the full rule set with fixes. ## The four failures, in order of cost ### 1. Hardcoded strings ```jsx <button>Save changes</button> ``` Every literal in JSX that a user reads is a string that has to be found and extracted later, by hand, across the whole codebase. ```jsx <button>{t('settings.save')}</button> ``` Do this while writing, not after. Extraction is the expensive part, not translation. ### 2. Pluralization by ternary ```jsx {count === 1 ? 'item' : 'items'} ``` This is correct in English and wrong in most of the world. Russian has three plural forms, Arabic has six, Japanese has one, Polish has four and the rule depends on the last two digits. A ternary cannot express any of that. ```jsx {t('cart.items', { count })} ``` Let the i18n library a