langsys-js-react 0.6.2 → 0.6.4

package/CHANGELOG.md

@@ -1,3 +1,31 @@
+## 0.6.4 - 2026-08-16
+
+### Fixed
+
+- **Base SDK bumped to `langsys-js-typescript@^0.6.4` — fixes raw ICU message source rendering to the page.** Unlike the recent bumps, this one changes what your users see. When an ICU argument was missing, the base SDK fell back to the simple `{key}` interpolator, whose pattern deliberately can't match an ICU slot — so the entire construct passed through untouched:
+
+  ```
+  before: {name_gender, select, male {Bienvenido} female {Bienvenida} other {Bienvenide}} Sarah
+  after:  Bienvenide Sarah
+  ```
+
+  **This is reachable without any mistake on your part**, which is why it's worth upgrading for: langsys-ai's ICU promoter can *introduce* a `select` argument the source phrase never had — a plain `%name%` / `{name}` becomes `{name_gender, select, …}` in gendered target locales. Your app can't supply `name_gender`, because it doesn't exist in the phrase you wrote and nothing tells you the translation grew one. Any React app translating into a gendered locale could hit this, through either `t()` or `<Translate params>` / `<Phrase params>`.
+
+  Recovery is aligned with `langsys-php` so a shared catalog can't render two different sentences: a missing `select` argument takes the `other` branch (a correct sentence — `other` is what an unknown gender should render), and a missing `plural` argument takes `other` with `#` rendered as `{count}` (nothing can be inferred for a count, so the sentence survives with a visible gap).
+
+- **A `null` param now counts as missing rather than coercing to `0`.** Previously `{count, plural, …}` with `count: null` rendered `0 items` — identical to a genuine `count: 0`, so a failure to pass the value and an empty cart produced the same string on screen, in screenshots, and in bug reports. A real `0` still renders `0 items`; only `null` now takes the recovery path.
+
+## 0.6.3 - 2026-08-16
+
+### Changed
+
+- **Base SDK bumped to `langsys-js-typescript@^0.6.3`** — fixes `<select>` option text being harvested twice by the tokenizer. Inherited; no wrapper API change.
+
+  **What this means if you put a `<select>` inside `<Translate>`** (which this README documents as a supported pattern — `<option>` text is harvested):
+    - **Content without a `<select>` is unaffected** and does not rebase.
+    - **Affected blocks re-key**, because the token list feeds the `custom_id`. Migration is automatic and lookup-only: the base SDK tries the corrected id, then the 0.6.0–0.6.2 id, then the pre-0.6.0 legacy id, and always *registers* the corrected one — so the older keys only shrink and nothing loses its translations.
+    - **If you render with `langsys-php` and hydrate with this SDK**, affected blocks may appear to *gain* translations after upgrading. That's expected: the ids previously diverged from PHP's and now converge on them, so blocks PHP had already translated start resolving here.
+
 ## 0.6.2 - 2026-08-16
 
 ### Changed

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "langsys-js-react",
-    "version": "0.6.2",
+    "version": "0.6.4",
     "description": "React binding for the Langsys translation SDK — realtime continuous translations with automatic token discovery, delivered as hooks and a <Translate> component.",
     "author": "Langsys",
     "license": "MIT",
@@ -61,7 +61,7 @@
         "react": "^18.0.0 || ^19.0.0"
     },
     "dependencies": {
-        "langsys-js-typescript": "^0.6.2"
+        "langsys-js-typescript": "^0.6.4"
     },
     "devDependencies": {
         "@eslint/js": "^9.0.0",