rich1.0cloud fodder (npub10n…ztl5h)https://nostr.now/npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5hnjumphttps://nostr.nowMy clanker has some suggestions. I told him to give you these, in 2 paragraphs, so that your clanker can start down the i18n path if you want :) I was too lazy to give him or ask him to do the githubs. Haha. But, pretty sure you could add i18n and then you'd have some translation capability. ``` Add one new file, `i18n.js`, loaded before any other script on every extension page (and importable by the service worker). It defines three globals in which the English source string is itself the lookup key: `t('Allow once')` with optional `{placeholder}` interpolation via a second object argument; `tc('context', 'Active')` for the same English in two meanings; and `tp(n, '{count} relay', '{count} relays')`, which selects a CLDR category through `Intl.PluralRules` so Polish and Arabic can supply more than English's two forms. Interpolation must use `{name}`, never `${}`, so a catalog can never be evaluated as code. It also exposes `I18N.apply(root)`, a single DOM pass translating any element carrying `data-i18n` (the element's own text is the key, cached on the node so a language switch re-translates from English rather than from a translation) and `data-i18n-attr="placeholder,title"` for attributes; and `I18N.setLocale(tag)`, which fetches `locales/<tag>.json`, falls back from region to base language (`de-AT`→`de`), and degrades to English on any miss. Separately, set `"default_locale": "en"` in `manifest.json`, replace its `name`, `description` and action `default_title` with `__MSG_*__` references, and add `_locales/en/messages.json` — this is the native `chrome.i18n` path and the only thing that localizes a store listing, so it stays alongside the hand-rolled layer rather than being replaced by it. Then the supporting pieces. `scripts/i18n-extract.js` greps `t(`/`tc(`/`tp(` call sites and `data-i18n` markup into `locales/_source.json`, the string inventory, counting non-literal call sites rather than silently dropping them; `scripts/i18n-pseudo.js` turns that inventory into `locales/qps-ploc.json`, a pseudo-locale that accents every letter and pads ~35%, deterministically so regeneration produces no diff churn. Translation catalogs are plain `{"English": "translation"}` JSON, with plural entries keyed `one|||other` mapping to a per-category object, and an empty string meaning "fall back to English". Wire both into `package.json` as `i18n:extract`/`i18n:pseudo`, and add a CI workflow that runs `npm test` plus regenerates the catalogs and fails on `git diff --exit-code -- locales/`. Two constraints an implementer will hit immediately: `data-i18n` assigns `textContent` and therefore deletes child elements, so any sentence wrapped around an input needs its text moved into its own `<span data-i18n>`; and several existing tests regex English literals straight out of source to assert copy parity between surfaces, so their patterns need to tolerate the `t(...)` wrapper — expect a handful to break with every extraction wave, which is precisely why the suite belongs in CI before the bulk conversion starts. ```