localized_text edit can leave a stale other-language sub-value #41

New Issue

2026-06-05T13:16:48Z

logaritmisk commented

2026-06-05 13:16:48 +00:00

Context

Follow-up from the instance-locale milestone (single-language content authoring,
docs/superpowers/specs/2026-06-05-instance-locale-and-content-authoring-design.md).

The LocalizedText field input (web/src/objects/field-input.tsx, case "localized_text")
now registers a single input at ${key}.${default_language}. On the object edit path,
react-hook-form seeds defaultValues.fields from object.fields verbatim
(object-edit-form.tsx). If a stored localized_text value was authored under a different
language than the current instance default — e.g. stored { title_ml: { en: "Vase" } } on an
instance whose DEFAULT_LANGUAGE is now sv — the form registers title_ml.sv into the
existing subtree. Saving then yields { en: "Vase", sv: "Vas" } (if the user types) or leaves
the stale { en } untouched (if they don't). set_fields is full-replace and validates the
shape, so this is not data loss — but it silently accumulates a hidden, non-default-language
key that display (labelText/pick_label fall-through) may surface unexpectedly.

Why it's an edge

A fresh Sweden-first deployment (default sv, content authored in sv) never hits this — it
only matters if an instance had localized_text data in another language before the default
was set/changed. Non-blocking; flagged in the milestone's final review.

Ask

When authoring/saving a localized_text value, normalize to keep only the default-language
key (strip other-language sub-values), OR document that pre-existing multilingual field
values are preserved as-is and only the default-language slot is edited.
A small test covering: edit an object whose localized_text has a non-default-language key →
the saved value contains only the default-language key (or the documented behavior).

Notes

The descriptive-label path (LabelEditor) already replaces the whole array with a single
default-language entry, so this only concerns the localized_text field-value map.

## Context Follow-up from the instance-locale milestone (single-language content authoring, `docs/superpowers/specs/2026-06-05-instance-locale-and-content-authoring-design.md`). The `LocalizedText` field input (`web/src/objects/field-input.tsx`, `case "localized_text"`) now registers a single input at `${key}.${default_language}`. On the object **edit** path, react-hook-form seeds `defaultValues.fields` from `object.fields` verbatim (`object-edit-form.tsx`). If a stored `localized_text` value was authored under a *different* language than the current instance default — e.g. stored `{ title_ml: { en: "Vase" } }` on an instance whose `DEFAULT_LANGUAGE` is now `sv` — the form registers `title_ml.sv` into the existing subtree. Saving then yields `{ en: "Vase", sv: "Vas" }` (if the user types) or leaves the stale `{ en }` untouched (if they don't). `set_fields` is full-replace and validates the shape, so this is **not data loss** — but it silently accumulates a hidden, non-default-language key that display (`labelText`/`pick_label` fall-through) may surface unexpectedly. ## Why it's an edge A fresh Sweden-first deployment (default `sv`, content authored in `sv`) never hits this — it only matters if an instance had `localized_text` data in another language *before* the default was set/changed. Non-blocking; flagged in the milestone's final review. ## Ask - When authoring/saving a `localized_text` value, normalize to keep only the default-language key (strip other-language sub-values), OR document that pre-existing multilingual field values are preserved as-is and only the default-language slot is edited. - A small test covering: edit an object whose `localized_text` has a non-default-language key → the saved value contains only the default-language key (or the documented behavior). ## Notes - The descriptive-label path (`LabelEditor`) already replaces the whole array with a single default-language entry, so this only concerns the `localized_text` *field-value* map.

logaritmisk closed this issue

2026-06-05 13:54:23 +00:00

logaritmisk referenced this issue from a commit

2026-06-05 14:23:41 +00:00

docs(plans): follow-ups batch (#38 #28 #41 #26)

logaritmisk referenced this issue from a commit

2026-06-05 14:23:41 +00:00

fix(web): VisibilityBadge typed to the union (#38); normalize localized_text to default language on save (#41)

logaritmisk referenced this issue from a commit

2026-06-05 14:23:41 +00:00

merge: follow-ups batch (#38 #28 #41 #26)

Sign in to join this conversation.