@ham2k/extension-sdk 0.1.0

package/dist/i18n.js

@@ -0,0 +1,43 @@
+import i18next from "i18next";
+function createCachedTranslator(resources) {
+  let cachedLocale;
+  let cachedT;
+  return (ctx) => {
+    const locale = ctx.locale ?? "en";
+    if (!cachedT || cachedLocale !== locale) {
+      cachedLocale = locale;
+      cachedT = createTranslator(resources, locale);
+    }
+    return cachedT;
+  };
+}
+function createTranslator(resources, currentLocale) {
+  const instance = i18next.createInstance();
+  instance.init({
+    lng: currentLocale,
+    fallbackLng: "en",
+    resources,
+    // Explicit because the engine has no Intl. i18next's PluralResolver
+    // probes for Intl.PluralRules, does not find it under QuickJS-NG, and logs
+    // "Your environment seems not to be Intl API compatible" through the host
+    // log on EVERY translator build — and createCachedTranslator builds one per
+    // extension per locale, so that is live noise on every platform.
+    //
+    // Declaring v3 makes the supported plural shape a decision rather than a
+    // silent fallback. It is inert for correctness today: no catalog uses a
+    // plural-suffixed key in either shape, and no call
+    // site passes `count` to t() — the one place that needs a plural spells it
+    // out with a ternary (core/scoring/src/scoring.ts). If a catalog ever does
+    // want plurals, v3's `key`/`key_plural` pair is what will work here.
+    compatibilityJSON: "v3",
+    interpolation: {
+      escapeValue: false
+      // Not in a browser/HTML environment
+    }
+  });
+  return (key, options) => instance.t(key, options);
+}
+export {
+  createCachedTranslator,
+  createTranslator
+};