focusreactive / focusreactive/payload-plugins
translator: provenance fingerprint option covering excluded and non-text localized fields
- Dominant language
- TypeScript
- Stars
- 19
- Forks
- 0
- Avg merge
- 16h 54m
- Merged PRs (30d)
- 19
Description
Read against **0.10.1**.
## Problem
The provenance fingerprint is built from translatable text only — `leafSourceText`, which collects
localized `text` / `textarea` / `richText` fields that are not excluded. Everything else in the
document is merge-only and never contributes.
So a source change that is *not* text never marks its translations out of sync. Swap the hero image on
the English version of a page and every translated locale keeps showing the old image, with the
staleness signal saying everything is current. Same for attachments, and for any field a host has
marked `exclude: true`.
## Why this matters
Localized uploads are common — ours include a required localized `promoImage` on the Hero block. These
are exactly the fields a human has to handle, because a model cannot translate an image, so they are
the ones most in need of a "the source moved, look at this again" signal.
We currently catch it with a review-time same-as-source comparison, which works but only fires when
someone happens to run another translation. Between runs, the staleness signal is quietly wrong.
## Suggested shape
An option to include non-text localized fields in the fingerprint — uploads and relationships by id,
excluded fields by value. Opt-in would be fine; it changes what counts as a source change, so it should
not shift under existing installs silently.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing how the translator builds the provenance fingerprint from leafSourceText and how localized text, uploads, relationships, and excluded fields are represented. Define and implement the opt-in behavior so the selected non-text fields contribute to the fingerprint, while existing installs retain current behavior; verify that source changes produce the intended staleness signal.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- localization
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100