{"type":"rich","version":"1.0","title":"cloud fodder wrote","author_name":"cloud fodder (npub10n…ztl5h)","author_url":"https://nostr.now/npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h","provider_name":"njump","provider_url":"https://nostr.now","html":"My 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.\n\n```\nAdd 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/\u003ctag\u003e.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.\n\nThen 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 `\u003cspan data-i18n\u003e`; 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.\n```"}