Media field on an i18n model saves to the active locale only, so a locale-agnostic asset silently diverges

[ABB65]

Preflight

Searched open and closed issues — no duplicate. ROADMAP.md lists "Multi-locale tools — Bulk translation helpers, locale coverage dashboard", which is adjacent but broader; this report is about a silent data divergence, not a bulk-translation convenience.

Studio version

Managed staging at studio-staging-5610.up.railway.app, as running on 2026-08-19. Exact version not determinable from the UI — that is #206.

Environment

Other (managed staging)

Browser

Chrome

Description

On an i18n: true model, saving an image field writes only the locale that happens to be selected in the editor. The other locales keep the previous value, and nothing in the UI says so.

For a text field that is correct — the whole point of the locale switch. For a media field it is not: the value is a delivery URL (…/api/cdn/v1/<pid>/media/original/<uuid>.webp), which carries no language. The same is true of relation/relations IDs. There is no editorial reason for these to differ per locale, but the editor treats them exactly like translatable prose.

The failure is silent and, worse, invisible in the place people look. The editor swaps the asset, sees the new image in the form, and reasonably concludes the job is done. If the site renders a different default locale, nothing changes on the site.

Steps to reproduce

1. Take a singleton with i18n: true and an image field (ours: site-settings.guides_band_background, locales tr + en, default tr).
2. Open it in Studio with en selected.
3. Upload a new asset to that field and save.
4. Inspect the committed content.

Expected

Either the asset lands in every locale, or the editor is told plainly that it did not — a per-field locale-coverage marker, or a "this field now differs across locales" warning on save.

Actual

content/system/site-settings/en.json   guides_band_background → f09cf840-….webp   (new)
content/system/site-settings/tr.json   guides_band_background → bcea0e2d-….webp   (old, untouched)

Two cr/content/site-settings/en/* branches, no tr branch. The site renders tr, so the change had no effect at all.

Impact

This happened to a real, non-technical editor on our project. They replaced the asset, then commented "I did it but I'm not sure whether it came out right" — which is the correct instinct, but they had no way to check from inside Studio. Someone with repo access had to diff the locale files to find it.

The general shape: for any locale-agnostic field type on an i18n model, per-locale scoping turns a normal edit into a silent partial write. Media is the common case because assets get swapped late, often by the client, right before launch.

Suggested direction

Roughly in order of cost:

1. Warn on divergence. After saving a media/relation field, if the value now differs across locales, say so in the save confirmation with a one-click "apply to the others".
2. Per-field locale coverage. Show which locales share the current value — this also covers Read view shows raw relation IDs while the edit form resolves them #203's territory, where the read view already hides what the editor needs to see.
3. Let the model declare it. A field-level flag (localized: false, or an inferred default for image/file/video/relation) so locale-agnostic fields write across all locales and render once in the form instead of once per locale.

(3) is the real fix — the schema already knows these fields are not prose. (1) alone would have saved us this round.