Copy changes must trigger the translation workflow

What it is

A source-change-triggered localization workflow treats every addition, deletion, or semantic revision of user-facing copy as an engineering event that must propagate. Starting from a stable message identifier in code or a content system, the event drives extraction, TMS assignment, translation, linguistic review, in-context acceptance, and release. It replaces the late manual hunt for sentences that changed. Each locale version remains tied to a source revision and an explicit state: a translation that never existed is missing, while one that describes an older source meaning is stale.

Why it happens

Using source text as a key can turn a punctuation edit into both a new key and an orphaned translation. Checking only whether a target file exists is equally unsafe because yesterday's translation can appear release-ready after today's source change. A stable message ID, source revision or content hash, placeholders, plural branches, call site, and screenshot context identify the affected locale records. A change event first validates message structure, then moves approved targets to stale or creates missing work for a new message. Translation is only an intermediate state: linguistic review and acceptance in the rendered interface are required before release. Deletion and message splitting also need traceable events so obsolete targets do not accumulate silently.

Studying it

Replay additions, wording edits, placeholder changes, plural-branch changes, message splits, and deletions from version history, then inspect the task and state transition produced by each. Useful process measures include extraction latency, age in each state, backlog by locale, review return rate, source churn during translation, and post-release defects caused by lost context. Comparisons need to control change volume, locale count, release cadence, and message risk: longer lead time can reflect necessary legal or domain review rather than inefficiency. Sampling one source revision and tracing it through repository, TMS, approval, and shipped artifact tests actual provenance more strongly than a closed-ticket count.

Where it stops holding

Comments, analytics event names, and non-user-facing identifiers should not create translation work. Conversely, remote configuration, email templates, help content, and server-originated errors are source copy even when absent from the client repository. A layout-only metadata change may preserve a translation, while a small change to placeholder type, tone, legal meaning, or action consequence may require full review. Machine translation can create a candidate; it does not confer approved status. Emergency releases may take a predefined degraded or delayed path, but they must retain a record of which locales still express the old meaning.

Applying it

• Give each message a source-text-independent ID and retain its revision, content hash, description, call site, placeholders, and plural or gender branches. Fail extraction on duplicate IDs, unowned messages, and incompatible structure.
• Connect source repositories and content systems to the TMS as an event chain. Keep translation-review state (missing/translated/reviewed/approved) orthogonal to deployment state (unpublished/published). When the source changes again, mark every target still bound to the old source revision stale or superseded, even if it was published; record actor, time, rule version, and source revision for every transition.
• Set release gates by risk. Transactional, safety, privacy, and legal messages require an authorized reviewer to approve the current source revision. Low-risk copy may enter a time-bounded backlog only under a declared fallback policy.
• Generate a per-locale manifest for every candidate build, exposing missing, stale, placeholder-incompatible, orphaned, and unreviewed messages. Run a trace test across source, TMS, review, and artifact to verify that a source change reaches a legitimate terminal state.

Related

• Same group: S4.04.2 Fallback behavior for untranslated content must be explicit · S4.04.3 Translation lag produces mixed-language interfaces
• Adjacent: S4.03.3 Hard-coded text can only be found by running the product · S4.05.3 Termbases and style guides provide acceptance criteria
• Search terms: continuous localization · translation state machine · source revision tracking