Translation master architecture: EDKSG-TRANS-MASTER-WORLD-1200. A world-facing practical chapter on translating accessible interfaces while preserving operable meaning for people using screen readers, voice control, keyboard navigation, magnification and other assistive technologies.
How to translate accessible web interfaces without breaking what they do
How do you translate a website or app so that screen readers announce the right language, buttons retain their accessible names, and localized forms remain usable? The practical answer is to translate both the words people see and the programmatic relationships through which people navigate them. This guide explains accessible localization, multilingual accessibility testing, ARIA labels, web translation QA, and the steps required before a localized interface is safe to release.
Most translation failures in interactive products are invisible in a screenshot. A button may visibly say “Save” while its accessible name says “Submit”; an error message may appear in the selected language while its linked input has no error relationship; or a page may display translated text but retain an incorrect document language. The real job is not replacing words. It is preserving instructions, choices, states, relationships, and outcomes through every rendering path.
Here is a repeatable method for multilingual web accessibility: identify each user task, record the original visible and programmatic messages, define the meaning that must survive translation, localize with context, inspect the accessibility tree and real interactions, test the target-language experience with keyboard, speech input and relevant assistive technologies, repair defects, and keep evidence attached to the release. Work through the examples below to diagnose precise faults rather than treating every failure as a vague translation problem.
Quick answer and the release rule
Short answer: the localized interface is not ready merely because every string is translated. It is ready when a person can understand, locate, operate, recover from errors, and verify the intended result using the rendered interface and the accessibility information exposed by the product. A visible label, computed accessible name, accessible description, role, state, focus order, language information and status announcement may all contribute to the same task.
The safest design treats accessibility semantics as part of a translation contract. Write down what a control is called, what it does, which state it can enter, what happens after activation, what warning applies, and how a user learns of success or failure. Preserve these facts in every locale. A control named “Remove” must not trigger a permanent deletion if the translated confirmation suggests temporary hiding. A status translated as “Saved” must not be exposed before persistence actually succeeds.
This chapter does not promise legal compliance or universal compatibility. WCAG provides testable success criteria, but actual support varies across browsers, operating systems, speech engines and assistive technology. A machine checker can reveal structural problems; it cannot prove that a human speaker understands a label or that an interaction is usable in context. Automated inspection and human testing therefore complement one another.
The hidden problem: one interface, several simultaneous texts
Every localized component has at least a visual layer and a programmatic layer. It may also have speech, braille, keyboard and error-recovery layers. These are not always identical strings. The visible text might be “More”; the correct name for an otherwise ambiguous icon might be “More payment options.” The important point is that each channel describes the same action to the person using it. Changing only the visible text leaves a fractured interface.
A translation memory typically stores source and target segments. A user, however, experiences a sequence: find the relevant action, predict its outcome, activate it, understand the response, and correct any mistake. Translation assets without component context often fail on the first or fourth step. An isolated source key such as `close` might refer to dismissing a dialog, shutting a session, closing an account, or stopping a device. These actions must not be collapsed into one undifferentiated target-language term.
Accessible names are computed, not simply read from the nearest visible string. In HTML, the naming algorithm can take `aria-labelledby` or `aria-label` ahead of certain native labels and element content. Thus an untranslated or stale ARIA property can override a carefully translated button caption. Likewise a visually translated image can retain obsolete alternative text. Auditing only visible pixels systematically misses these defects.
Language is another structural signal. WCAG 2.2 distinguishes the default human language of a page (success criterion 3.1.1, Level A) from identification of passages in another language, subject to exceptions (3.1.2, Level AA). Markup such as the HTML `lang` attribute helps software select appropriate pronunciation and presentation rules. A language switcher must change more than what appears in a menu: it should ensure the rendered content and associated metadata correspond to the selected language.
Names and descriptions are not interchangeable. An accessible name identifies the control, whereas an accessible description can explain constraints, consequences or additional instructions. If every translated validation rule is forced into the name, the result may be noisy and difficult to navigate. If the constraint is nowhere exposed, the user may repeatedly encounter errors. A good localization specification assigns each message to the correct semantic place.
These distinctions matter for voice input too. WCAG 2.2 success criterion 2.5.3, Label in Name, requires a component’s accessible name to contain its visibly presented text label where the criterion applies. It helps people say the label they can see. Translators should not shorten the visible string and leave a mismatched programmatic alias unless the relationship still meets the criterion and actual voice-control workflows operate.
A seven-stage method for accessible translation
Stage 1 — map tasks before strings. Pick a complete task such as searching, changing preferences or correcting a payment form. Record each screen, action, decision, status, and recovery opportunity. For each control, capture a stable identifier and the component type. Translation decisions made from this task map are less likely to confuse “close this view” with “close an account.”
Stage 2 — collect a semantic inventory. For each screen element, capture the visible text, accessible name, accessible description, role, state, language, keyboard behavior, focus destination and downstream system result. If an element is decorative, record that decision rather than inventing descriptive copy. If the element conveys data, explain which part must be announced and which part remains visual.
Stage 3 — define invariants. An invariant is a fact that must survive the language change: whether an action is destructive, whether a field is required, whether a result is final, whether a filter is applied, what a number measures, and whether an item belongs to the user. Keep exact dates, amounts, product identifiers, units and names anchored to their real data sources. A translation must not modify the underlying permission, threshold or status.
Stage 4 — translate with UI context. Give linguists screenshots, interaction recordings, message keys, destination screens and notes about ambiguous words. Provide space for grammatical variation and number-dependent messages rather than concatenating fragments. Ask for a short visible label and, where necessary, separately authored concise descriptive text. Treat placeholder text as an example, not a substitute for a persistent label.
Stage 5 — inspect rendering and semantics. Check the actual page language and any embedded passages; compare visible labels against computed accessible names; check names, roles, values and states; inspect associations between labels, controls, instructions and errors; and verify that translated live-region content is announced after the underlying action has genuinely completed. Test the HTML as delivered, not merely the string file.
Stage 6 — test complete journeys. Use keyboard navigation, speech input where available, a screen reader and the product’s supported platform combinations. Test initial focus, error focus, modal boundaries, search results, confirmations, loading and timeouts. Do not assume a screen reader’s spoken pronunciation alone proves markup validity: W3C notes that some accessible-name pathways flatten language markup and may not preserve internal language switches.
Stage 7 — capture release evidence. Store the locale, component version, browser or app build, assistive technology, action performed, expected semantic result, observed result, defect owner and retest outcome. Distinguish a mistranslation from a design, implementation, content-model or platform compatibility issue. Re-run the task after source or translation changes. A claim of accessibility based only on a passing linter is incomplete.
Design principles for translators, product writers and engineers
The first practical rule is translate actions, not interface tokens. “Submit,” “Apply,” “Save,” “Send,” and “Confirm” are not interchangeable because their consequences differ. Specify what changes when the user activates each control. For a screen reader user jumping between buttons, an accurate, concise, distinct name is often more useful than an elegant but ambiguous synonym.
The second rule is preserve the source-of-truth hierarchy. A localized message string should not hard-code a quantity that comes from a data model. A status message should not say a transfer succeeded before the server confirms it. If the source content changes, translation QA must re-evaluate the meaning, not just whether every key has a value. This chapter builds on the prior discussion of regression testing but concentrates on the human and machine interpretation of interface semantics.
The third rule is do not use an ARIA attribute to hide poor content design. Native semantic HTML and visible labels are usually the clearest starting point. `aria-label` can be valuable when no suitable visible naming text exists, but its precedence can also override text that a translator fixed. When visible text already names the control, confirm that the computed name and speech-command path remain aligned.
The fourth rule is treat errors as instructions. “Invalid” without naming the field or explaining the allowed repair is not enough. Translate the cause accurately, identify the affected control, make the error relationship available programmatically, and ensure focus or status behavior allows the user to discover the correction. An error message is useful only when the person can complete the task after reading or hearing it.
The fifth rule is test language and direction separately. The content language is not identical to the layout direction, and text direction is not evidence of language identity. Mixed-script strings, serial numbers, dates and email addresses can reorder visually. Native rendering, Unicode handling and `dir`/`lang` use should be checked within the implemented interface; do not assume that changing CSS alignment resolves all bidirectional-text problems.
The sixth rule is do not over-announce. Routine status updates can use appropriate status semantics, but repetitive or assertive announcements for every movement can interrupt reading and obscure urgent information. Translate alert priorities as part of the interaction design. A language string cannot repair a poor live-region strategy on its own.
The seventh rule is record locale-specific exceptions openly. An abbreviation that works in one language may be unintelligible in another; a written word may be pronounced unexpectedly by a voice synthesizer; a line break may divide a compound word or separate a number from its unit. These are defects to diagnose and document, not reasons to declare the whole language unusable.
The eighth rule is provide human review for high-consequence content. Health, identity, financial, legal and security workflows deserve contextual review because mistranslations can alter choices and obligations. Testers should preserve uncertainty and avoid claiming a transaction completed, a diagnosis was made or an account was deleted unless the underlying event truly occurred.
The audit matrix: what to check in every localized component
Visible meaning: what does the person see, and what action does that text predict? Programmatic meaning: what are the computed accessible name, role, description, value and state? Language: what page language and local overrides does the browser expose? Navigation: where does keyboard focus move before and after use? Feedback: what changed, how is that change announced and is the message truthful? Recovery: can the person undo, correct or seek clarification?
Write the six answers in a review sheet for every component that carries task meaning. A mismatch between the visual and programmatic channels deserves a specific defect, not a general comment such as “screen reader issue.” Name the offending key, attribute or event and assign a repair owner. The most useful test cases state the expected accessible behavior before showing what failed.
Testing should cover at least two distinct rendering contexts where a feature relies on assistive technology. A pattern supported by one combination cannot automatically be generalized to every operating system, browser, voice engine, input method or braille device. When a limitation comes from third-party software, record the supported workaround and the evidence rather than inventing a guaranteed fix.
A worked pattern: translate a form without losing the user
Imagine a registration form with a visible heading, email field, password field, consent checkbox and Save button. The localization brief should name each field by purpose, explain its required state, distinguish password requirements from placeholder examples and describe where a submission outcome appears. Changing language must not turn an optional newsletter checkbox into an implied requirement.
The review begins at the heading and proceeds by keyboard. The email input needs a correctly associated label. A localized password requirement should be reachable as a description and should accurately reflect the actual validation logic. If submission fails, identify the failing input with text, preserve the user’s entered values when appropriate, and make the error discoverable. If submission succeeds, announce completion only after a positive server response. A translated “Saved” message is not evidence of persistence by itself.
Then repeat in another locale and compare, not word by word but action by action. Can a user identify the same required fields, navigate the same order, make the same choice and recover from the same error? That is semantic equivalence. A beautiful translation that changes consent, hides field purpose or prevents a person from finding feedback has not accomplished the task.
Failure modes that make translated interfaces look correct but behave incorrectly
Invisible stale text. The visible label is updated, while `aria-label`, `title`, `alt`, a tooltip or a hidden heading remains in the source language. Repair by checking the computed accessible name and all naming sources, not merely searching string files.
Misleading synonyms. A translated action appears polite but implies a different outcome. Repair by writing the real event, reversibility and permission change into the localization note.
Placeholder masquerading as a label. The example disappears when the user types, so the field purpose becomes ambiguous. Add a persistent, correctly associated field label rather than asking translators to write a longer placeholder.
Language declared for the wrong document. The interface changes language while the root element retains a stale language tag. Fix the rendered metadata and check language-specific fragments, while acknowledging real assistive technology variation.
Grammar by concatenation. Fragments such as “one” + “results” or a fixed word order break target grammar or convey the wrong number. Use whole messages with grammatical variants and variable protection.
Visual-only errors. A red outline or translated toast conveys failure without a text alternative, control relationship or appropriate announcement. Give users a discoverable, actionable explanation.
Premature confirmation. “Payment received” appears when the payment has only been initiated. Rephrase the state accurately and delay success announcements until confirmation.
Focus stolen by updates. Translation text length changes a component or re-renders a page, causing focus to jump. Preserve focus unless the interaction deliberately requires a new focus destination.
Overzealous screen-reader copy. A button name redundantly contains its role, such as “Send button,” when the technology announces the role itself. Prefer a distinct action name and use a description when more detail is essential.
Shared translation key with different intents. The same source word is reused for “Close dialog,” “Close account,” and “Close period.” Split by component and consequence so linguists can choose appropriate terms.
Truncated target strings. A button’s final word disappears at zoom or in a longer locale; the accessible name may remain complete, leaving sighted and speech-control users with mismatched clues. Fix layout flexibility and keep visible labels readable.
Incorrectly localized data. A date, amount or unit is copied as part of a static segment, creating a mismatch with live data. Maintain separate formatter and translation responsibilities and inspect the actual rendered value.
Worked accessibility and translation diagnostics: the casebook
The following cases are fictional, deliberately constructed teaching scenarios rather than reports about named products. Each describes an observable semantic failure, a repair, and evidence that should be collected. They are not one-word translation exercises: they combine interaction intent, accessibility exposure, risk and an end-to-end test. The purpose is to let a reviewer diagnose an unfamiliar product by comparison.
Use the worked cases as a training matrix. The target language is intentionally unspecified because a valid translation depends on the audience, grammatical system and product context. Each example asks the translator to preserve the real meaning without pretending that one universal phrase works in every language. The concrete control names are English-language source descriptions, not pre-approved target translations.
1. Controls: Save changes
Observed interface: the task presents Save changes. Specific defect: untranslated aria-label says Submit form. This is not a harmless stylistic variation. A user may expect a submission rather than saving preferences. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Align the computed name to the localized visible Save changes caption and retain the underlying save action. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Save changes is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Compare browser accessibility tree, persisted preferences and spoken command match. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
2. Controls: Close dialog
Observed interface: the task presents Close dialog. Specific defect: shared Close key also names the close-account procedure. This is not a harmless stylistic variation. The same word can imply a much more consequential action. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Use component-scoped keys and keep the dialog title available. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Close dialog is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Activate with keyboard and check only the overlay closes. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
3. Controls: Delete draft
Observed interface: the task presents Delete draft. Specific defect: accessible name says Archive draft. This is not a harmless stylistic variation. A person may reasonably expect recovery when deletion is permanent. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. State permanent removal in both the action and confirmation, where accurate. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Delete draft is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Check confirmation, undo availability and eventual draft state. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
4. Controls: Undo deletion
Observed interface: the task presents Undo deletion. Specific defect: a tooltip says Restore but the control is named Repeat. This is not a harmless stylistic variation. The action is hard to find in a list of controls. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Use an action-led name matching the recovery promise. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Undo deletion is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Perform delete and undo, checking result and focus. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
5. Controls: Open filters
Observed interface: the task presents Open filters. Specific defect: icon-only button retains generic More. This is not a harmless stylistic variation. A screen reader user cannot distinguish filter controls from unrelated more menus. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Name the exact filtering action and expose expanded state. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Open filters is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Expand and collapse with keyboard while observing aria-expanded. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
6. Controls: Download report
Observed interface: the task presents Download report. Specific defect: accessible label still names last quarter’s report. This is not a harmless stylistic variation. The user could download an unintended period with sensitive information. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Build name from the actual report scope rather than a frozen translation. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Download report is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Compare file identity, scope displayed and announced. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
7. Controls: Retry upload
Observed interface: the task presents Retry upload. Specific defect: control is translated as Restart account. This is not a harmless stylistic variation. The wording suggests abandoning the workflow instead of repeating transfer. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Separate retry from reset and associate the control with the failed file. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Retry upload is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Observe retry network state and success message. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
8. Controls: View details
Observed interface: the task presents View details. Specific defect: eight buttons share identical context-free names. This is not a harmless stylistic variation. A person navigating by buttons cannot identify which row each one opens. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Include object identity in an appropriate programmatic label without contradicting the visible phrase. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for View details is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Review the buttons list and destination record. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
9. Forms: Email address
Observed interface: the task presents Email address. Specific defect: only placeholder provides a label, and disappears on typing. This is not a harmless stylistic variation. The field purpose is lost during correction. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Add a persistent localized label associated with its input. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Email address is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Tab, type, delete and inspect the exposed name. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
10. Forms: Password requirements
Observed interface: the task presents Password requirements. Specific defect: localized helper promises eight characters while validator requires twelve. This is not a harmless stylistic variation. The user repeatedly fails an undisclosed condition. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Translate from the actual current validation specification and associate helper text. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Password requirements is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test a boundary-length input and inspect feedback. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
11. Forms: Required field
Observed interface: the task presents Required field. Specific defect: asterisk changes color but the required state is not available. This is not a harmless stylistic variation. Users who do not perceive color may miss a condition. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Explain required status in text and use the appropriate native required semantics. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Required field is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Navigate by keyboard and submit empty values. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
12. Forms: Confirm email
Observed interface: the task presents Confirm email. Specific defect: both email inputs have the same computed name. This is not a harmless stylistic variation. Users cannot tell first entry from confirmation. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Differentiate the field labels and preserve their comparison purpose. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Confirm email is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Navigate through form controls without relying on visual position. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
13. Forms: Preferred language
Observed interface: the task presents Preferred language. Specific defect: a dropdown lists language names but changes the page before an option is deliberately chosen. This is not a harmless stylistic variation. Keyboard exploration may unexpectedly erase work. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Define deliberate activation and state preservation before localizing option names. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Preferred language is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Use arrow keys and confirm saved form data. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
14. Forms: Consent choice
Observed interface: the task presents Consent choice. Specific defect: translation makes an optional marketing choice sound mandatory. This is not a harmless stylistic variation. The user may grant permission unintentionally. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Document the exact optionality and make checkbox grouping explicit. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Consent choice is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Review selection default, wording and submission record. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
15. Forms: Date of birth
Observed interface: the task presents Date of birth. Specific defect: placeholder suggests day-month order while parser expects month-day. This is not a harmless stylistic variation. A valid person receives an invalid-date rejection. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Explain the supported order or use locale-appropriate entry and parsing. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Date of birth is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Enter ambiguous dates and validate stored value. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
16. Forms: Address line 2
Observed interface: the task presents Address line 2. Specific defect: translation states Required despite the field being optional. This is not a harmless stylistic variation. The user may fabricate data to advance. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Mark optionality truthfully and ensure validator agrees. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Address line 2 is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Submit with the field empty and confirm acceptance. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
17. Navigation: Main navigation
Observed interface: the task presents Main navigation. Specific defect: menu heading remains in source language after locale change. This is not a harmless stylistic variation. Landmark navigation loses an understandable name. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Localize the landmark label and distinguish it from other navigation regions. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Main navigation is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Inspect landmarks list and keyboard traversal. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
18. Navigation: Breadcrumb Home
Observed interface: the task presents Breadcrumb Home. Specific defect: translated link visibly says Start but name remains Dashboard. This is not a harmless stylistic variation. Voice input users may be unable to activate by what they see. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Ensure rendered text is included in the computed link name. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Breadcrumb Home is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Compare visible wording and accessible links list. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
19. Navigation: Pagination Next
Observed interface: the task presents Pagination Next. Specific defect: accessible name says Previous after an RTL layout change. This is not a harmless stylistic variation. Moving between result pages becomes unpredictable. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Use logical direction and destination semantics, not solely arrow appearance. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Pagination Next is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Check page increment and link label with keyboard. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
20. Navigation: Tab Account
Observed interface: the task presents Tab Account. Specific defect: translated tab name points to a different panel ID. This is not a harmless stylistic variation. The visually selected tab opens unrelated content. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Keep stable IDs, aria-controls and selected state in sync across locales. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Tab Account is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Switch tabs and verify active panel association. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
21. Navigation: Skip to content
Observed interface: the task presents Skip to content. Specific defect: localized link targets an element deleted by a template variant. This is not a harmless stylistic variation. Keyboard users cannot bypass repeated navigation. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Retain the target and a meaningful local name. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Skip to content is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Focus first keyboard control and activate the skip link. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
22. Navigation: Language menu
Observed interface: the task presents Language menu. Specific defect: language switcher announces codes rather than understandable names. This is not a harmless stylistic variation. A person cannot choose a language confidently. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Use recognizable language names in the menu with accessible selection state. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Language menu is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Navigate options and verify language after switch. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
23. Navigation: Search results heading
Observed interface: the task presents Search results heading. Specific defect: new results appear but keyboard focus returns to the top unexpectedly. This is not a harmless stylistic variation. A user loses their place in a large list. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Preserve focus where feasible and provide truthful change feedback. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Search results heading is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Apply a filter, then resume keyboard traversal. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
24. Navigation: More settings
Observed interface: the task presents More settings. Specific defect: expandable region has a translated heading but no expanded state. This is not a harmless stylistic variation. A user cannot tell whether additional content is open. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Keep name and aria-expanded aligned to the real panel state. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for More settings is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Toggle twice and inspect announcements. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
25. Status: Item added to basket
Observed interface: the task presents Item added to basket. Specific defect: visual toast is translated but never appears in a status region. This is not a harmless stylistic variation. A screen reader user may repeat the add action. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Expose a concise status tied to actual basket change. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Item added to basket is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Add item once and check basket count and status announcement. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
26. Status: Saving changes
Observed interface: the task presents Saving changes. Specific defect: status announces Saved before the server responds. This is not a harmless stylistic variation. The user may leave while an update is still pending. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Distinguish Saving, Saved and Failed, based on real transitions. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Saving changes is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Simulate latency and a server failure. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
27. Status: Search completed
Observed interface: the task presents Search completed. Specific defect: live message always says One result regardless of count. This is not a harmless stylistic variation. The response falsifies the current result set. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Use grammatically correct messages driven by count data. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Search completed is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test zero, one and many results and inspect spoken output. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
28. Status: Uploading 45 percent
Observed interface: the task presents Uploading 45 percent. Specific defect: a progress indicator has no accessible value update. This is not a harmless stylistic variation. A user cannot learn whether a transfer is progressing. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Expose the actual progress value and avoid excessive announcements. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Uploading 45 percent is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Run a throttled upload and inspect progress state. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
29. Status: No results
Observed interface: the task presents No results. Specific defect: empty message says Network unavailable instead of zero matches. This is not a harmless stylistic variation. Users chase an imagined connection problem. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Differentiate an empty successful query from a request failure. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for No results is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Compare offline error and valid empty search. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
30. Status: Invitation sent
Observed interface: the task presents Invitation sent. Specific defect: translation says accepted though the recipient has not responded. This is not a harmless stylistic variation. A pending task is represented as completed. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Use Sent or Pending according to evidence and reserve Accepted for confirmation. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Invitation sent is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Review audit record and recipient status. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
31. Status: Session expired
Observed interface: the task presents Session expired. Specific defect: translated warning lacks any action to return or reauthenticate. This is not a harmless stylistic variation. The person cannot recover from timeout. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Provide a clear state explanation and actionable next step. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Session expired is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Let session expire and complete recovery with keyboard. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
32. Status: Offline editing
Observed interface: the task presents Offline editing. Specific defect: banner says Synced while changes remain on device. This is not a harmless stylistic variation. The user may assume data exists remotely. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Separate local save from remote synchronization. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Offline editing is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Disconnect network, edit, reconnect and inspect timestamps. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
33. Commerce: Price per month
Observed interface: the task presents Price per month. Specific defect: translation omits the billing period while the amount stays visible. This is not a harmless stylistic variation. The purchaser mistakes recurring payment for one-time price. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Keep unit, recurrence and total scope attached to price. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Price per month is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Inspect invoice preview and renewal information. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
34. Commerce: Apply discount
Observed interface: the task presents Apply discount. Specific defect: control is called Redeem purchase in assistive output. This is not a harmless stylistic variation. The user may think the order has been finalized. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Preserve action difference between applying a code and placing an order. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Apply discount is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Activate with keyboard and inspect order status. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
35. Commerce: Remove item
Observed interface: the task presents Remove item. Specific defect: translation says Delete account on a row action. This is not a harmless stylistic variation. A routine basket change appears dangerous. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Tie the name to the line item and basket removal outcome. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Remove item is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Remove one item and check others remain. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
36. Commerce: Delivery options
Observed interface: the task presents Delivery options. Specific defect: radio group labels are translated but the group question is not announced. This is not a harmless stylistic variation. A user hears costs without knowing what the options mean. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Localize a fieldset legend naming the delivery decision. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Delivery options is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Navigate radio choices and listen for group context. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
37. Commerce: Payment failed
Observed interface: the task presents Payment failed. Specific defect: error banner announces Success when authorization was rejected. This is not a harmless stylistic variation. The user may assume money was taken or order completed. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Use the transaction’s actual state and include safe correction steps. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Payment failed is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test declined authorization and inspect receipt generation. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
38. Commerce: Tax estimated
Observed interface: the task presents Tax estimated. Specific defect: translation presents estimate as final tax. This is not a harmless stylistic variation. A buyer misunderstands the cost before checkout. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Retain the estimate qualifier and stage of calculation. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Tax estimated is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Compare checkout estimate to confirmed invoice. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
39. Commerce: Refund requested
Observed interface: the task presents Refund requested. Specific defect: translated history says Refunded immediately after submitting a request. This is not a harmless stylistic variation. A customer may stop following up on an unresolved reimbursement. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Distinguish request receipt, approval and completed payment. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Refund requested is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Inspect transaction ledger stages. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
40. Commerce: Order canceled
Observed interface: the task presents Order canceled. Specific defect: a hidden status says Shipped because translation reused a key. This is not a harmless stylistic variation. The user hears a state opposite the actual order outcome. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Use state-specific strings tied to authoritative order status. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Order canceled is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Cancel test order and inspect order state and live message. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
41. Account: Change password
Observed interface: the task presents Change password. Specific defect: button is localized as Reset profile. This is not a harmless stylistic variation. The user cannot predict which credentials will change. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Write a verb-object name reflecting the credential action. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Change password is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Complete test update and sign in with new secret. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
42. Account: Sign out everywhere
Observed interface: the task presents Sign out everywhere. Specific defect: visible sign-out label omits all devices while programmatic name includes them. This is not a harmless stylistic variation. A user may trigger a broader termination than expected. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Expose scope consistently in visible confirmation and accessible copy. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Sign out everywhere is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Verify local and other sessions after action. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
43. Account: Deactivate account
Observed interface: the task presents Deactivate account. Specific defect: translation implies permanent deletion though action is reversible. This is not a harmless stylistic variation. The user may fear unnecessary irreversible loss. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Explain deactivation and available reactivation truthfully. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Deactivate account is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Deactivate and test restoration route. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
44. Account: Delete account
Observed interface: the task presents Delete account. Specific defect: confirmation dialog says Hide profile although records will be removed. This is not a harmless stylistic variation. An irreversible operation appears harmless. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Require unambiguous destructive wording and explicit scope. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Delete account is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Audit deletion outcome in a controlled test account. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
45. Account: Change recovery email
Observed interface: the task presents Change recovery email. Specific defect: form instruction leaves out verification requirement. This is not a harmless stylistic variation. A user may assume change is active immediately. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Say which address is pending and when verification takes effect. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Change recovery email is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Submit change and inspect verified state. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
46. Account: Two-step verification
Observed interface: the task presents Two-step verification. Specific defect: translated setting reverses enabled and disabled meanings. This is not a harmless stylistic variation. A person can unknowingly weaken account security. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Bind the label and state to actual security flag and test both positions. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Two-step verification is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Enable, disable and inspect effective verification requirement. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
47. Account: Download my data
Observed interface: the task presents Download my data. Specific defect: translated download scope says all records but export excludes archived material. This is not a harmless stylistic variation. A privacy statement becomes incorrect. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Define scope in the source data and localize any exclusions. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Download my data is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Inspect export manifest against promise. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
48. Account: Close session
Observed interface: the task presents Close session. Specific defect: shared Close text looks like account closure in a confirmation modal. This is not a harmless stylistic variation. Users may abandon a harmless action or misunderstand a risky one. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Name the session specifically and state whether it can be restored. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Close session is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Close current session and test active account. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
49. Health: Medication reminder
Observed interface: the task presents Medication reminder. Specific defect: translation turns Do not take into Take now. This is not a harmless stylistic variation. An imperative reversal can cause harm. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Use specialist review for negation and action timing, and retain warnings exactly. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Medication reminder is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test the visual, spoken and scheduled message under realistic states. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
50. Health: Appointment request
Observed interface: the task presents Appointment request. Specific defect: confirmation says Booked before the request is approved. This is not a harmless stylistic variation. A person may fail to obtain actual care. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Separate Submitted request from Confirmed booking and show next step. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Appointment request is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Inspect booking state and notifications. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
51. Health: Allergy field
Observed interface: the task presents Allergy field. Specific defect: instruction says list ingredients instead of substances causing a reaction. This is not a harmless stylistic variation. The clinical intent of entered data can shift. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Explain question purpose and permitted free-text input. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Allergy field is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Have qualified reviewers check sample entries and labels. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
52. Health: Test result pending
Observed interface: the task presents Test result pending. Specific defect: translation says Normal when a result has not arrived. This is not a harmless stylistic variation. The interface fabricates an interpretation. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Expose pending state without inferring medical findings. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Test result pending is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Use synthetic unresolved result and test all output channels. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
53. Health: Emergency contact
Observed interface: the task presents Emergency contact. Specific defect: accessible name says Primary clinician despite asking for personal contact. This is not a harmless stylistic variation. The wrong person may be recorded. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Clarify whom the user should nominate and why. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Emergency contact is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Inspect saved field and confirmation. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
54. Health: Symptom severity
Observed interface: the task presents Symptom severity. Specific defect: radio options reorder mild and severe after a locale change. This is not a harmless stylistic variation. A person may submit opposite severity. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Use explicit labels with stable numeric mapping and localized group context. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Symptom severity is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Choose each option and inspect stored score. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
55. Health: Accessibility request
Observed interface: the task presents Accessibility request. Specific defect: consent form labels accommodations as medical diagnosis. This is not a harmless stylistic variation. People may disclose unnecessary sensitive information. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Separate requested support from diagnostic disclosure. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Accessibility request is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Complete form with minimal data and review submission. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
56. Health: Stop treatment instruction
Observed interface: the task presents Stop treatment instruction. Specific defect: a help tooltip drops only from a critical qualifier. This is not a harmless stylistic variation. The instruction can become falsely absolute. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Require context review and exact scope preservation. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Stop treatment instruction is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Read complete flow with specialist and compare conditions. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
57. Learning: Submit assignment
Observed interface: the task presents Submit assignment. Specific defect: visible action says Save draft while actual action sends final work. This is not a harmless stylistic variation. A learner may submit unfinished work. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Preserve distinction between temporary saving and irreversible submission. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Submit assignment is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Inspect assignment state and editing permissions. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
58. Learning: Mark correct answer
Observed interface: the task presents Mark correct answer. Specific defect: feedback says Incorrect for a correct response in translated audio. This is not a harmless stylistic variation. Learning feedback becomes misleading. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Tie status strings to scoring logic and retain explanation. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Mark correct answer is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Try known correct and incorrect examples. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
59. Learning: Quiz time remaining
Observed interface: the task presents Quiz time remaining. Specific defect: timer text changes locale but its accessible value is not updated. This is not a harmless stylistic variation. A learner with screen reader misses a deadline. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Expose current time value without incessant interruption. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Quiz time remaining is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Simulate countdown and listen at controlled intervals. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
60. Learning: Lesson progress
Observed interface: the task presents Lesson progress. Specific defect: translated labels reverse completed and not started. This is not a harmless stylistic variation. Learners cannot plan their next activity. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Map status terms to actual progress values. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Lesson progress is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Resume interrupted lesson and inspect progress. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
61. Learning: Review this word
Observed interface: the task presents Review this word. Specific defect: dictionary entry lacks pronunciation-language metadata. This is not a harmless stylistic variation. Voice output may pronounce examples with wrong rules. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Identify language of substantive passages and test speech rendering. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Review this word is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Navigate headword, translation and examples. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
62. Learning: Next question
Observed interface: the task presents Next question. Specific defect: control label does not state whether answer will be submitted. This is not a harmless stylistic variation. A learner may lose an unfinished response. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Specify action effects and any auto-save behavior. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Next question is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Advance with incomplete answer and verify recovery. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
63. Learning: Course certificate
Observed interface: the task presents Course certificate. Specific defect: button claims Download certificate before requirements are complete. This is not a harmless stylistic variation. The interface makes an unearned promise. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Tie availability and wording to verified eligibility. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Course certificate is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test incomplete and complete learner states. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
64. Learning: Correct your work
Observed interface: the task presents Correct your work. Specific defect: error hint uses advanced terminology that source instructions explain in simpler terms. This is not a harmless stylistic variation. The target text creates an extra comprehension barrier. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Preserve intended reading level and show a concrete correction example. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Correct your work is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Conduct plain-language comprehension review. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
65. Media: Play audio
Observed interface: the task presents Play audio. Specific defect: translated icon button says Mute. This is not a harmless stylistic variation. A person activates the opposite audio function. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Separate play, pause, mute and unmute states. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Play audio is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Toggle audio and inspect name, pressed state and playback. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
66. Media: Captions enabled
Observed interface: the task presents Captions enabled. Specific defect: switch says Off while captions render visibly. This is not a harmless stylistic variation. A screen reader user cannot trust the state. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Keep visible and programmatic states sourced from actual caption setting. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Captions enabled is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Toggle and observe caption display. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
67. Media: Audio description
Observed interface: the task presents Audio description. Specific defect: setting is translated as captions although it adds spoken visual information. This is not a harmless stylistic variation. People choose the wrong accessibility feature. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Explain the difference between narration and text captions. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Audio description is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Enable each feature and check output. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
68. Media: Transcript download
Observed interface: the task presents Transcript download. Specific defect: link name does not identify the recording it belongs to. This is not a harmless stylistic variation. Multiple downloads are indistinguishable. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Include recording title or episode context in accessible link text. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Transcript download is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Inspect link list and downloaded document. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
69. Media: Playback speed
Observed interface: the task presents Playback speed. Specific defect: options translate as minutes rather than rate multipliers. This is not a harmless stylistic variation. A viewer misunderstands faster versus slower playback. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Protect numeric multipliers and label speed choices clearly. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Playback speed is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Select each speed and measure behavior. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
70. Media: Skip introduction
Observed interface: the task presents Skip introduction. Specific defect: control secretly jumps past a safety notice as well. This is not a harmless stylistic variation. The label understates skipped material. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Verify actual segment boundaries and accurate action scope. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Skip introduction is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Skip then inspect playback position and missed content. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
71. Media: Volume slider
Observed interface: the task presents Volume slider. Specific defect: localized value says 50 degrees instead of 50 percent. This is not a harmless stylistic variation. A screen reader user hears an unrelated unit. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Keep physical units and percentage metadata separate. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Volume slider is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Move slider in steps and inspect value text. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
72. Media: Live stream ended
Observed interface: the task presents Live stream ended. Specific defect: message says Paused though the broadcast cannot resume. This is not a harmless stylistic variation. A user repeatedly attempts an impossible action. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Distinguish ended session from temporary pause. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Live stream ended is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test ended stream and check available next routes. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
73. Security: Security key required
Observed interface: the task presents Security key required. Specific defect: localized message implies password alone is sufficient. This is not a harmless stylistic variation. A user is denied access without understanding a second factor. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Explain required factor and available alternatives without weakening security. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Security key required is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test a user missing the security key. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
74. Security: Report abuse
Observed interface: the task presents Report abuse. Specific defect: control translates as Block user, which is a separate consequence. This is not a harmless stylistic variation. A person may believe reporting immediately prevents contact. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Use discrete keys and explain each operation. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Report abuse is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Submit report and check blocking state independently. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
75. Security: Revoke access
Observed interface: the task presents Revoke access. Specific defect: dialog describes temporary pause but token will be invalidated. This is not a harmless stylistic variation. A collaborator may lose access unexpectedly. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. State scope, permanence and reauthorization path. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Revoke access is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Revoke a test token and attempt later use. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
76. Security: Sensitive data hidden
Observed interface: the task presents Sensitive data hidden. Specific defect: screen reader output still contains the unmasked identifier. This is not a harmless stylistic variation. Private data is disclosed through an alternate channel. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Apply masking at the source and all accessibility text outputs. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Sensitive data hidden is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Inspect accessibility tree while data is hidden. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
77. Security: Show password
Observed interface: the task presents Show password. Specific defect: button state label fails to toggle to Hide password. This is not a harmless stylistic variation. A user cannot tell whether secret text is exposed. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Tie accessible name to real visibility state. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Show password is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Toggle and inspect input type and announcement. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
78. Security: Authentication failed
Observed interface: the task presents Authentication failed. Specific defect: message says Wrong password for every possible failure. This is not a harmless stylistic variation. The system may reveal or obscure the wrong reason and prevent recovery. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Write truthful but security-reviewed generic failure states. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Authentication failed is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test invalid password and locked account separately. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
79. Security: Permission denied
Observed interface: the task presents Permission denied. Specific defect: translated notice says File missing instead of access restricted. This is not a harmless stylistic variation. A person looks for a nonexistent resource. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Preserve authorization distinction without revealing protected details. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Permission denied is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test allowed and denied roles with same resource. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
80. Security: Session warning
Observed interface: the task presents Session warning. Specific defect: countdown is translated but extension control is not keyboard reachable. This is not a harmless stylistic variation. A person may be logged out without a way to act. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Restore keyboard operability and explain time left. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Session warning is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Run full timeout and extend through keyboard. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
81. Communication: Send message
Observed interface: the task presents Send message. Specific defect: action becomes Publish publicly in localized copy while recipient is private. This is not a harmless stylistic variation. A sender may disclose content to the wrong audience. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Keep audience and channel explicit in confirmation. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Send message is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Send test message and inspect recipients. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
82. Communication: Message delivered
Observed interface: the task presents Message delivered. Specific defect: status becomes Read although delivery is not evidence of reading. This is not a harmless stylistic variation. A sender draws the wrong conclusion about attention. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Maintain distinct delivered and read states. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Message delivered is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Compare event log against both badges. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
83. Communication: Reply all
Observed interface: the task presents Reply all. Specific defect: translated option collapses all recipients into sender only. This is not a harmless stylistic variation. A user may exclude colleagues from important conversation. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Expose recipient scope and preview addresses. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Reply all is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Reply with keyboard and inspect outgoing headers. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
84. Communication: Notification dismissed
Observed interface: the task presents Notification dismissed. Specific defect: dismiss appears as Unsubscribe. This is not a harmless stylistic variation. The user may fear losing future alerts. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Separate one-time dismissal from preference changes. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Notification dismissed is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Dismiss notice and verify subscription unchanged. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
85. Communication: Mute thread
Observed interface: the task presents Mute thread. Specific defect: action translates as Delete thread. This is not a harmless stylistic variation. A reversible notification setting looks destructive. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Explain that messages remain accessible. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Mute thread is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Mute and inspect retained conversation. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
86. Communication: Attachment failed
Observed interface: the task presents Attachment failed. Specific defect: banner says File too large although error is connection loss. This is not a harmless stylistic variation. A sender may unnecessarily alter the document. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Translate from the correct error code and offer reconnect route. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Attachment failed is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Reproduce each failure independently. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
87. Communication: Video call join
Observed interface: the task presents Video call join. Specific defect: visible button says Preview camera but immediately joins a call. This is not a harmless stylistic variation. A user may disclose image or sound unexpectedly. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Separate preview from joining and expose permission changes. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Video call join is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test from denied and granted device permissions. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
88. Communication: Block contact
Observed interface: the task presents Block contact. Specific defect: programmatic name says Report contact. This is not a harmless stylistic variation. A person might assume moderation review when only local blocking occurred. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Name local action and explain its extent. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Block contact is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Block in test account and inspect report history. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
89. Data: Sort ascending
Observed interface: the task presents Sort ascending. Specific defect: screen reader announces descending when order changed. This is not a harmless stylistic variation. A user reads rankings backward. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Bind order name and state to real sort direction. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Sort ascending is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Sort numeric and alphabetical examples. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
90. Data: Filter applied
Observed interface: the task presents Filter applied. Specific defect: status says Three filters when only one is active. This is not a harmless stylistic variation. A user cannot explain missing records. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Count applied filters from active model. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Filter applied is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Toggle filters and inspect result and announcement. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
91. Data: Export CSV
Observed interface: the task presents Export CSV. Specific defect: translated action says Print PDF. This is not a harmless stylistic variation. The user may send the wrong file to a collaborator. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Keep exact export format, encoding and availability in copy. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Export CSV is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Check filename, MIME type and exported contents. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
92. Data: Empty chart
Observed interface: the task presents Empty chart. Specific defect: alt text announces increasing sales despite no data. This is not a harmless stylistic variation. The chart invents a trend. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Explain no available data rather than hypothetical movement. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Empty chart is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test empty and populated chart states. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
93. Data: Table header
Observed interface: the task presents Table header. Specific defect: localized header implies rate instead of total count. This is not a harmless stylistic variation. A reader may compare incompatible quantities. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Preserve metric definition in header and description. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Table header is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Read cells with header relationships and verify units. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
94. Data: Footnote marker
Observed interface: the task presents Footnote marker. Specific defect: reference number is visible but its meaning is not linked. This is not a harmless stylistic variation. An important qualifier may be lost to non-visual readers. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Expose reference and note relationship without overloading each cell. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Footnote marker is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Navigate from data to note and back. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
95. Data: Live dashboard refreshed
Observed interface: the task presents Live dashboard refreshed. Specific defect: banner says Updated while remote fetch failed. This is not a harmless stylistic variation. A user relies on stale data as current. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Show last confirmed refresh time and failure distinction. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Live dashboard refreshed is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Simulate failure and inspect timestamp. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
96. Data: Select all rows
Observed interface: the task presents Select all rows. Specific defect: name omits that only the current page is selected. This is not a harmless stylistic variation. A user can act on an unexpectedly limited set. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. State whether selection means page, filtered results or whole dataset. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Select all rows is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Select then inspect count and batch action. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
97. Travel: Departure delayed
Observed interface: the task presents Departure delayed. Specific defect: status translation says Canceled instead of delayed. This is not a harmless stylistic variation. A passenger may abandon a still-operating service. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Preserve event type and current source timestamp. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Departure delayed is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Check synthetic delay and cancellation states. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
98. Travel: Gate changed
Observed interface: the task presents Gate changed. Specific defect: alert names the previous gate in speech output. This is not a harmless stylistic variation. A traveller may move to the wrong place. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Bind both visible and spoken gate to latest confirmed data. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Gate changed is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Change gate in test feed and compare all channels. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
99. Travel: Accessibility assistance
Observed interface: the task presents Accessibility assistance. Specific defect: option translated as priority boarding only. This is not a harmless stylistic variation. A traveller may not request needed support. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Describe actual assistance offered and request pathway. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Accessibility assistance is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Submit support request and inspect staff-facing record. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
100. Travel: Estimated arrival
Observed interface: the task presents Estimated arrival. Specific defect: translation omits Estimated and presents an exact promise. This is not a harmless stylistic variation. The user may plan around unsupported certainty. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Retain prediction qualifier and timestamp. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Estimated arrival is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Simulate fluctuating arrival data. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
101. Travel: Change booking
Observed interface: the task presents Change booking. Specific defect: button name says Cancel booking while workflow edits a date. This is not a harmless stylistic variation. A person fears losing the reservation. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Make the changed field and eventual confirmation explicit. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Change booking is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test date modification without cancellation. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
102. Travel: Seat selected
Observed interface: the task presents Seat selected. Specific defect: screen reader says available although the seat is occupied. This is not a harmless stylistic variation. A user may attempt an impossible selection. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Expose selected, unavailable and available states from current seat model. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Seat selected is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Navigate grid and confirm booking validation. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
103. Travel: Route unavailable
Observed interface: the task presents Route unavailable. Specific defect: message says No connection rather than no route for constraints. This is not a harmless stylistic variation. A user misdiagnoses the failure. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Distinguish search exclusions, disconnected device and unavailable service. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Route unavailable is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test each separately. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
104. Travel: Boarding complete
Observed interface: the task presents Boarding complete. Specific defect: status says Boarding started even after door closure. This is not a harmless stylistic variation. The user may be directed into an unavailable step. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Tie visible and accessible state to operational event. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Boarding complete is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Replay state transitions and ensure timing. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
105. Authoring: Publish now
Observed interface: the task presents Publish now. Specific defect: translated button says Save privately. This is not a harmless stylistic variation. A writer may expose unpublished material. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. State publishing audience and public consequence. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Publish now is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Use sandbox draft and inspect post visibility. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
106. Authoring: Save draft
Observed interface: the task presents Save draft. Specific defect: live region says Published after autosave. This is not a harmless stylistic variation. A writer misreads the content lifecycle. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Report draft persistence without publication claim. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Save draft is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Save draft and check external public URL absent. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
107. Authoring: Restore revision
Observed interface: the task presents Restore revision. Specific defect: translation implies restoring the whole site instead of one document. This is not a harmless stylistic variation. The action appears broader than its real scope. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Name exact document and revision. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — language and context: For language analysis, inspect the rendered document language and any language changes on substantive passages. Then verify the vocabulary in the specific task. Do not treat script direction, font family or keyboard layout as a reliable substitute for language identification. In this case, investigate how the string for Restore revision is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Restore a test document and inspect other content unchanged. Because assistive technologies differ, test the intended supported configurations and write down observed behavior. A pronunciation artifact is not automatically a markup failure, and correct markup is not proof that every synthesizer will pronounce every proper name identically. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
108. Authoring: Comment resolved
Observed interface: the task presents Comment resolved. Specific defect: label says Deleted, suggesting discussion was erased. This is not a harmless stylistic variation. Collaborators may avoid using resolution workflow. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Describe resolved status and retrievability. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — scope and consequence: For consequence analysis, specify which object changes, which people can see the result, whether the action can be undone and which later events must occur before it is final. Localize the whole scope of the promise, not the most attractive verb. In this case, investigate how the string for Comment resolved is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Resolve then reopen discussion. During retest, compare the before-and-after object state with what the translated interface predicted. If the copy says an action is reversible, attempt the documented recovery. If it says final, verify that the workflow and audit trail justify that assertion. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
109. Authoring: Change language
Observed interface: the task presents Change language. Specific defect: editor label suggests machine translation when it only switches editing locale. This is not a harmless stylistic variation. A writer expects a translated draft to appear. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Distinguish interface language from content translation. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — name and role: For naming analysis, inspect the computed name before looking at the translation catalog. Browser tools show how a name is derived, but the final check also needs a human hearing or reading the control in a realistic task. If a visible label and a hidden name conflict, identify the precedence path instead of adding another synonym. In this case, investigate how the string for Change language is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Switch UI and inspect document body unchanged. The best diagnostic record contains the original source message, the current translated label, any programmatic override, the component role and a screenshot or concise interaction trace. It makes the mismatch reproducible and prevents a later translator from fixing the wrong field. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
110. Authoring: Review suggestions
Observed interface: the task presents Review suggestions. Specific defect: button name refers to accepted changes before user approval. This is not a harmless stylistic variation. A reviewer could miss outstanding suggestions. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Describe pending status accurately. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — state and feedback: For state analysis, distinguish a command from the outcome it claims. A message such as Pending, Completed or Failed belongs to an actual product state. It cannot be made correct simply by choosing fluent grammar. Test every transition, including aborted, canceled and network-failure paths. In this case, investigate how the string for Review suggestions is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Inspect proposed, approved and rejected states. The reviewer should retain an event timestamp, the state from the authoritative model, the visible update and the assistive-technology announcement. If these disagree, the defect may belong to application logic rather than translation, and both teams need the same evidence. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
111. Authoring: Archive page
Observed interface: the task presents Archive page. Specific defect: localized warning promises permanent deletion although page is reversible. This is not a harmless stylistic variation. A writer may misunderstand retention. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Explain archive and restore path. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — error and recovery: For recovery analysis, reproduce the failed input instead of reading a disconnected string. The error must tell the person what happened, where it happened and what they can do. Ensure the localized text is discoverable through the control’s description, an error summary or an appropriate status pathway. In this case, investigate how the string for Archive page is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Archive then locate recovery mechanism. The test is successful only when the user can correct the problem without guessing the original-language requirement. Capture the rejected input class and the accepted repaired input in a safe test environment, never an actual user’s confidential records. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
112. Authoring: Share privately
Observed interface: the task presents Share privately. Specific defect: dialog says Anyone with link even when restricted to named users. This is not a harmless stylistic variation. A writer could disclose confidential content through mistaken assumptions. A person who sees the interface and a person who hears its accessible representation may form different expectations about the same task.
What meaning must survive: preserve the concrete user action and the conditions attached to it. Bind permission copy to actual sharing model. Before selecting target-language wording, the reviewer should ask which object is affected, which state follows, what consent or permission is implied, and whether the action is reversible. These details resolve ambiguity more reliably than dictionary equivalence. In the localization brief, provide the component identity, neighboring headings, before-and-after screens and any legal or safety qualifier. The translator can then write a phrase that is concise without losing the difference between appearance, intention and completed outcome.
Mechanism and diagnosis — navigation and focus: For navigation analysis, start before entering the component and continue after leaving it. Tab order, heading structure, focus visibility, expanded or selected state and destination content together determine whether the translated label is useful. In this case, investigate how the string for Share privately is inserted, whether an alternate channel contains the defective phrasing, and whether the interaction is controlled by the same application state as the visible text. A language review should not assume that every problem originates in the language file: it may arise from a stale accessibility property, shared key, incorrectly associated label, component lifecycle or a premature status event. Determine which layer actually generates the misleading information before patching it.
Repeatable correction: start with a minimal reproducer in a safe test account. Record the current translated text, the associated role and state, and the sequence that leads to the mismatch. Replace the ambiguous text with an action-specific message, implement the corresponding semantic relationship where necessary, then re-run the original sequence. Check that the correction remains true when data changes, when a user cancels, and when an error occurs. Do not compensate for a wrong system state by making the wording vague; change the underlying behavior or the predicate that chooses the message.
Evidence and release check: Test link with authorized and unauthorized accounts. Record what an assistive-technology user would encounter when navigating by headings, landmarks, buttons or links. A translation can preserve the visible sentence yet destroy the ability to find its corresponding object among many similar controls. The acceptance criterion should be understandable to someone who has never seen the source-language UI: the user can identify the intended action, perform it with the supported input method, observe the real outcome, and recover when appropriate. If any of these checks fails, document the exact failure rather than marking the translation complete simply because the localized string is present.
Transfer lesson: a similar fault can appear when the same design pattern is reused on a different screen or in another locale. Create a regression case keyed to the semantic requirement—purpose, scope, state or recovery—not merely the exact English words. When the source design changes, use that requirement to decide whether the localized name, explanation, role association or announcement must change as well.
Practice workshop: a complete multilingual release review
Begin with a screen containing three actions: Change settings, Save changes and Close. Create a task card for each. The first opens an editing state, the second persists a change, and the third dismisses the current panel without necessarily saving. Translate all three with the panel context and verify the rendered and computed names are distinct. If Close actually discards unsaved edits, the interface should offer an accurate warning or an appropriate save path; a translator must not invent saving behavior.
Move to a form. Mark required fields with explicit text and native semantics. Ensure each label names the expected information, examples do not replace labels, and help text describes the input format accurately. Deliberately submit an empty required field, an invalid value and a valid value. The first two should expose correctable errors through a discoverable channel. The valid submission should produce a confirmation only when the underlying process actually succeeds.
Now change the interface language while retaining entered content. Verify that the chosen language survives navigation, the page’s language declaration is correct, user-provided data is not silently rewritten, and translated control names remain aligned with what is visible. Repeat with a line of mixed-script user content and with a long target string. The goal is not identical screenshots but identical task meaning and an operable layout.
Introduce delayed responses, a failed save, an empty search result and a pending invitation. The review should distinguish waiting, failure, no matches and invitation accepted. If a status is announced, it must correspond to the actual event and use a priority suitable for the importance of the change. Avoid a stream of announcements that prevents users from hearing what they are trying to do.
Finish by running one journey without a mouse, one with a supported screen reader and one using the user’s visible labels as voice-command targets when available. Record every mismatch as an actionable defect: component, locale, source key, actual label or name, expected task outcome, observed outcome and owner. A QA result is only useful when the team can reproduce and repair it.
How to decide whether a translation defect blocks release
A release-blocking defect is one that changes a high-consequence action, conceals required information, defeats essential navigation, prevents error recovery or causes an untrue state to be announced. Examples include a reversed delete confirmation, a payment-success message after failure, a field with no usable label, or a translated language selector that unexpectedly discards work. Severity depends on the actual task, not on whether the visible mistake looks small.
A serious but sometimes workaround-possible defect might include ambiguous duplicate button names, truncated target text at supported zoom, a stale language attribute, or an inaccessible search-results update. Assess the user’s ability to finish the task independently, not just whether an auditor can find a hidden route. A workaround that requires knowledge of the original language is not a robust localization solution.
Lower-priority corrections can concern wording rhythm, punctuation or preferred synonym choice when neither purpose, scope, navigation, feedback nor recovery changes. Even these should be tracked if they repeatedly confuse users or damage consistency. Preserve evidence of the decision and revisit it when the component’s user journey changes.
Risk-based prioritization does not excuse neglecting WCAG requirements. It separates immediate operational harm from improvement sequencing. Record applicable success criteria and test results in addition to the product-specific impact. Never claim that one automated scan, one language or one assistive-technology setup certifies every locale and environment.
Reusable translator’s brief and QA checklist
For each item, collect these fields: stable message key; product feature; task purpose; source text; visual context; computed accessible name; role; description; language; source of dynamic values; singular and plural constraints; special formatting; action effect; reversibility; required user consent; success and error states; supported locales; content owner; accessibility owner; example screenshot; test account condition; source revision; translation revision; and final approval evidence.
Ask reviewers to answer six questions in natural language: Can I find it? Can I identify it? Can I operate it? Can I tell what happened? Can I correct a problem? Do the visible and programmatic channels agree? These questions are intentionally independent of the particular language. They describe the task outcome rather than a memorized set of strings.
Build a defect vocabulary: wrong action, wrong object, wrong scope, wrong state, missing accessible name, visible/programmatic mismatch, missing form relationship, language metadata, focus loss, undiscoverable feedback, broken layout at zoom, and unsupported assistive-technology behavior. Assign each issue to the real layer that owns the correction.
For every release, preserve representative positive and negative paths. Positive paths prove that an action works; negative paths prove that an error remains understandable and recoverable. Add tests whenever a production failure uncovers a new confusion. Do not assert that translations are “fully accessible” without defining the tested scope and acknowledging known limitations.
Questions readers commonly ask
Should every image have translated alt text? Meaningful images need text alternatives that serve their purpose in context. Decorative images should not be given redundant prose. An image of a chart may require an explanation of the actual information rather than a literal description of every visual decoration. The right translation depends on its use.
Do I translate aria-label? If an `aria-label` conveys human-language meaning, it needs appropriate localization. But first check whether the control should instead use its visible text or an associated label, and whether the ARIA attribute overrides a name that would otherwise be correct. Translate the purpose, not the attribute name.
Do I need to translate language names in the language switcher? Use names users can recognize and choose. The interface may use autonyms, translated names or a combined pattern according to audience and usability testing. The important result is unambiguous selection with the correct language applied afterward.
Is WCAG 2.2 a machine translation standard? No. WCAG 2.2 describes web accessibility success criteria. Translation methods, linguistic quality, terminology and user research are related disciplines. The localized interface must satisfy the intended task and relevant accessibility requirements together.
Will adding lang attributes solve pronunciation everywhere? No. Language metadata is important and can enable appropriate rendering, but W3C notes that accessible-name processing and differences among assistive technologies may affect speech behavior. Test supported combinations and do not infer compliance from pronunciation alone.
Can automated accessibility scanners replace native-language reviewers? No. Tools can detect missing attributes, many contrast issues and some structural errors. They generally cannot judge whether a translation reverses a command, misstates consent, chooses the wrong register or invents a medical finding.
Does longer translation always break accessibility? Not necessarily. Flexible layout, proper wrapping, reflow and clear label design can accommodate many expansions. The risk rises when strings are hard-clipped, controls have fixed widths or critical qualifiers disappear. Test at supported zoom and viewport sizes.
Should the accessible name repeat the button role? Generally not. Screen readers announce control roles, so a name such as “Save button” can be unnecessarily repetitive. WAI’s naming guidance recommends concise, distinctive names matched to purpose.
What happens when translation and source behavior disagree? Do not smooth over the mismatch. Record what the interface actually does, ask the product owner to establish the intended behavior, and repair the appropriate source, UI logic or localization. Publishing a knowingly false message because it is grammatically elegant is not an acceptable solution.
How much accessibility testing is enough? Scope depends on task criticality, supported platforms and available resources. At minimum, check the actual rendered structure, complete keyboard journeys and representative assistive technology use, including failures and recoveries. Record exact coverage rather than implying universal proof.
Further reading and authoritative technical references
Primary references should be read as the original sources of requirements and guidance. The examples in this article are explanatory applications, not quotations of normative language. Relevant W3C resources include the WCAG 2.2 Recommendation, explanatory Understanding pages, accessible-name guidance and accessible form tutorials. Standards and implementation guidance may evolve, so verify the current version and the actual technology stack before an audit.
- W3C WCAG 2.2 Recommendation
- W3C Understanding Language of Page
- W3C Understanding Language of Parts
- W3C Understanding Label in Name
- W3C WAI Accessible Names and Descriptions
- W3C WAI Forms Tutorial
- W3C WAI Form Instructions
- W3C WAI Form Validation
- W3C WAI Internationalization Language on the Web
- W3C Understanding Status Messages
Transfer: from one accessible translation to a reliable multilingual product
The method transfers to applications, educational platforms, public information portals, commerce, account management, media controls and document editing because each has users acting on information. Begin with the task, name the action, verify its scope, identify the machine-exposed structure, then test real use. A language-by-language checklist built only around translated strings misses the fragile moments between reading, acting and recovering.
Localization becomes easier to maintain when semantic requirements are stored beside product components. Instead of asking reviewers to remember that a particular English label was once problematic, document that a destructive action must state its object and consequence; a status must be grounded in the actual backend event; and a form error must connect to the field it concerns. Those statements survive translation and product redesign.
When teams add machine translation or AI assistance, preserve the same accountability. Models can suggest concise labels and detect some inconsistent strings, but they should not be allowed to invent workflow states, alter permissions or silently assume what a backend event means. Human review and technical tests remain essential for consequences that matter.
The best measure is not the count of translated messages. It is whether a person using the supported locale and access method can accomplish the task with the same essential information, degree of choice and opportunity to recover. Translation is successful when meaningful interaction remains possible, not merely when every word has been substituted.
Next routes in the Master Art of Translation
Return to the Master Art of Translation | The Complete System for Moving Meaning Between Languages for the full architecture and related branches. The current chapter is the reserved-tens child EDKSG-TRANS-MASTER-WORLD-1200, following the Multilingual Regression Testing System. This article specializes in the user-facing and assistive-technology semantics that regression cases must protect.
For systematic word knowledge and concept distinctions, visit the protected Vocabulary Learning Hub. It is relevant when an interface team must explain why two familiar-looking terms are not synonyms in a workflow. This page does not replace that hub’s vocabulary instruction.
For the role of syntax, meaning and text organization in English, visit the protected How English Works | Translation and Meaning Across Languages. It helps readers analyze the structure of instructions and messages, while this chapter remains responsible for multilingual accessibility behavior and localization verification.
To continue independently, choose one real interface journey, write its semantic inventory, reproduce one error and one success path, and compare the visible experience with the computed accessibility information. Fix that smallest complete journey before multiplying the language count. The habit scales from a single translated button to a multilingual product release.