@authup/i18n 1.0.0-beta.49 → 1.0.0-beta.50

package/dist/error.d.ts

@@ -7,16 +7,15 @@
  * (`TranslatorTranslationNamespace.ERROR`, value `authupError`) — a
  * *sibling* of validup's own `validup` namespace rather than merged into
  * it, so `@ilingo/validup-vue`'s install can't overwrite authup codes
- * (and vice versa). `translateError()` (in `@authup/client-web-kit`,
- * wired in a later phase) resolves a server error's `code` + `data`
- * against this namespace.
+ * (and vice versa). `useErrorTranslator()` (in `@authup/client-web-kit`)
+ * resolves a server error's `code` + `data` against this namespace.
  *
  * The catalog is keyed by `@authup/errors`' `ErrorCode` values. The
  * `AuthupErrorData` map below is the typed *producer* contract — the
  * structured data each code may carry on the wire — and the
  * `declare module 'validup'` block augments validup's `IssueDataByCode`
  * wherever this package is imported. Today that is the client only
- * (`@authup/client-web-kit` re-exports this module, so `translateError()`
+ * (`@authup/client-web-kit` re-exports this module, so `useErrorTranslator()`
  * and any client-side issue construction get the typed `data`). It does
  * **not** reach server-side producers: `apps/server-core` does not depend
  * on `@authup/i18n`. If typed `defineIssueItem` / `createValidupError`
@@ -29,11 +28,12 @@
  * `{{param}}`), not because the data is unavailable but because ilingo's
  * `template()` leaves an unknown data key in place verbatim — a message
  * like `'The {{entity}} ...'` would render the literal `{{entity}}`
- * whenever a producer omits it. Interpolating these params is therefore
- * deferred to the (later-phase) `translateError()` resolver, which will
- * merge per-code defaults before calling `get()` so a missing param can
- * never leak. Until then the data rides along untranslated, ready for
- * logging / richer UI, while the human-readable string stays safe.
+ * whenever a producer omits it. `useErrorTranslator()` passes the whole
+ * serialized error body to `get()` as `data`, so a parameterized message
+ * would interpolate from it — but since every shipped message is currently
+ * param-free, interpolation is a no-op and the data just rides along
+ * (ready for logging / richer UI). If a `{{param}}` message is added later,
+ * merge per-code defaults before `get()` so a missing param can't leak.
  */
 /**
  * Interpolation params per parameterized `ErrorCode`. Keys are the

package/dist/index.d.mts

@@ -411,16 +411,15 @@ declare const CATALOGS: import("ilingo").CatalogNode;
  * (`TranslatorTranslationNamespace.ERROR`, value `authupError`) — a
  * *sibling* of validup's own `validup` namespace rather than merged into
  * it, so `@ilingo/validup-vue`'s install can't overwrite authup codes
- * (and vice versa). `translateError()` (in `@authup/client-web-kit`,
- * wired in a later phase) resolves a server error's `code` + `data`
- * against this namespace.
+ * (and vice versa). `useErrorTranslator()` (in `@authup/client-web-kit`)
+ * resolves a server error's `code` + `data` against this namespace.
  *
  * The catalog is keyed by `@authup/errors`' `ErrorCode` values. The
  * `AuthupErrorData` map below is the typed *producer* contract — the
  * structured data each code may carry on the wire — and the
  * `declare module 'validup'` block augments validup's `IssueDataByCode`
  * wherever this package is imported. Today that is the client only
- * (`@authup/client-web-kit` re-exports this module, so `translateError()`
+ * (`@authup/client-web-kit` re-exports this module, so `useErrorTranslator()`
  * and any client-side issue construction get the typed `data`). It does
  * **not** reach server-side producers: `apps/server-core` does not depend
  * on `@authup/i18n`. If typed `defineIssueItem` / `createValidupError`
@@ -433,11 +432,12 @@ declare const CATALOGS: import("ilingo").CatalogNode;
  * `{{param}}`), not because the data is unavailable but because ilingo's
  * `template()` leaves an unknown data key in place verbatim — a message
  * like `'The {{entity}} ...'` would render the literal `{{entity}}`
- * whenever a producer omits it. Interpolating these params is therefore
- * deferred to the (later-phase) `translateError()` resolver, which will
- * merge per-code defaults before calling `get()` so a missing param can
- * never leak. Until then the data rides along untranslated, ready for
- * logging / richer UI, while the human-readable string stays safe.
+ * whenever a producer omits it. `useErrorTranslator()` passes the whole
+ * serialized error body to `get()` as `data`, so a parameterized message
+ * would interpolate from it — but since every shipped message is currently
+ * param-free, interpolation is a no-op and the data just rides along
+ * (ready for logging / richer UI). If a `{{param}}` message is added later,
+ * merge per-code defaults before `get()` so a missing param can't leak.
  */
 /**
  * Interpolation params per parameterized `ErrorCode`. Keys are the

package/package.json

@@ -1,7 +1,7 @@
 {
     "name": "@authup/i18n",
     "type": "module",
-    "version": "1.0.0-beta.49",
+    "version": "1.0.0-beta.50",
     "description": "Framework-agnostic translation catalogs and locale registry.",
     "license": "Apache-2.0",
     "exports": {
@@ -24,7 +24,7 @@
         "test:coverage": "cross-env NODE_ENV=test vitest run --coverage"
     },
     "engines": {
-        "node": "^20.19.0 || ^22.13.0 || ^23.5.0 || >=24.0.0"
+        "node": "^22.13.0 || ^23.5.0 || >=24.0.0"
     },
     "keywords": [
         "auth",
@@ -52,12 +52,12 @@
         "ilingo": "^6.0.0"
     },
     "devDependencies": {
-        "@authup/errors": "^1.0.0-beta.49",
+        "@authup/errors": "^1.0.0-beta.50",
         "validup": "^0.5.1",
         "vitest": "^4.0.14"
     },
     "peerDependencies": {
-        "@authup/errors": "^1.0.0-beta.49",
+        "@authup/errors": "^1.0.0-beta.50",
         "validup": "^0.5.1"
     },
     "publishConfig": {