Master Art of Translation | The Unicode MessageFormat 2 Localization System — How Variables, Plurals, Selectors, Markup and Runtime QA Keep Their Meaning

How do you translate Unicode MessageFormat 2 (MF2), localize dynamic app messages, or make plural forms, variables, grammatical selectors, numbers and rich-text markup work correctly across languages? This long-form guide explains the MessageFormat 2 translation workflow from source-message design to multilingual quality assurance. It is for translators, localization engineers, UX writers, developers and language reviewers who need user-facing software to say the right thing when runtime data changes.

The hidden problem is that a translated application message is not always a fixed sentence. It may be a family of sentences selected by count, status, user preference, date, number, context or product state. A translation can look correct in the string editor and still fail when the counter is zero, a name arrives in a right-to-left script, the application inserts a negative amount, a placeholder has no value, or the target language needs a different grammatical construction. A fluent preview at one value does not prove that all the other values preserve meaning.

The reliable method is to specify the user action and the data contract, identify every changing variable, choose the correct MessageFormat 2 declarations and selection behavior, translate complete messages rather than clipped fragments, protect syntax while allowing natural target word order, format values using locale-aware functions, and test combinations in the actual runtime. This chapter explains how to migrate from older ICU MessageFormat patterns cautiously, diagnose missing fallbacks and invalid selectors, review markup and bidirectional text, and build a repeatable release gate for source and target languages.

Architecture: EDKSG-TRANS-MASTER-WORLD-1120. Research and editorial review: 3 November 2026. This article focuses on the translation of dynamic MessageFormat 2 messages as a versioned production system. It does not supersede the existing quick-task guide to ICU MessageFormat plural/select work or the general translation root. Illustrative interface, order, safety and account messages are fictional. Verify supported functions and platform behavior against your implementation before release.

Fast answer: how to translate a dynamic MessageFormat 2 message

• Start with the whole user-facing message and its purpose, not a string fragment.
• List input variables, data types, possible values, missing-value behavior and the action that follows the message.
• Treat MF2 syntax, declarations, selector keys, function identifiers and markup identities as executable structure, not ordinary prose.
• Use a typed number selection when grammatical forms depend on quantity; distinguish exact-value decisions from locale plural categories.
• Let target translators reorder words and variable positions; do not force the source language’s syntax across languages.
• Keep fallback variants, representative values, scripts, locale settings and errors inside a reproducible QA matrix.
• Validate the pattern with a compatible MF2 parser, then inspect rendered output in the product; neither step replaces the other.
• Preserve the distinction between an error that prevents parsing and a runtime value that triggers a defined fallback.
• Publish only after language review, implementation tests, accessibility review and verified change control.

1. What MessageFormat 2 is, and why it changes translation

MessageFormat 2 is a Unicode specification for composing localizable messages containing text, variable values, formatting, selection and markup. It is part of the Common Locale Data Repository specification, Unicode Technical Standard #35, Part 9. A program supplies values at runtime; the message describes how these values participate in something a person will read or hear. In a simple message, this may be only a name; in a complicated message, a count and category determine which entire sentence appears. The standard defines a message data model and processing rules, not a universal promise that every software framework already implements every feature.

The crucial object of translation is the meaningful rendered message, not the sequence of characters stored in a resource file. A target variant is correct if it communicates the intended state, subject, action and consequence for the actual runtime values. That requires two kinds of fidelity at once. Linguistic fidelity protects what the audience learns; structural fidelity protects the variables, selectors and rendering contracts by which software decides what to display. A sentence that reads naturally but mislabels a status fails the first test. A perfectly translated sentence hidden behind a malformed matcher fails the second.

Unicode announced that MessageFormat 2 had advanced to Stable with CLDR 47 in March 2025. The current authoritative CLDR 49 Part 9 specification, dated 21 October 2026, describes syntax, conformance, default functions, processing, fallback and errors. Do not confuse a stable specification with universal runtime availability: library versions, supported functions, API behavior, feature flags and deployment constraints still differ. A project should pin the specification and library versions, then test its own actual environment. This guide separates stable structural ideas from examples that rely on particular runtime features.

An older ICU MessageFormat guide remains valuable for established production systems. MF2 is a successor with a different syntax and explicit concepts such as declarations, matchers, markup and function annotations. A project should not convert a working production catalog merely because the newer notation is more legible. Migration requires a compatibility inventory, a mapping of observable outputs and a rollback plan. Here the specialized question is how to make MF2 work as a multilingual message system from authoring through release, not how to translate a one-off plural sentence quickly.

2. The boundary between source text, message logic and runtime state

Imagine an interface that says, “Your order is on its way.” The sentence appears simple, but the system may show it only when an actual shipment has been handed to a carrier. If a translated variant instead reads “Your order has arrived,” the semantic error is obvious. More subtle defects occur when a string is selected at the wrong moment, when an unqualified “delivered” status describes only a partial shipment, or when a placeholder receives a stale delivery estimate. Translation cannot repair missing application state; it can expose and document that state so engineers and product owners can correct the source contract.

An MF2 project should therefore contain at least four linked artefacts. The source intent records the human meaning and action. The message pattern records variable interpolation, selector and formatting logic. The runtime contract records the types and allowed values supplied by software. The test evidence records source and target outputs for representative and boundary values. Those artefacts should agree. In a small project they may live in one carefully managed spreadsheet and repository; in a large product they may be maintained in catalog tooling, source code, type schemas and automated tests.

A placeholder is not a safe substitute for missing information. A variable called $value tells the reviewer almost nothing. A variable called $remainingAttempts still requires clarification: does zero mean no retries remain or that no attempts have yet been used? What happens at negative one? Is the maximum fixed? Does the value represent an account, a session or an action? Translators should not be expected to invent business rules from names. A well-written localization brief explains precisely what the source speaker knows and what it is authorized to claim.

Good separation also protects nontranslatable data. A resource key, variable identifier, function name, persistent product ID and machine-readable state value may remain constant while visible descriptions change. Yet “never translate anything inside braces” is too simplistic: some literal text and markup-adjacent text may be intended for users, while option values may be code. The task is to classify tokens by function, not by appearance. Unicode’s translator guidance explicitly distinguishes literals, declarations, placeholders and markup so editors can change prose without damaging the executable structure.

3. Read a simple MF2 message without mistaking syntax for language

The simplest placeholder inserts a runtime value into a sentence. The visible text can move to another position in translation; the variable name identifies the data to insert. For example, consider the source pattern below. Its purpose is to identify a record assigned to a person, not to make the personal name the grammatical subject in every language.

Record assigned to {$name}.

The curly braces and dollar sign are message syntax. The variable name is supplied by the caller. A translator may produce a target sentence whose object, verb and name appear in an entirely different order. A parser that recognizes the pattern does not know whether the name is a company name, a person’s full name or a pronoun; the runtime contract and translator context provide that knowledge. In testing, include a long name, an empty value, a multiword name, accented characters and a bidirectional-script name. Values must be properly escaped or represented according to the application’s safety model; MF2 does not replace output-encoding and trusted-markup handling.

A formatted numeric value looks different because the expression includes a function. The notation below requests numeric formatting; the number’s display conventions depend on locale settings and the function implementation. It does not convert arbitrary currencies, quantities or physical units by itself.

Total items: {$count :number}.

A translator should know whether count is exact, rounded, approximate or limited to integers. The field label should not imply precision the data lacks. In a report, displaying 1.5 may be meaningful; in a count of physical objects, it could reflect a data error. The function is capable of formatting a value, but the product remains responsible for deciding which values are allowed. When a decimal separator or digit grouping changes, testers should inspect both the formatted output and any adjacent words so that punctuation and spacing do not accidentally change the user’s interpretation.

4. Declarations, matchers and the meaning of a variant

When quantity affects the entire sentence, one fixed string is not enough. A typed declaration can make a count available as a numeric selector. The .match line chooses among variant keys, while the catch-all * provides a fallback variant. Here is a compact source example with intentionally simple English output:

.input {$count :integer}
.match $count
0   {{No messages are waiting.}}
one {{One message is waiting.}}
*   {{There are {$count} messages waiting.}}

The text inside the double braces is complete user-facing prose. The exact zero case handles a product-specific difference between no messages and at least one message. The one key is a plural category, not merely an English spelling of the digit 1. Other languages may need more grammatical categories and different sentence designs. The catch-all is obligatory for valid matching messages; it does not guarantee that the translated fallback will be grammatically appropriate for all values. The reviewer needs a test grid from actual CLDR plural categories and special exact values.

A matcher is a selection mechanism, not an independent grammatical oracle. CLDR’s plural categories classify numbers according to language-specific rules; they do not write the right noun phrase for a translator. A source message with one and * is not automatically sufficient for a locale with additional relevant categories. Nor does “0” always mean the plural category zero: an exact key and a grammatical category are different things. Teams must test the intended behavior of their function annotations and selector keys with supported libraries and the locale data actually deployed.

With multiple selectors, each variant has a corresponding key for each selector and requires a catch-all combination. This creates power and risk. If the interface changes by order status and count, a reviewer may need to inspect several interactions, not simply translate a noun. A “completed” status paired with a count of zero could describe either no completed items or a completed process with zero items; only a documented state contract can settle it. Avoid exploding into dozens of near-duplicate variants when the message could be simplified into two independently meaningful messages. Conversely, do not split a sentence into fragments merely to save translation entries; that can prevent a target language from reordering words and expressing agreement.

5. What can be translated, and what must be protected

In a MessageFormat 2 resource, the visible literal sentence is normally translatable. So are many adjacent grammatical particles and labels inside branches. Variable identifiers, the names of functions, selector constructs, structural braces, numeric key meanings and markup identifiers are usually application logic. The translator may reorder complete expressions relative to words, but should not casually rename a runtime variable or change :integer to a guessed function. Literal option values can also be semantic commands to the implementation. The correct classification is specified by the message contract, not by blanket rules about punctuation.

Markup deserves a separate inspection because it is structurally expressive while remaining application-defined. An MF2 pattern can use a sequence such as {#bold}important{/bold}. The #bold and /bold tokens are markup syntax, but the word “important” is natural-language content that may be translated. The standard does not assign universal rendering semantics to arbitrary tag names. One product may render a tag as strong visual emphasis, another as a semantic annotation for a speech interface. The translator’s job is to preserve the function and intended emphasis; engineering and accessibility reviews must verify that the product’s renderer handles it safely.

Do not treat raw markup as a convenient place to hide untrusted HTML. Rich messages often combine product-controlled markup commands with user-provided values. Escaping, sanitization, allowed element lists, safe URL handling and separation of text nodes from executable markup remain implementation obligations. A translation resource should not become an arbitrary code execution channel. For links, reviewers must test visible link text, link destination meaning, accessible name, focus behavior and whether a target-language paragraph makes the same promise as the linked action.

6. Why plural rules are not the same as integer comparisons

English encourages a deceptive shortcut: one item, two items. It can tempt developers to encode count === 1 and use a single fallback for everything else. This shortcut does not model the morphology of every language and can also mishandle decimals or displayed rounding. Unicode CLDR plural rules account for categories such as zero, one, two, few, many and other, with the actual mappings determined by locale. Some locales use only one relevant category; others use several. A category name does not have an identical numeric membership everywhere.

MF2’s number selection distinguishes exact-value keys from rule-selected categories and from the catch-all. That distinction protects product behavior from grammatical behavior. A payment product may require an exact zero warning for business reasons, while a different count needs a locale-driven plural construction. The same numeric value could be formatted with grouping or decimal precision before it appears in a message. Choosing a selection function without considering these formatting options can produce awkward or misleading agreement. When an approximate number is rounded for display, the team should test what grammatical form the matcher chooses and whether that matches the visible number.

Plural review should be grounded in CLDR locale data but must not stop at category lookup. A reviewer can test zero, one, two, a value in each locale category, a large count, negative values if permitted, decimals if permitted, and any exact business-rule exceptions. They should then read the whole rendered sentence, not simply check that a branch was selected. A category may have the correct key while the noun, adjective, pronoun or word order inside the chosen branch is wrong.

7. Dates, times, quantities and hidden assumptions

Numbers and dates are not decoration. An instruction may change when it is valid, an appointment may depend on a time zone, and a transaction amount may be confused if a formatting pattern rounds away needed precision. Formatting functions should receive typed values and explicit contextual requirements. A stored instant and a local calendar date are not interchangeable concepts. An account suspension that ends at an instant cannot safely be described using an ambiguous date-only label unless the product specifies the corresponding zone and inclusive or exclusive boundary.

The source writer should define whether a number is a count, currency, percentage, measurement, identifier, ranking or serial value. Format a quantity that belongs to a counted set differently from an opaque identifier that only resembles a number. Keep account numbers and medical identifiers intact rather than passing them through a generic numeric formatter that might strip leading zeros. For percentages, clarify whether the input is a fraction or a whole-number percentage. For currencies, clarify whether the field is a numeric amount paired with a code and how rounding should be handled. Locale formatting does not authorize conversion of units, exchange rates or real-world deadlines.

Dates introduce further choices: source time zone, target audience time zone, daylight-saving transitions, calendar system, display precision, weekday names and whether the date includes an exact time. A message that says “tomorrow” must be checked at the point of display, not copied from a cached translation generated before midnight. A UTC timestamp cannot be assumed to share the user’s local calendar day. These are examples of how an apparently linguistic error can originate in data modeling; translation review should identify the source of the problem rather than only polishing the wording.

8. Bidirectional text and the architecture of one mixed-script sentence

A right-to-left language message may contain a left-to-right account code, URL, email address, product name or numeric date. Visual ordering can differ from logical character ordering, and punctuation may appear beside the wrong segment when directional boundaries are not handled correctly. Translators should not manually add arbitrary invisible marks without a plan. The product should follow a documented bidi strategy, support the appropriate isolation and direction metadata, and test realistic data values. Unicode’s specification discusses default bidirectional strategies; the safe rendered result still depends on the embedding environment and UI component.

The most revealing test is a target-language sentence containing both right-to-left prose and a deliberately long left-to-right identifier with punctuation. Inspect it on each supported platform and with assistive technology where appropriate. Check copying, selection, screen-reader order, search, truncation and error dialogs. What matters is whether a human can identify the whole code and associate it with the correct action. A screenshot of one short value is not sufficient proof that the message is safe for all valid values.

9. The release pipeline: source brief to proven rendering

Begin by defining the user task and the exact state transition the message reports. A writer can record the message ID, trigger, allowed input range, type information, target audience, intended level of formality, brand terms, accessibility requirement and security constraints. The developer then chooses a message pattern that permits natural target grammar and logs its source version. Translators receive a complete visual and interaction context, including representative values. Reviewers inspect the target message for invariant meaning and appropriate linguistic choice. Engineers validate parseability and supported functions. Finally, QA evaluates the rendered message in the real application and records failures by cause.

A minimal practical release gate contains: linting and syntax validation; typed-variable checks; variant-coverage tests; unresolved-variable tests; known-good and intentionally bad test values; pseudolocalization or expansion testing; locale switching; right-to-left rendering; assistive-technology checks for key flows; terminology consistency; screen-space resilience; and product-owner review of claims and actions. High-risk texts such as consent, deletion, billing and safety notices warrant more conservative change control and independent sign-off. A failed branch should block release for the affected locale rather than being hidden because the English default screen looks correct.

Record evidence at three levels. The source contract shows what the application promised to provide. The translation record shows the chosen expressions and any unresolved questions. The runtime report shows actual outputs for a versioned build and locale set. This enables an error to be traced to its origin: source ambiguity, wrong variable, wrong selector, missing variant, mistaken terminology, formatting mismatch, renderer behavior or product-state defect. Without this separation, every problem becomes a generic “translation issue,” preventing a durable fix.

10. Distinguish review findings by their real cause

Linguistic findings include inaccurate content, omissions, unjustified additions, tone mismatches and agreement errors. Structural findings include broken braces, mismatched selector key counts, missing catch-all variants, wrong variable references, unknown functions and invalid markup handling. Product findings include stale status, wrong field values, inaccessible controls, wrong locale selection or an unsupported library feature. Rendering findings include layout clipping, incorrect bidirectional ordering, numerals formatted against policy or a hidden accessible label. Each finding needs a different owner and test of correction.

Do not permit a fix for one category to manufacture a failure in another. Replacing a complex message with one fixed sentence may eliminate a parser warning but erase valid distinctions across quantities. Converting an identifier to a number may improve display consistency but destroy leading zeros. Forcing a manually inserted directional mark might repair one screenshot but destabilize text selection elsewhere. A good issue report describes the observed output, input values, active locale, version, expected meaning and impact on the user’s action, then assigns the problem to the person able to change the underlying cause.

11. Migration from ICU MessageFormat 1: equivalence is an experiment

MessageFormat 1 and MessageFormat 2 are related but are not interchangeable strings. MF1 commonly expresses a plural choice inside braces with a construct such as a plural argument and an other branch. MF2 uses declarations, matchers and variants with a catch-all *. Moving a resource to MF2 is a translation and engineering migration, not just find-and-replace. Branching semantics, number formatting, escaping rules, function support, error behavior and integrated application APIs must all be checked.

Create a behavioral baseline before converting. For each old message, render a matrix covering permitted values and locales in the existing production runtime, then record the intended meaning separately from accidental output quirks. Convert the message to a target MF2 pattern supported by a chosen implementation. Render the same matrix and compare. Differences should be triaged: an intentional linguistic improvement is not the same as a new bug, and an old bug should not be preserved merely for string equality. Audit code that passes data to the formatter; it may need different type handling or APIs. Retain a rollback path until the new runtime is production-proven.

If the translator management system or release environment cannot handle MF2 syntax safely, do not pretend the problem is solved by asking translators to avoid touching braces. Use a compatible toolchain, an interim protected resource workflow, or postpone migration. Existing MF1 content may remain the right operational choice while the team’s tooling catches up. The stable Unicode specification is a foundation for interoperability, not a deadline imposed on every application.

12. Editorial ownership, reader routes and further reading

This chapter owns the crossing between a versioned MF2 message program and its target-language runtime behavior: the semantics of declarations, selectors, formatted values, dynamic placeholders, markup and production QA. The broader question of how meaning survives movement between languages belongs to Master Art of Translation | The Complete System for Moving Meaning Between Languages. The already-published fast ICU plural/select article remains the focused quick-task entry, while this chapter documents the complete MF2 architecture. The protected Vocabulary Learning Hub and How English Works series remain independent learning owners; links to them appear in the final transfer section when a reader’s difficulty is lexical or English-language rather than cross-language message logic.

Authoritative starting points are Unicode Technical Standard #35, CLDR 49 Part 9: MessageFormat (dated 21 October 2026), the Unicode MessageFormat 2 overview, the official quick start, the official translator guide, and CLDR 47 release notes. Read the normative specification for implementation requirements, the translator guide for practical editing and the deployed library’s documentation for its actual supported feature set. All examples below are teaching cases unless explicitly identified as standard examples.

Part II. Worked translation diagnostics: meaningful output across real product states

The following fictional cases are not claims about any named vendor’s implementation. They are small translation laboratories. For each, identify the source’s assertion, distinguish language from application data, choose a message design, and validate rendered outputs. The purpose is to train reviewers to diagnose the particular invariant that must survive the move between languages. Every case requires language-specific editing, not just replacement of an English word.

01. An unread-notification counter

Reader task and input contract. A messaging application counts notifications that have not been read rather than total conversations. An account can have several conversations yet no unread notifications. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The source says “You have one message” while the product field represents unread notifications only. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. The distinction between a conversation, a message and an unread notification can change the user’s next action. A target variant must not imply there are no messages in the account when the count is zero. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Supply an integer selector with an exact zero expression, a valid locale-specific grammatical set and a catch-all. Use the product word for unread notifications consistently in every branch. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test zero, one, two, high counts, a badge that shortens large values and a delayed refresh after the user opens another device. Compare the screen-reader announcement against the visible badge. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

02. An upload that may contain zero files

Reader task and input contract. A workspace shows the number of files successfully uploaded after a user presses Confirm. An attempted upload can fail before any file is stored. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The interface renders “1 file uploaded” because it counts selected items rather than confirmed uploads. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. The success claim is an assertion about state, not a grammatical flourish. Plural selection cannot make a wrong input count truthful, and a zero-success case must not sound like success. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Create distinct source contracts for selected, processing, uploaded and failed counts; decide which message is shown for each process stage before translating variants. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test zero successfully uploaded with two failures, mixed successes and failures, a retry that duplicates an event, and a selection that is cancelled before upload. Confirm that the final message describes the actual result. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

03. A download progress indicator

Reader task and input contract. A progress view reports completed bytes, total bytes and possibly an unknown total while a large file is downloaded. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The source string assumes that a percentage always exists and says “100% downloaded” when total size is undefined. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. A number formatter can display a value but cannot invent its denominator. “Complete” and “transferred bytes equal estimated total” may be different states. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Use separate patterns for indeterminate and determinate progress; keep percentage and file-size formatting governed by explicit metadata and rounding policy. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test a zero-byte file, unknown total, late changes to total size, 99.95% rounded to 100%, pause, resume and failure. Review progress semantics for assistive technology. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

04. A calendar invitation with guests

Reader task and input contract. A meeting scheduler tells the organizer how many people have accepted, declined or not responded. The organizer may also be counted as an attendee. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The product says “All guests accepted” after counting only those who responded, leaving two people pending. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. The word “all” is a quantified claim whose reference set must be defined. MF2 grammar is irrelevant if the recipient set is wrong. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Model accepted, declined and pending independently; choose a message with the approved group scope and avoid compressing two different sets into one ambiguous number. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test the organizer included and excluded, a guest added after responses arrive, rescinded acceptances and a meeting with no invitees. Verify the count announced in email and in the calendar UI. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

05. A subscription renewal reminder

Reader task and input contract. A paid service sends a reminder before its next scheduled renewal. The renewal may be automatic, pending approval or cancelled. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. A source string uses “Your plan renews tomorrow” for a user whose payment is merely scheduled for an attempted charge. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. The state of a financial obligation matters more than a natural-sounding tense. A target expression must not turn a planned event into a guaranteed successful payment. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Separate renewal date, charge attempt, authorization and confirmed renewal. Pass a typed date and explicit state rather than letting one placeholder carry several meanings. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test boundaries around midnight in the user’s time zone, an unpaid invoice, retry schedules, cancellation after notification generation and a delayed message queued across time zones. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

06. A security code expiration notice

Reader task and input contract. A sign-in flow tells a user when a temporary verification code stops being accepted. The product sends a code that may be invalidated by a newer one. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The interface uses “valid for five minutes” after three minutes have already passed during delivery. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Relative time is a computation tied to a real expiry instant, not text a translator can make accurate by selecting the correct plural suffix. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Specify whether time is remaining, originally allotted or elapsed; calculate at display; prefer unambiguous expiry time for long delays; preserve “not valid after” logic. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test zero remaining, a second code that revokes the first, network delay, a clock skew, a screen that remains open beyond expiry and a language change mid-flow. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

07. An irreversible deletion dialogue

Reader task and input contract. A file system asks whether to remove one or several folders permanently. Folder names may include punctuation and text in different scripts. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The warning says “Remove selected items” but the action actually deletes them without recovery. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. The modality and consequence are essential. Dynamic names and counts are secondary to the distinction between hiding, moving to trash and irreversible deletion. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Keep the irreversible action and affected object class in each complete variant; separate the list preview from the confirmation button; protect file names as data. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test a single folder, multiple folders, a mixed list, an empty selection, inaccessible names and an item whose name resembles a command. Require explicit product review of the destructive claim. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

08. A permission change confirmation

Reader task and input contract. An administrator changes another person’s role from viewer to editor for one workspace. The same role label is reused in menus and audit logs. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The message reads “You are now an editor,” misleading the administrator into thinking their own permission has changed. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Person and role are distinct inputs. A fluent sentence can reverse agency if the recipient, the affected account and the performer are not recorded. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Bind the affected person and target role separately; preserve agency in every target variant; consider full-sentence variants when grammatical role titles change with context. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test the administrator changing their own role, changing someone else’s role, a display name identical to a role name and a revoked invitation. Inspect audit-log wording and notification recipients. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

09. An access-request review

Reader task and input contract. A collaboration system reports requests that are pending, approved, rejected or expired. The requests can refer to different resources. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The translation calls a rejected request “cancelled,” implying that the requester withdrew it rather than an owner denying it. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Status terms encode actor and decision. Selection logic can match a status key correctly and still choose target wording with the wrong agency. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Create a controlled state glossary that defines each status and its responsible actor; use status-driven complete sentences and avoid one generic string with a substituted adjective. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test every state transition, a request automatically expired by policy, a rejection later reversed and two requests with different outcomes. Compare UI and audit records for consistent language. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

10. A two-factor authentication fallback

Reader task and input contract. A product offers an authenticator app, a recovery code and a hardware key. Not every account has every method available. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The screen says “Use another code” when the available next method is a physical key. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. The word “code” describes a specific mechanism. A dynamically selected fallback must reflect the actual security method rather than a generic noun chosen for brevity. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Make available methods explicit in the runtime model and use meaning-preserving choices; do not expose a method not configured for the user. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test each supported method, no available fallback, a key not connected, a lost device and a locale changed after the recovery screen opens. Confirm links and controls remain functional. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

11. A time-zone-aware deadline

Reader task and input contract. A task management system allows deadlines stored as instants and deadlines stored as all-day dates. Different users see the task from different time zones. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. A translated reminder says “Due today” even though the deadline has already passed in the recipient’s locale. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Calendar date and instant are different data types. Formatting can change the printed digits but cannot correct the wrong temporal reference. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Separate all-day deadlines from timestamp deadlines; define business time zone, inclusive boundaries and the exact source of relative-date expressions. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test timestamps around midnight, daylight-saving shifts, calendar-only dates, users traveling between zones and a push message arriving one day later. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

12. An appointment rescheduling notice

Reader task and input contract. A booking application tells a person that an appointment changed from one start time to another, retaining its duration and service location. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The message shows only the new start time without making clear that this replaces a confirmed earlier time. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. A change notice needs a before-and-after relation. A pair of formatted values is not sufficient when the causal wording is omitted or ambiguity remains. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Use separate old and new typed timestamps, a consistent date-time zone treatment and a complete target sentence that expresses replacement rather than addition. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test a change crossing a calendar day, one crossing a time-zone boundary, same-day moves, identical old and new values and cancellation instead of rescheduling. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

13. An inventory quantity estimate

Reader task and input contract. A storefront labels remaining stock as an estimate rather than an exact warehouse count, because reservations may be pending. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The output says “Only 3 remain” although the system reports a rounded availability band. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. The word “only” introduces urgency; a precise numeral turns an estimate into an apparent fact. Translation should not intensify scarcity beyond evidence. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Keep approximation markers tied to the actual quantity model; use a separate message for unknown, estimated and exact stock; approve any urgency wording. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test rapidly changing stock, zero available with backorders, a stock band displayed as a numeral and a cart reservation that reduces available quantity temporarily. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

14. A ticket queue position

Reader task and input contract. A support system gives a user an estimated position in a queue, not a guaranteed sequence of service. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The sentence “You are the third person to be served” is generated from an estimated rank that can change. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Ordinal language and certainty are distinct problems. A grammatical ordinal does not establish the reliability of the underlying rank. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Use a typed approximate position with a qualified sentence. Avoid claiming an exact future order unless the service contract guarantees one. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test positions 1, 2, 3, 11, 12 and 21, rapidly changing queues, priority interventions and a user leaving and rejoining. Check ordinal formatting in each locale. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

15. A multi-currency cart total

Reader task and input contract. A checkout shows a subtotal, shipping amount, taxes and final amount using a currency code attached to the actual transaction. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The amount 49.90 is displayed without the currency symbol or code, so a customer cannot tell which currency will be charged. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Number formatting and monetary identity are separate. A locale does not authorize a currency conversion or decide exchange rates. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Pass amount and the transaction currency explicitly, lock rounding policy to financial requirements, and protect any legally required price disclosure. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test a currency with no minor unit, one with several minor units, a refund, a negative adjustment, a very large amount and switch between interface locale and billing currency. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

16. A percentage discount banner

Reader task and input contract. A promotion advertises a percentage reduction on eligible items only, excluding certain categories and a minimum-spend condition. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The source message “Save 20% on everything” appears although the campaign applies only to a subset. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. A percentage placeholder does not carry scope. The translator must preserve eligibility conditions and avoid inferring a broader offer. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Separate promo value from offer conditions, provide concise access to the eligibility text and translate complete claims in each selected campaign state. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test no eligible items, the threshold exactly met, one excluded item, a partial refund, a changed campaign value and screen-reader access to restrictions. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

17. A package delivery stage

Reader task and input contract. A shipment tracking app displays prepared, collected, in transit, out for delivery, delivered and returned states. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The “delivered” localized label is reused for “out for delivery,” implying a handoff has occurred. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Different states carry different evidence. A selector should not blur them through a single celebratory phrase. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Maintain an explicit enum-to-language map, define what evidence changes each state and review order status separately from shipment status. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test partial delivery, a returned package, a failed delivery attempt, a delay and an event arriving out of sequence. Compare timeline, push notification and email. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

18. A medical appointment reminder

Reader task and input contract. A clinic portal sends appointment information, including clinician, modality, start time and what a patient must bring. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The dynamic message says “Your consultation will be online” because the last-used mode was virtual, while this one is in person. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. An appointment modality is clinical logistics information with practical consequences. Wrong state is not merely stylistic variation. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Use the actual booking record, explicit in-person or virtual variant and a separate instruction for preparation; seek qualified domain review for patient-facing care messages. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test a hybrid appointment, modality changed after scheduling, a patient with multiple bookings and a reminder that arrives after cancellation. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

19. An allergy filter result

Reader task and input contract. A food search tool labels products whose ingredient data indicates that a chosen allergen is absent, present or unknown. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The message says “safe for you” because the chosen ingredient is not listed in an incomplete record. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Absence of a recorded ingredient is not proof of safety. A selector must distinguish confirmed absence, reported absence and unknown evidence. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Translate the underlying evidence state without making health guarantees; preserve disclaimers and route to product-specific ingredient information. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test incomplete supplier records, traces, cross-contact notes, translated ingredient names and a search query that hides a term. Escalate high-risk wording to qualified reviewers. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

20. A weather probability notice

Reader task and input contract. A forecast app provides a probability of precipitation for a defined time interval and geographic grid. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The source reads “There will be rain” because the percentage is above an arbitrary threshold. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Probability is not certainty. Translating a forecast requires preserving the event, time window and strength of the claim. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Format the percentage correctly, state the forecast interval and avoid converting confidence into a categorical prediction unless explicitly authorized. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test zero, 50%, near 100%, missing data, stale forecasts and a location boundary. Compare graph labels, notification text and accessible description. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

21. A manufacturing machine alarm

Reader task and input contract. An industrial dashboard shows a current machine state, event severity, affected component and recommended operator action. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The translation changes a caution-level maintenance alert into a stop command even though the source says inspection is recommended. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Safety language contains authority and action, not just labels. The translator must not upgrade or soften commands outside the validated procedure. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Bind severity separately from remedy, use approved technical terminology and ensure instructions are reviewed by the responsible safety specialist. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test simultaneous alarms, a stale status, acknowledgement without resolution and a sensor returning invalid data. Verify audible and visual versions of the alert. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

22. A software-update prompt

Reader task and input contract. An application invites users to install an update that may be optional, required for security, or blocked by device compatibility. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The target message says “Update now” for an optional update while the primary action actually starts a download only. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Action labels must match execution. Required and recommended are different levels of obligation; start-download and install are different operations. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Keep source action and update policy explicit; translate each state as its own complete promise and verify buttons against actual navigation. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test no network, insufficient storage, auto-update disabled, a pending restart and a required update with a time-limited postponement. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

23. A consent-preference control

Reader task and input contract. A user can accept analytics, reject optional tracking, or choose categories. The interface records a consent state and may show a later confirmation. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The translated confirmation says “You agreed to all cookies” when only necessary storage remains enabled. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Consent scope and user agency are legally significant. A generic success message is unsafe because it may claim a choice that was not made. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Translate the exact category and scope of the saved preference, preserve withdrawal paths and verify the target against the underlying state record. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test accept-all, reject-optional, custom selection, changed policy version and withdrawal. Do not infer legal compliance from a linguistically correct pattern. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

24. A password rule hint

Reader task and input contract. A sign-up form displays requirements for length and character restrictions that can change by product or policy. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The translated hint says “at least eight characters” but the validator requires twelve and allows spaces. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. The interface wording and enforced rule must be one contract. A hard-coded translated number can drift when validation changes. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Pass current policy values or derive controlled resource variants, clarify whether limits count grapheme clusters or code points when relevant, and display examples without leaking secrets. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test minimum and maximum boundaries, Unicode characters, pasted spaces, a rule-change rollout and screen-reader error feedback that repeats the same requirement. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

25. A meeting-room capacity label

Reader task and input contract. A scheduling product shows room capacity as seated places, standing capacity or an uncertain maximum set by venue configuration. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The interface uses one “people” count for every layout and makes a room appear universally suitable. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. A quantity does not tell the reader the conditions under which it applies. Capacity is a property of a configuration. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Bind the occupancy mode to the count and include the mode in each full sentence; maintain the unit and meaning of maximum versus recommended capacity. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test a zero-capacity closure, different event layouts, changed furniture, accessibility reservations and a room with no verified capacity. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

26. A learning-platform assignment deadline

Reader task and input contract. A classroom tool reports how many submissions are graded, missing or pending feedback after an instructor closes an assignment. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The source line “All work has been reviewed” appears when every uploaded file has a score but some late submissions remain unreviewed. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. The universe of submissions determines whether “all” is true. The renderer should not infer completeness from the number of rows visible. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Define the submission set, distinguish scored from commented and reviewed, then translate status-dependent claims as whole messages. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test late arrivals, hidden submissions, reassessment, a null grade, an exempt learner and changes between instructor and learner views. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

27. A public-transport departure board

Reader task and input contract. A digital display shows a predicted departure in a number of minutes for a service that may be cancelled, boarding or delayed. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The string says “Departing in 0 minutes” even after the service is cancelled and the countdown freezes. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Countdown values and operational states must be coordinated; zero is not necessarily a completed departure. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Use status precedence rules and separate running countdown from cancellation or platform-change notices; avoid fabricating exact timing from stale data. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test service cancellation at zero, negative estimates, platform swaps, real-time updates, offline boards and long route names clipped in the target. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

28. A file-sharing expiry label

Reader task and input contract. A file-share link can expire after a fixed instant, after a maximum number of downloads, or when its owner revokes access. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The target displays “expires tomorrow” though the link will actually expire after its final allowed download tonight. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Expiry cause matters. A date value alone cannot describe a limit-based condition or a revocation. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Use distinct reason codes and complete variants. If more than one condition applies, express that access ends at the earliest trigger or present both limits explicitly. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test one download remaining, an expired date, revocation, a link opened from another time zone and an account that changes its link policy. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

29. A profile visibility message

Reader task and input contract. A social app describes who can see a post: only the author, a selected group or everyone permitted by the network. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The translation renders “private” as “invisible,” implying nobody else can access the post while selected contacts can. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Visibility is a relationship among actor, audience and resource, not a generic positive or negative adjective. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Use a documented audience model and complete per-state messages; verify whether a user can see, share, search or redistribute the post. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test a blocked contact, group-membership changes, a copied share link, a public profile with a private post and a deleted audience list. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

30. A backup completion message

Reader task and input contract. A device reports the time of the last successful backup, the current pending backup and any items omitted by policy. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The status reads “Your data is backed up” after a partial backup completed with exclusions. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Completion and completeness are distinct claims. Translation must preserve the documented scope of the backup and not turn a partial result into full protection. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Model successful, partial, pending and failed states with counts and accessible details; keep timestamps and excluded-item counts separate. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test disconnected storage, a backup spanning midnight, selected folders, revoked permissions and a restoration rehearsal that exposes omitted data. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

31. A live auction bidding message

Reader task and input contract. A bidding interface indicates the user’s current rank, minimum next bid and a closing time that can extend after last-minute activity. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The source says “Winning bid” whenever the user is temporarily highest, suggesting the transaction is final. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Current highest offer is not the winning outcome. Modal and temporal markers protect user understanding of contingent status. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Use state-aware wording with clear pending/closed distinctions; pass amount, currency and precise deadline through typed fields. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test two bids with the same timestamp, a late extension, a payment failure and an auction cancelled after closing. Check any push notification sent after a status change. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

32. An issue-tracker severity report

Reader task and input contract. An engineering team marks incidents as open, mitigated, resolved and closed; separately it records severity levels. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The localized badge translates “mitigated” as “resolved,” hiding that a temporary workaround is still active. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Status and severity are independent axes; a single colored badge must not flatten them into one optimistic word. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Keep both enums explicit, attach approved descriptions, and ensure status changes update notifications and incident summaries consistently. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test rollback of mitigation, incident reopening, multiple affected services and a stale dashboard. Verify that the target term implies no more than the source evidence. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

33. A service availability indicator

Reader task and input contract. A platform reports that a feature is available, degraded, unavailable, in planned maintenance or unknown because monitoring has no data. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The interface displays “Everything operational” whenever no alarm event arrives. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Absence of detected failure is not confirmation of normal operations. Unknown is a distinct epistemic state. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Use the monitoring system’s verified status categories; translate uncertainty explicitly and avoid making broad uptime promises in a generic fallback. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test missing telemetry, partial service failure, delayed detection, maintenance windows and a feature hidden behind a regional configuration without assuming its availability. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

34. An accessible form-validation summary

Reader task and input contract. A form has required fields, optional fields and errors that may be announced together. A screen reader receives an accessible summary. The translator must first identify the actor who receives the message, the event that triggered it and what the current screen permits the reader to do. Where the state is uncertain or differs between data sources, write that uncertainty into the brief rather than asking a target-language phrase to cover it invisibly.

Failure to diagnose. The summary says “One error” but the visible page highlights three invalid fields because the server and client counts differ. This is not merely a question of picking a more fluent synonym. A dynamically inserted word may appear accurate in one screenshot while the same pattern communicates an unsupported claim for a different input. The reviewer should describe the exact wrong inference a reader would make before proposing a repair.

Meaning mechanism. Count correctness, focus behavior and grammatical selection interact. A perfectly localized sentence is still inaccessible if it reports the wrong total or cannot reach the errors. Read the full assembled message aloud in the target language with several plausible values. Ask whether a different word order, classifier, preposition, agreement form or full-sentence variant is required. If the defect comes from the underlying field rather than the translation, route it to the product owner instead of hiding it in wording.

Message design and evidence. Use one source of truth for validated errors, translate complete summary variants, and connect the message to appropriate accessible semantics and focus management. Preserve the variable’s identity, document any permissible target reordering, ensure all selected patterns contain complete claims and require a structural parser check. The target variants should remain natural rather than treating the source English phrase as a universal template.

Diagnostic tests. Test blank submission, multiple errors, errors removed after correction, keyboard-only navigation and long field labels that are read with the error summary. For each observed failure, record input values, message ID, locale, formatter version, rendered output, expected user understanding and the responsible correction. A reviewer should then repeat the test after repair, including the branch that originally looked correct, because changes to fallbacks or shared resources can create regressions elsewhere.

Part III. Technical laboratory: how to find the exact mechanism behind an MF2 failure

A useful translation laboratory does not ask only whether the target language looks natural. It asks what value was supplied, which message was selected, which function handled it, which grammatical or business condition was chosen, what the renderer displayed, and what the reader understood. These studies separate the parts of the pipeline that are frequently confused. They are fictional diagnostic setups, not assertions that a specific library has been tested here.

Laboratory 01: Identify whether an expression is data or language

Setup. A resource says “Pay {$amount :number} now.” A translator is asked to change a variable called amount to a translated identifier, and a developer says the new name will be easier for readers. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. The variable identifier is an interface contract with the caller, not a visible word choice. The visible verb and payment description need translation, while changing the variable name in one locale can disconnect the resource from application data. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. In the source editor, locate the callsite supplying amount, document its type and whether currency is separately identified. If the value is money, the generic number formatter may be insufficient. The localization brief should specify payment state, rounding, currency, and whether “now” accurately describes the required action. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Compare a render with the correct value, a render with a missing value and a render with a negative adjustment. A missing-variable error should not be disguised as a blank price. If the UI pays an invoice only after confirmation, the button and surrounding message should not claim settlement already occurred. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 02: Separate text changes from code token changes

Setup. A notice pattern contains a bracketed function expression and an adjacent literal explanation. A translation tool highlights the whole sequence as editable, tempting a reviewer to alter syntax. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. A translation editor that treats braces and annotations as free prose can produce parse errors, while a tool that freezes an entire sentence can prevent natural word-order changes. Both extremes are costly because message structure and linguistic expression have different permissions. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Use syntax-aware tokenization to mark identifiers and structural tokens as protected, but leave sentence content and permitted expression placement editable. Record exceptions for application-defined literal values. Translators should see a readable rendered preview as well as the underlying pattern. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Ask a reviewer to move a variable across a target sentence without renaming it, then deliberately corrupt the function annotation in a test branch. The first operation should be permissible; the second should fail a parser or lint gate before the resource reaches production. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 03: Classify zero without guessing the plural category

Setup. A notification counter is zero. A team assumes the selector must choose the category named zero, irrespective of the target locale. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. An exact numeric key and a language’s plural category are different routing mechanisms. A language does not necessarily define a plural category for zero, and the special meaning of “no notifications” is a product decision rather than a grammatical law. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Specify a deliberate exact-value zero variant where the product needs it; otherwise let the locale-specific numeric selector choose a grammatical category. Keep one catch-all and ensure the displayed number agrees with the branch’s words. Do not hard-code English plural knowledge into other languages. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. For each locale, create values that reach the relevant categories in the deployed CLDR data, then add product exceptions such as a zero-state action. Inspect the resulting complete message for idiomatic agreement and correct user instruction. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 04: Test a rounded decimal against selection

Setup. A rating system stores a mean of 1.49, displays one decimal place, and selects a phrase based on the unrounded numeric input. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. The output may show a different visible value than the one the product conceptually selected. A sentence that looks like “1.5 review” can confuse users even when the underlying selector follows the implementation’s specified rules. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Decide whether the interface is reporting an exact quantity, an average, a rounded measurement or a categorical status. Treat the display policy and selection policy as one design decision; a reviewer must not silently change numeric precision in translation to repair awkward grammar. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Test values just below and above rounding thresholds, negative values if valid, very small decimals and numbers whose category changes with fractional digits. Log the raw value, formatted value, selected branch and expected reader understanding. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 05: Check exact keys against locale categories

Setup. A developer builds variants for 1, one and fallback, expecting that the literal 1 and the grammatical one category always coincide. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. Exact matching can take precedence over category matching. The source pattern may deliberately distinguish a unique product state at the numeric value 1 from a general grammatical pattern containing values that belong to one in a particular locale. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Name why an exact exception exists. If it describes a free-item promotion, explain whether the exception is universal across markets or an artifact of an English copy experiment. If no business exception exists, grammatical selection is usually the more portable default. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Test values that a target locale classifies as one but that are not numerically 1, where applicable, and compare the copy with the exact 1 case. The linguistic reviewer should know which distinction was intentional and which was accidental. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 06: Document every selector and key count

Setup. An MF2 message combines a status category and a count. A translated variant provides one key, although the matcher expects two. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. A variant with fewer keys than selectors is structurally incomplete. It is not a case of missing punctuation or a polite tone; the message may be invalid according to the data model regardless of how beautifully its body is translated. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Review the matcher arity and every variant line as a small decision table. Require a catch-all combination covering all selectors. Consider whether a simpler single-axis message architecture would reduce duplication and improve comprehensibility. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Use a parser test with intentionally mismatched key counts, then a truth table of supported status and quantity combinations. Confirm that every expected combination reaches a sensible human-facing sentence and that the fallback never makes a false claim. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 07: Make fallback language safe without treating it as proof

Setup. A team writes a catch-all variant: “Everything worked.” They reason that it will almost never be shown because all known enum values have named branches. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. The catch-all is a required structural backstop, not a certificate that unknown state equals success. New enum values, resolution errors and unexpected inputs may reach a fallback in circumstances the author did not anticipate. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Choose a neutral and accurate fallback with a path to more details or support. Instrument unexpected selector values so the product can improve its data contract rather than concealing new states. Distinguish user-facing recovery from diagnostic telemetry. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Inject an unknown status, a missing selector input and a future enum in a test build. Review whether the message claims anything stronger than the runtime knows, whether the user can still act safely and whether the error is discoverable by engineering. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 08: Distinguish a parser error from a runtime error

Setup. A resource missing its final closing braces fails before formatting; a different resource parses but receives no value for one placeholder. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. These problems should not be diagnosed under the single label “translation failed.” The first concerns message syntax. The second concerns runtime resolution. Their recovery routes, ownership and scope differ. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Run static checks on the resource catalog independently of the application, then run formatting tests with typed values. Classify syntax errors, data-model errors, resolution errors and function errors according to the relevant version of Unicode’s specification. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Deliberately break each failure class in a test resource. Confirm that the release pipeline reports a meaningful error before shipment and that a fallback rendered by the library is not treated as approved public copy. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 09: Handle an unknown function responsibly

Setup. A source message requests a custom formatting function that exists in a development runtime but is missing from the production locale pipeline. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. A source file can appear legitimate to translators while production reports an unknown-function error. The issue is an implementation capability mismatch, not a linguistic choice that can be solved by paraphrasing the sentence. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Create a compatibility matrix listing required, recommended, draft and project-specific functions supported by each deployed library and version. Require engineers to document namespaces and return types for custom functions. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Run the message through the actual production formatter, not just a preview tool. Remove the custom function as a controlled design change or deploy a compatible implementation; then repeat output and error tests across all locales. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 10: Do not assume draft date functions are universal

Setup. A message includes a date-time expression and a translator assumes it must produce exactly the same format as a different JavaScript library or an older ICU formatting pattern. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. Unicode CLDR 49 identifies date and time functions in a draft portion of the MessageFormat specification. API and option semantics can differ across runtimes, and the same label may produce output with different zone assumptions. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Pin the implementation, confirm function and option support, and test with a typed date or timestamp. If a project chooses a compatible preformatted value rather than a draft function, document the trade-off and avoid turning a machine-ready instant into a locale-ambiguous string. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Use a time just before and after a daylight-saving transition, a date-only event and a long locale label. Capture the result from the deployed engine and ensure the user sees the intended date and time zone. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 11: Preserve opaque identifiers that resemble numbers

Setup. An invoice number begins with several zeros, contains a hyphen and is read aloud in a support call. A developer sends it through a number formatter for digit grouping. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. The identifier is not a quantity. Numeric formatting can strip leading zeros, alter separators or remove an embedded structural prefix, causing the customer to quote a different reference. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Declare the value as an opaque string and document whether it must remain byte-identical, normalized for display or announced digit by digit. Localized surrounding words can change, but the identity-bearing sequence should not silently change. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Test leading zeros, long identifiers, lookalike characters, copy-and-paste, screen-reader pronunciation and matching against the authoritative record. Reject any change that makes the rendered identifier refer to a different object. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 12: Make a money amount legible without changing the transaction

Setup. A purchase has a currency amount and a separate ISO currency code. The user interface has localized language but the transaction currency does not change with that language. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. A product displays a new currency symbol based on locale without converting the value, making the charge appear to be in a different currency. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Locale is a formatting context, not an exchange operation. A source contract needs to identify amount, currency and rounding requirements; currency identity cannot be inferred from the reader’s language. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Keep numeric value and currency together in domain logic, use supported money formatting with explicit code and review any tax or exchange explanation separately. If the implementation lacks needed support, use a controlled formatting adapter outside the translator’s free text. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 13: Respect the difference between category and status selectors

Setup. A role selector chooses among reader, editor and owner. A product redesign renames a role but retains the old internal enum key for compatibility. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. The target translator changes the enum key to the new visible role label, and the runtime no longer recognizes it. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. A programmatic state code and a human-facing role description are different representations. The enum may be stable even when product language changes, and a hidden state can map to different target wording depending on audience. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Document stable codes, visible names and permitted user claims in an enum termbase. Translate complete sentences, including actor and scope, while leaving decision keys intact unless engineering updates the contract. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 14: Audit rich text and link meaning together

Setup. An inline note contains a highlighted phrase and a link to a privacy explanation. The target sentence needs a different word order and a longer link phrase. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. The emphasis remains attached to the original English word position rather than to the equivalent meaning, and the link text suggests an action not provided by the destination. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Markup is application-defined structure; it should be reviewed at the semantic level, including what the formatted element does and how its text is announced. Translator-controlled prose should not be forced into English token boundaries. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Allow approved markup placement changes while keeping tag identity and secure destination handling controlled. Review the accessible link name, focus sequence, text contrast and the actual page the user reaches. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 15: Compare text direction in input and output

Setup. An Arabic-language sentence contains an alphanumeric item code and a contact email address. The UI component derives paragraph direction from the surrounding page. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. Punctuation appears to belong to the wrong identifier, and copying the displayed string yields a different human-readable order than expected. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Bidirectional rendering is a combination of character properties, formatting strategy and embedding environment. The translation string alone cannot guarantee correct visual order in all components. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Use a documented Unicode-aware isolation policy, keep values as data, and avoid manual insertion of invisible controls unless specifically reviewed. Separate a language-direction defect from incorrect translation of surrounding text. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 16: Verify apparent fluency against action labels

Setup. A deletion dialog has a heading, a descriptive sentence, an irreversible-action button and a cancel button. Each is translated by a different workflow. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. The sentence warns of permanent removal, but the primary button is labeled with a generic “Continue,” obscuring the irreversible consequence. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. One translated segment can be correct while the interface as a whole communicates an unsafe action. MF2 resources should be tested as interaction units when the text determines consent or commitment. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Bring related labels into the review context and compare their claims with button handlers. Choose decisive visible labels and clear accessible names; avoid using dynamic counts as a substitute for describing the actual action. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 17: Check variant coverage when the product adds a new state

Setup. A source catalog is translated into many locales. After release, engineers add a new delivery-state enum without asking localization reviewers to update the associated message variants. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. Previously exhaustive selections silently route to an imprecise fallback. No parser error is guaranteed because the message still contains a structurally valid catch-all. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Treat the enum schema and message catalog as linked versioned contracts. Adding states should trigger targeted translation review even when formatting remains technically valid. Automated tests can flag new values reaching a fallback unexpectedly. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Create a golden dataset containing every enum value, update it when the schema changes, and compare outputs before release. Confirm that unknown states remain safe, then add an explicit approved phrase where necessary. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 18: Protect user names without treating them as translated copy

Setup. A collaboration app inserts a person’s user-entered display name into a grammatical sentence. Names may include spaces, emoji, symbols and scripts unfamiliar to reviewers. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. A translator modifies a sample name inside the catalog, and a preview seems polished; the live name later breaks punctuation or the agreement of the sentence. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Names are runtime data and should not be normalized into invented translations. Some languages require grammatical context around names; that must be designed carefully without rewriting the stored identity. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Keep names as data, use a neutral syntactic construction when needed, give translators realistic examples and specify escaping and length limits. Distinguish a person’s preferred display form from a grammatical label. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 19: Separate linguistic length from available pixel width

Setup. A design uses a narrow toolbar label, with a source phrase that is only three words. A target-language translation is longer and gets truncated. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. The final label drops the word “not,” reversing a prohibition, or hides the object of the action, making the control ambiguous. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Translation expansion is a layout risk, but deleting essential scope to meet the original width is not a faithful solution. Natural language has variable lengths, and runtime insertion increases uncertainty. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Design flexible components with line wrapping, responsive space and a visible full accessible name. When short alternatives are authorized, review their function and comprehension separately instead of removing critical terms. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 20: Distinguish missing translation from missing runtime data

Setup. A locale fallback chain is configured so that unavailable target strings may use a source-language resource. A placeholder is separately absent from the caller’s inputs. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. The team interprets an unresolved variable as evidence of missing locale data and adds a duplicate translation key, leaving the actual defect untouched. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. A catalog lookup failure and a message-expression resolution failure occur at different layers. One selects a resource; the other formats a selected resource. Their diagnostics and controls should remain separate. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Log message ID, requested locale, resolved locale, selected catalog entry, input map, renderer version and error channel. Avoid exposing raw diagnostic symbols to users when a safer interface fallback can be designed. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 21: Version the library, specification and locale data separately

Setup. An application migrates its message formatter while also updating Unicode locale data and product copy. The release introduces several observable differences. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. Because everything changed at once, engineers cannot distinguish intentional new grammar from a formatting regression or a changed plural rule. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. The specification, runtime, CLDR data, catalog and product state logic are related but separately versioned. A reproducible failure needs all of them recorded. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Maintain a release manifest with resource commit, implementation version, CLDR version, target locales, message contract and test dataset. Run comparisons before and after each independent change where feasible. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 22: Use pseudolocalization to discover structural defects, not prove grammar

Setup. A product replaces its human-readable strings with exaggerated accented text and long expansions to see whether layouts survive. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. The UI passes pseudolocalization, and the team assumes all target-language grammar and pragmatic meaning must therefore be correct. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. Pseudolocalization can reveal unlocalized fragments, clipping, encoding issues and concatenation problems. It cannot verify that a particular language selects the right grammatical variant or preserves cultural register. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Include both pseudo-expansion and real bilingual QA. Test value interpolation, directionality, branch coverage and interaction context. Record which failures a pseudo-locale is designed to expose and which it cannot. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Laboratory 23: Apply source-content governance to AI translation suggestions

Setup. An automated system proposes translated MF2 variants from a source catalog and surrounding screenshots. A reviewer receives fluent output quickly. Before touching the translated sentence, freeze the resource version and write a short statement of the intended user action. The test is incomplete if its input types, actual values, selected locale, formatter implementation and output surface cannot be reproduced. Those facts let two reviewers reach the same diagnosis rather than disagreeing about a screenshot.

Mechanism. The model silently renames variables, omits a fallback branch or invents an error description that sounds plausible but is not supported by the application state. This is the essential explanatory step: find whether a broken result comes from message syntax, data-model validity, runtime resolution, selection logic, language choice, rendering or a source-content claim. A convenient-looking wording adjustment may hide the defect without repairing it; a good localization issue explains the layer in which the failure is born.

Repeatable intervention. AI can assist with suggestions but does not validate executable syntax, domain facts or runtime contracts by merely generating a fluent string. The review chain must separate machine proposals from verified releases. Preserve any stable identifiers and agreed terminology during this work. Where a target language requires a different clause order, agreement pattern or register, allow the expression to be rebuilt naturally inside the permitted resource structure. Explain any necessary source-code change to engineers before a translator tries to compensate by inventing data or modifying protected tokens.

Verification and transfer. Constrain suggestions to editable language spans, provide schema and context, parse all generated patterns, check every variable and selector, and require bilingual human review proportional to the risk. Keep both a successful case and a deliberately adversarial case after the fix. The first shows the expected path remains readable; the second shows why the defect no longer occurs. Write down the result, not merely “passed,” so that a later library upgrade or catalog revision can be compared against actual evidence.

A practical review question is: if the same message is rendered with an unfamiliar script, a longer input, a missing value and a product-state transition, what would the reader believe happened? That question forces the team to inspect meaning rather than only grammar. The answer should be specific to this laboratory’s user task and constraints, and should lead to one testable correction rather than a generic instruction to “improve translation quality.”

Part IV. A reproducible MF2 QA matrix that teams can actually maintain

A full factorial test of every locale, value, screen, runtime and platform can become unmanageable. Use risk-based sampling with explicit boundaries. First test the parser against every message in the catalog. Then build variable-level boundary sets: empty and long strings, zero and representative plural categories, exact-value business exceptions, negative and decimal numeric values when permitted, future enum values and missing inputs. Add high-risk screen states such as payments, permissions, authentication and irreversible actions. Finally test a representative real-language and real-device set, expanding it when evidence suggests a hidden risk. This is not an excuse to skip uncovered branches; it is a way to direct human review where it can find meaningful failures.

For every tested output, record six facts in a durable format: the resource identifier and revision; the exact input map; requested and resolved locale plus locale-data version; formatter and renderer versions; the actual displayed or announced result; and the reason a reviewer considered it correct or incorrect. A source screenshot can be useful, but it does not substitute for an input map. Reproducing a bug from a screenshot alone is difficult if the message depends on hidden state or changes with time.

Run at least four distinct kinds of checks. A syntax check determines whether the pattern is well formed. A semantic structure check determines whether selector arity, fallback requirements and declarations follow the data model. A runtime test determines what particular values and functions actually produce. A bilingual user-meaning review determines whether the result tells the target reader the right thing. These checks overlap but are not interchangeable. A valid parser cannot judge a fraudulent claim; a human linguist cannot guarantee that an unseen runtime branch will resolve.

When the QA system flags a mismatch, use a short decision tree. If no pattern can be loaded, inspect syntax and resource loading. If the pattern loads but cannot resolve input, inspect data binding and function support. If selection chooses the wrong variant, inspect numeric or string selection and exact keys. If the right variant is chosen but the sentence is misleading, inspect the language and source business meaning. If the right words appear incorrectly or invisibly, inspect rendering, direction, markup and accessibility. This hierarchy keeps fixes close to their causes.

Part V. One full recovery: repair a dynamic message from source meaning to shipped behavior

Consider a fictional task application displaying the number of drafts awaiting approval. The source team proposes the fragment “You have {count} drafts waiting,” with a count provided by application code. A rushed translator receives only the sentence, no screenshot or state definition, and is told to preserve the original order of all tokens. An engineer proposes string concatenation so that the target can reuse “draft” and the plural suffix in several screens. None of these choices is obviously malicious. Together they create a predictable multilingual defect: the source design gives the translator too little context and too little freedom to construct a natural sentence.

Begin with the source meaning. The count refers to drafts waiting for the signed-in user’s approval, not all drafts in the workspace. It is an integer that cannot be negative. A value of zero should explain that there is nothing to approve; it must not imply that no drafts exist. A draft may be withdrawn after the count is retrieved; the UI should not promise exact state if it cannot update consistently. The message can therefore say what the product currently reports, but should not claim future completion or universal absence.

Next write the user journey. The reader lands on an overview screen, sees a count, and can open a queue of pending approvals. The target-language sentence should direct attention to the queue without making the role or number ambiguous. If a person’s name appears in another message, keep it separate from this count unless the actor relationship is necessary. If the source writer uses “waiting for you” rather than simply “waiting,” record whether that is a fact the current product can prove. The translator needs this distinction more than a bigger glossary.

For a simple English illustrative resource, one possible MF2 pattern is the following. It declares the count as an integer and supplies an exact zero branch, a grammatical one branch and a catch-all. It is a starting pattern for translation, not a finished resource for every locale; a target language may require additional category branches or a different sentence structure.

.input {$pendingCount :integer}
.match $pendingCount
0   {{No drafts need your approval.}}
one {{One draft needs your approval.}}
*   {{There are {$pendingCount} drafts waiting for your approval.}}

Review the exact zero case independently from grammatical selection. It expresses a product-specific empty queue state. Review the one branch because it uses singular agreement in English, but do not assume that the one category has the same numeric membership or morphological expression everywhere. Review the fallback because it contains a variable and a full sentence. Check that the renderer receives the expected integer, that the value has not been formatted as an opaque identifier, and that the target-language reviewer can rearrange the sentence inside each branch.

Create the behavioral tests: zero reports the empty queue; one displays a single item needing approval; two displays a plural count in English; a large count remains legible on narrow screens; missing input produces a detectable resolution error rather than a silent false success; a negative value is rejected at the domain layer because the contract forbids it; a queue that changes while the screen is open refreshes coherently. In a target language with more category distinctions, generate representative inputs for the actual CLDR rules. An expansion test should confirm the label remains readable; an accessible test should confirm that the count and task are announced together in a useful order.

The correct release decision comes from agreement among the domain source, the translated variants, the selection implementation and the observed output. If the product’s queue count is wrong, return the bug to application data. If the source’s “your approval” phrasing is unsupported, revise the content contract before translation. If a target-language agreement is wrong, revise the affected branch. If an exact key catches an unintended case, review the matcher. If the result clips a negation, repair layout. The end-to-end process is longer than replacing a noun, but it is reproducible and can be taught to a new team member.

Part VI. Questions readers commonly ask

Is MessageFormat 2 the same as ICU MessageFormat?

No. MessageFormat 2 is a successor specification with a different model and syntax. It is related to the long-standing ICU MessageFormat ecosystem, but an MF1 plural pattern is not an MF2 pattern. Production libraries and catalogs need version-aware migration. Continue to use a supported MF1 toolchain if that remains the correct match for an existing application’s requirements; do not rename resources to MF2 without confirming parsing and runtime output.

Can AI translate an MF2 resource correctly without a human reviewer?

AI can draft candidate sentences and help find inconsistencies, but a generated result is not a proof of conformance, domain fidelity or appropriate grammar. Parse the message, compare protected identifiers and all selector variants, inspect the runtime, and assign human review to consequential claims. For high-risk messages, the reviewer should know the underlying product or domain state, not merely the two languages. An apparently fluent machine suggestion can omit a negation or fabricate a stronger promise.

Why are plural categories not simple translations of English singular and plural?

Because languages categorize quantities differently and use those categories to select grammatical forms. Unicode CLDR provides plural-rule data, but the names one, few, many and other are category labels, not universal English numeric definitions. The relevant categories depend on locale and sometimes on numerical representation, including fractional values. A translator still has to compose the appropriate phrase for each selected branch.

What should a translator do if a variable is unclear?

Ask for the input contract: what it represents, its type, which values can occur, its source, its units, whether it can be absent and whether it is known precisely. Request the screen context and the reader’s task. Never silently rename a protected variable or convert uncertainty into a definite claim. A precise question returned to the source owner is a productive translation outcome when the available evidence does not support an accurate decision.

Is a valid MF2 message necessarily an accurate translation?

No. Validity addresses syntax and semantic requirements of the message data model. Accurate translation addresses the meaning of the rendered result for a reader. Both are needed. A valid message can report an incorrect account status or omit a payment condition; a beautiful translation can also fail to render because its syntax is invalid. Teams should test those dimensions independently and then together.

How should we translate dates, currency and measurements?

Start by identifying the data type and the intended real-world claim. Use locale-aware formatting functions that your pinned implementation supports, while preserving currency identity, measurement unit, time zone and required precision. The CLDR 49 MessageFormat specification contains some date/time functions in a draft section; do not assume every implementation supports them or that their option behavior matches a different API. Verify the actual runtime, and do not infer unit or currency conversion from the user’s language.

What should localization QA do with untested branches?

Treat them as missing evidence. A branch may be structurally valid while never being exercised by the chosen test values. Generate cases that cover every relevant enum and plural category, especially exact business-rule values and fallbacks. For particularly consequential flows, require explicit human approval of the full set of variants. If source conditions make a branch unreachable, record why, so that a future schema change triggers renewed review.

When should a message be split into separate resources?

Split when the pieces represent independent user tasks or when separating different states makes the interface safer to reason about. Do not split grammatical fragments only to reduce translation entries. For example, a status label and a timestamp may be separate semantic components if the interface presents and announces them separately. A sentence containing a count, an actor and a condition often needs to remain one translatable unit so that the target language can reorder the entire construction.

Part VII. Transfer: use the method beyond software translation

The same discipline improves document translation. A policy statement contains an actor, an obligation, a condition, a time and sometimes an exception. Treating those features as a structured meaning contract helps prevent omission and scope reversal. It also helps document designers see where the source is ambiguous. The difference is that software messages make branches executable, while prose asks humans to infer many branches. The reviewer can still use a decision table to reconstruct possible readings before translating.

It also improves human conversation mediated by translation tools. In a dialogue, a reply may depend on an earlier sentence, an implied request or a role relationship. A speaker who asks whether something is ready may be checking permission to act rather than requesting an abstract status. Context-aware translation research in 2026 reinforces the value of conversational context in resolving ambiguity. Unlike a tightly specified message catalog, a conversation may not have explicit input schemas; the transferable habit is to identify missing context and avoid confidently filling it with invented assumptions.

For documentation, carry the method into version control. Separate what can change linguistically from stable IDs, citations, test values, product names and evidence states. Decide what can be updated independently. A translator who can follow the source contract and read structured diagnostics is less likely to approve a translation that happens to sound natural but refers to the wrong object or status. For the reverse direction, a source author who learns to write translatable messages can improve the clarity of the original language as well.

For language learning, choose a single source sentence with a count and two possible states. Instead of memorizing a bilingual list, ask what changes when the count is zero, one, several or unknown; whether the target needs another word order; and what the words imply about certainty. The insight is a transfer of relations, not a collection of dictionary substitutions. That exercise is useful in any language pair and is especially revealing when the source and target express number, politeness or time differently.

Part VIII. Next routes: what to read after dynamic-message translation

Return to the architectural root, Master Art of Translation | The Complete System for Moving Meaning Between Languages, when the challenge is broader than software messages: source analysis, equivalence, context, terminology, workflows, cultural transfer and general quality assurance. This MF2 child stays responsible for the distinct combination of dynamic runtime values, variants, executable message structure and rendered multilingual meaning.

When the underlying difficulty is learning and retrieving precise words, collocations or conceptual distinctions rather than controlling cross-language runtime selection, use the protected Vocabulary Learning Hub. When the difficulty is understanding English sentence relations, grammar, reference, register or how an English paragraph works independently of translation, use How English Works | The Complete Map and Learning Routes. These are separate owners, not content for this translation article to reproduce.

For a short application-specific introduction to established ICU plural and select patterns, continue to How People Translate Quickly | ICU MessageFormat Plurals and Selects. For the primary technical authority, consult Unicode CLDR 49 MessageFormat specification, the Unicode translator guidance and the MF2 function reference. Use the source most relevant to the decision: official normative definitions for conformance, translator guidance for what may change, and your installed runtime documentation for supported behavior.

The final discipline can be expressed as a single chain: understand the user task, specify the data, protect the message’s structural promises, let the target language reorganize expression, test difficult values, inspect the real user experience, and preserve enough evidence to explain every decision. Translation is complete only when the message still does its job in the new language, under the values and conditions that real people can encounter.