Master Art of Translation | The Digital Identity, Verifiable Credentials & Trust Frameworks Translation System — How Claims, Wallets, Proofs, Consent and Status Keep Their Meaning

Master Art of Translation · World system child 510 · Specialist longform guide

Digital identity translation is the disciplined localization of verifiable credentials, digital identity wallets, electronic attestations, identity-proofing notices and trust-framework records. A reliable translation preserves who made a claim, which person or organization the claim concerns, what the claim actually asserts, how it can be verified, and whether it is still valid. This guide explains how to translate digital identity information across languages without altering credential identifiers, structured data, cryptographic material, privacy permissions or the meaning of a verifier’s decision.

Readers looking for verifiable credentials translation, multilingual digital ID, digital wallet localization, identity verification terminology, credential issuer–holder–verifier language or trust framework translation often discover that ordinary document-translation practice is insufficient. Words on a screen may be translated, but machine-readable attributes, issuance protocols, validity dates, status checks, selective disclosure, security instructions, accessibility messages and audit records must continue to describe the same underlying transactions. Good localization therefore needs linguists, subject experts, product owners, engineers, privacy specialists and independent reviewers to work from one controlled meaning model.

The hidden problem is a dangerous appearance of equivalence: two screens can sound equally reassuring while representing different evidence. “Verified identity” can mean that a cryptographic signature was checked, that an account authenticated successfully, that a document was examined, or that an attribute was confirmed by a particular issuer. Those are not interchangeable. The repeatable method in this article starts with the claim and its evidence, not the prettiness of a translated label; then it tests whether the recipient can make the same authorized decision using the localized interface and the unchanged credential data.

This is a specialist branch of Master Art of Translation | The Complete System for Moving Meaning Between Languages. It does not replace the translation root, a general Vocabulary Learning Hub, or the protected How English Works explanation of language and communication. Those routes are connected only where their own subject boundaries matter.

At a glance: the decision this guide helps you make

Use this manual if a digital identity project must display claims in several languages, translate digital-wallet onboarding, document provenance, preserve data models during localization, adapt consent or disclosure language, investigate a mismatch between screen text and structured fields, or release a multilingual verification workflow without weakening its evidence chain. It is written for translators and reviewers as well as identity architects, schema stewards, accessibility testers, customer-support writers, policy authors and people who approve the finished service.

A successful release does not mean that every source-language word has an attractive target-language equivalent. It means that the person taking an action can distinguish the actors, status, conditions, limits and consequences; the machine still reads the same authorized fields; and the system does not silently invent an identity claim, a jurisdictional entitlement, a security guarantee or a consent event. A credential must not become more trustworthy because the translation sounds stronger, and it must not become weaker merely because a local grammatical convention is unfamiliar.

• Search intent: what “translate a digital identity credential” actually involves, and what it does not.
• Hidden problem: separating display language from proofs, bindings, attestations, attributes and trust decisions.
• Mechanism: actor–claim–evidence–status–purpose mapping before any localized wording is approved.
• Method: a sixteen-gate production and quality-assurance route that can be rerun on changes.
• Failure analysis: plausible but unsafe wording, with corrections and release tests.
• Worked diagnostics: fictional, non-personal case files across identity, credentials, wallets, internationalization and governance.
• Transfer: multilingual exercises, workflow simulations, glossary checks and next learning routes.

1. Search intent and the boundary of the subject

An identity credential can be a physical document, an account-bound record or a digital assertion made by an issuer. A W3C verifiable credential is a particular model for expressing issuer claims that can be checked with appropriate securing mechanisms. A wallet may store or help manage such credentials. An identity provider, credential service provider, relying party, verifier and credential issuer may overlap in some implementations, but those roles should never be presumed identical in translation. In a real service, the first step is to draw the actor diagram used by that particular deployment.

The phrase “digital identity translation” covers at least four different jobs. First, translate human-readable text, such as labels, help screens and recovery instructions. Second, localize data representation, such as language-tagged names or formatted dates, without changing their canonical values. Third, translate supporting governance documentation, including verification requirements, support notices and human review procedures. Fourth, handle authentic translation or certification of a claim when a separate legal or institutional process requires it. A multilingual display string is not automatically a new certified credential, and changing a signed payload is not merely a harmless formatting edit.

The international standards landscape provides useful terminology, but standards must be applied in context. The W3C Verifiable Credentials Data Model v2.0 became a Recommendation on 15 May 2025. OpenID4VCI 1.0 became final on 16 September 2025 and concerns issuance; OpenID4VP 1.0 concerns presentation. They are not the same function. NIST SP 800-63-4, finalized in 2025, separates identity proofing, authentication and federation assurance. These sources anchor definitions, not an assumption that every deployment has an identical legal effect.

2. The hidden problem: translation can impersonate a trust decision

A verifier may receive a credential with a legitimate issuer identifier and technically valid proof yet still reject it because the issuer is not trusted for this purpose, the credential is no longer valid, the intended attribute is missing, or the holder is not entitled to use it in that transaction. Conversely, a localized interface can accidentally suggest that a person has failed an identity check when only an optional metadata lookup has failed. Both errors are language failures with real operational consequences. The translator must not transform a limited technical result into an absolute statement about someone’s identity, character or rights.

The most reliable unit of analysis is a decision record with six linked questions: who speaks, about whom, what property is asserted, on what evidence, for which transaction, and as of what time? The record also identifies what is deliberately not asserted. A “valid credential” is not necessarily an authorized transaction. A proof of possession is not the same as identity proofing. A verified signature is not proof that every claim is factually true. An expiry date, a suspension state and a revocation state do different jobs. Localization becomes safer when these distinctions are explicit before writers choose verbs or nouns.

Some translation defects are visible in sentences. Others are structural: an editor “translates” a JSON key, removes a Unicode combining mark from an identifier, substitutes a localized decimal or date into a signed field, changes a status URL, collapses a right-to-left identifier into reversed display order, or replaces an inaccessible button label with an ambiguous icon. In such cases the problem is not just linguistic accuracy. The system may fail to parse the credential, bind a statement to the wrong subject or communicate an action the user cannot safely perform.

3. The mechanism: actor, claim, evidence, status, audience

The issuer is the entity making the credential claim; the credential subject is what or whom the claim describes; the holder is the entity controlling a credential in the workflow; and a verifier checks a presentation according to its rules. These are conceptual roles rather than promises about a particular software architecture. The translator needs a role glossary approved by the product owner. A wallet’s “My credentials” tab may use familiar user language, but specialist documentation must still distinguish who held, signed, issued and checked the record.

A claim is not a mere sentence that can be freely paraphrased. It may be a machine-readable attribute with a defined property, data type, identifier, permitted value set, provenance, validity period and intended purpose. The human phrase attached to it must preserve that schema-defined meaning. For example, “licensed for activity X until date Y” is narrower than “qualified professional,” and “over an age threshold” is not an invitation to request or display the full date of birth. The presence of a field does not authorize the service to demand unnecessary data.

A trustworthy pipeline keeps three representations separate: the signed or otherwise protected source data; the controlled semantic model that defines the meaning; and the localized presentation that helps humans operate the service. Where a new language needs to appear inside a credential, the issuer and system owner must determine the supported credential format and issuance workflow rather than making a post-issuance text edit that invalidates a proof. Where a screen simply displays a translated term, the original identity and status fields remain untouched.

4. The repeatable sixteen-gate translation method

Gate 01 — Scope and search question

Record the reader’s purpose: translate a credential display, prepare multilingual wallet instructions, localize a verifier’s decision page, or produce a controlled translation for review. Label audience and expected action. Do not quote a translation price or claim legal equivalence until the exact service and document status are known. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 02 — Actor map

Draw issuer, subject, holder, wallet, verifier, credential service provider, identity provider and relying party as separate nodes. Combine roles only when the system design explicitly combines them. A phrase like “our verification” must be assigned to its actual responsible actor. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 03 — Claim and field inventory

Export field names, labels, data types, value ranges, canonical identifiers, enumerations, evidence links and security restrictions. Classify source-language text that can be translated separately from protected bytes that cannot be edited. Record empty, unknown and not-applicable as different conditions. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 04 — Provenance and trust scope

Identify the organization that asserts each fact and the evidence relied on. Translate “issuer” differently from “document presenter” if the context requires it. Add reviewer notes when a claim’s authority is uncertain; never substitute a familiar institution just because a name sounds similar. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 05 — Purpose and permission

Document why the recipient sees each attribute and whether a disclosure is required, optional, or outside the transaction. Differentiate user preference, user authorization, privacy notice and legal basis; these are not interchangeable merely because each appears near a checkbox. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 06 — Identity assurance separation

Keep proofing, authentication and federation distinct. If a workflow authenticates an account, do not announce that the person’s real-world identity was re-proven. If a verifier checks a signed credential, avoid claiming the entire account is secure. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 07 — Terminology governance

Build a concept-based multilingual termbase with definitions, forbidden synonyms, field ownership and review date. Mark sensitive pairs such as revoked/suspended, holder/subject, verified/eligible, authentication/authorization, expiry/issuance, issuer/verifier and translation/certification. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 08 — Data and cryptographic freeze

Define immutable fields: identifiers, signatures, hashes, status endpoints, security tokens, schemas, protocol names, software keys and signed payloads. Only approved canonicalization and re-issuance procedures may change protected data. Translators may propose wording, not silently mint new credentials. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 09 — Language and direction metadata

Tag natural-language content with appropriate BCP 47 language identifiers and preserve writing direction when supported by the format. Test bidirectional scripts, mixed digits, punctuation and copied identifiers. Never infer a language tag from the phone’s language alone when the credential specifies its own. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 10 — Dates, values and units

Separate storage values from display formatting. Display locale-specific dates if permitted while preserving UTC offsets, calendar assumptions and validity logic. Keep numeric threshold meaning, boundary inclusion, decimals, time zones and comparators exactly as specified. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 11 — Accessibility and comprehension

Test screen readers, focus order, zoom, high contrast, longer translated strings, keyboard alternatives and error recovery. A translated control is usable only when the person can recognize the action, consequence and accessible name, not just when it fits a button. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 12 — Wallet and protocol flows

Trace issuance, acceptance, credential storage, selective disclosure, presentation, verifier response and recovery. Keep OpenID4VCI issuance separate from OpenID4VP presentation. Simulate delayed issuance and unavailable services rather than translating only the happy path. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 13 — Status and freshness

Distinguish present validity period from live status checking, including revocation, suspension, lookup failure and unknown. Record the time of the check and whether its result is authoritative for the requested decision. “Unable to check” must never become “invalid.” The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 14 — Privacy and security review

Minimize displayed claims and copy of documents. Avoid translation that encourages screenshots, sending secret codes to support teams or exposing a full credential when one attribute suffices. Review phishing warnings and impersonation risks across languages and scripts. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 15 — Independent linguistic and technical QA

Run human translation and revision for high-stakes content, then verify real UI and schema integration. Use a separate subject expert to test the claim’s semantics and a product tester to reproduce the outcome. Machine translation alone cannot assert compliance or trust. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

Gate 16 — Release and change control

Sign off a test matrix of languages, scripts, actors, errors, status states, screen-reader behavior, device modes and issuer profiles. Version the glossary and string bundles. Re-run meaning and parser checks when a schema, wallet protocol, source string or security control changes. The required hand-off evidence is a reviewable artifact: a sample field, a controlled target phrase, an owner decision or an observed test. A reviewer should be able to recreate what was checked without access to personal credential data. For high-impact ambiguity, hold the affected release string rather than guessing. When all sixteen gates pass, the project has a defensible translation process, not a magical guarantee of every future business decision.

5. Structured terminology: what cannot be silently normalized

The following technical words behave like a small grammar of trust. A credential issuer asserts claims, a subject is described by them, a holder manages or presents a credential, and a verifier checks the presented material. An issuer can be trusted for one kind of claim and not another. A relying party decides whether the evidence satisfies its transaction requirements. The meaning of “trust” is bounded by the task; it is not a personality judgment. A claim can be verifiable yet irrelevant, or relevant yet insufficiently fresh.

A status record describes the standing of a credential at a particular moment and under a particular status scheme. A cryptographic proof supports authenticity and integrity checks; it does not automatically prove that the underlying real-world proposition is true. Selective disclosure is a technique for revealing certain attributes while withholding others under a supported design, not a license to write “fully anonymous” on every screen. Authentication checks a present interaction or authenticator; authorization decides an allowed action. Identity proofing investigates an applicant’s claimed identity under a defined process. Those distinctions should survive translation even when the target language prefers a shorter everyday word.

For internationalization, language codes, directionality and string boundaries are part of correct representation. BCP 47 / RFC 5646 provides language-tag principles. The W3C’s July 2026 Strings on the Web: Language and Direction Metadata is a First Public Working Draft, not a final Recommendation; its discussion of reliable language and direction metadata is useful design guidance but should not be misrepresented as a binding deployment requirement. Preserve schema-supported language maps and avoid “translating” protocol keys.

6. Worked casebook — Actor identity and attribution

Actor labels shape accountability. In multilingual deployments, the same English word may feel natural for several roles, but the product should not use an easy synonym until its evidence architecture justifies that equivalence. Each case below uses invented identifiers and hypothetical transactions; no example is a real credential, legal determination or deployed protocol instance. “Controlled” means an illustrative semantic repair subject to the actual issuer schema, privacy rules, and product owner review.

Diagnostic 01 — Issuer label

Setting. A wallet displays the organization that asserts a qualification. The decisive issue is the boundary between the source fact and the reader’s interpretation. The relevant concept is that issuance is an assertion, not the verifier’s separate check. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Credential issued by Northstar Academy.” Unsafe expansion: “Verified by Northstar Academy.” Controlled wording: “Issued by Northstar Academy.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because issuance is an assertion, not the verifier’s separate check. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A reader may mistake the organization for the current checker. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine issuer identifier and issuer-signed statement. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Compare issuer key and verifier log independently. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the credential recipient, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. A false friend can be a word that is perfectly grammatical but wrong for the system state. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The testing question is whether a careful reader would reach a different decision using only the localized version. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 02 — Credential subject

Setting. A professional license names the individual whose status is asserted. This example shows why terminology is a controlled interface to evidence rather than decorative prose. The relevant concept is that the subject may differ from the holder presenting the credential. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Credential subject: person 482.” Unsafe expansion: “Credential owner: person 482.” Controlled wording: “Credential subject: person 482.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because the subject may differ from the holder presenting the credential. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. The wrong individual can be treated as the credential beneficiary. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine subject property and binding evidence. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Simulate an authorized organizational holder presenting a person’s credential. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the verification reviewer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Translation and authorization meet here but remain distinct disciplines. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 03 — Holder

Setting. A wallet user manages a credential while the subject is a company. Read this as an operational contract between a person and a service. The relevant concept is that control of a presentation is not the same claim as being its subject. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Holder: assigned representative.” Unsafe expansion: “Certified company: assigned representative.” Controlled wording: “Holder: assigned representative.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because control of a presentation is not the same claim as being its subject. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Corporate authority may be inferred without evidence. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine holder binding and delegation statement. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Remove delegation and see whether the message remains accurate. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the wallet operator, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Begin with the role that owns the assertion and the role that will act on it. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 04 — Verifier

Setting. A service checks a credential supplied in a presentation. A false friend can be a word that is perfectly grammatical but wrong for the system state. The relevant concept is that checking a proof is not issuing the original claim. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Verifier: service desk.” Unsafe expansion: “Issuer: service desk.” Controlled wording: “Verifier: service desk.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because checking a proof is not issuing the original claim. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A support person may be mistaken for the source of the claim. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The testing question is whether a careful reader would reach a different decision using only the localized version. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine verification policy and actor register. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Trace source issuer and current verifier in two distinct screens. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the service operator, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. The decisive issue is the boundary between the source fact and the reader’s interpretation. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 05 — Relying party

Setting. An application uses an evaluated credential to grant access. Translation and authorization meet here but remain distinct disciplines. The relevant concept is that the consumer of a trust decision may differ from its issuer or verifier. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Relying party: enrollment portal.” Unsafe expansion: “Identity issuer: enrollment portal.” Controlled wording: “Relying party: enrollment portal.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because the consumer of a trust decision may differ from its issuer or verifier. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. An application may claim a power it does not possess. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine access-decision policy and party map. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Check separately who made the claim and who grants access. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the decision maker, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. This example shows why terminology is a controlled interface to evidence rather than decorative prose. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 06 — Trust list

Setting. An onboarding service consults a list of recognized issuers. Begin with the role that owns the assertion and the role that will act on it. The relevant concept is that scope-limited recognition is not universal moral trustworthiness. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Issuer not listed for this claim type.” Unsafe expansion: “Issuer untrustworthy.” Controlled wording: “Issuer not recognized for this claim type.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because scope-limited recognition is not universal moral trustworthiness. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. An inaccurate accusation can harm a legitimate organization. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine trust-list version and supported credential type. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Test recognized issuer for one scope and unsupported scope for another. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the issuer support desk, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Read this as an operational contract between a person and a service. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 07 — Delegated authority

Setting. A representative presents credentials for an organization. The decisive issue is the boundary between the source fact and the reader’s interpretation. The relevant concept is that task authority is narrower than ownership or identity. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Representative authorized for procurement requests.” Unsafe expansion: “Representative owns the organization.” Controlled wording: “Representative is authorized for procurement requests.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because task authority is narrower than ownership or identity. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A translator can expand permissions beyond the delegation. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine signed or policy-backed delegation scope. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Try a request outside the declared delegation. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the procurement verifier, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. A false friend can be a word that is perfectly grammatical but wrong for the system state. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The testing question is whether a careful reader would reach a different decision using only the localized version. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 08 — Assurance roles

Setting. An account login passes authentication but physical identity was not rechecked. This example shows why terminology is a controlled interface to evidence rather than decorative prose. The relevant concept is that authentication assurance and identity proofing assurance are separate judgments. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Authentication successful.” Unsafe expansion: “Identity fully verified.” Controlled wording: “Authentication successful.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because authentication assurance and identity proofing assurance are separate judgments. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Users and staff may assume stronger proof than performed. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine authentication event and proofing record. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Present same login event with no proofing record. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the account user, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Translation and authorization meet here but remain distinct disciplines. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

7. Worked casebook — Biographic attributes and personal claims

Biographical claims can be sensitive and difficult to correct once they are copied. Translation work must therefore distinguish supplied facts from display preferences and avoid using cultural familiarity as a substitute for authoritative data. Each case below uses invented identifiers and hypothetical transactions; no example is a real credential, legal determination or deployed protocol instance. “Controlled” means an illustrative semantic repair subject to the actual issuer schema, privacy rules, and product owner review.

Diagnostic 09 — Legal name

Setting. A holder’s official-name attribute differs from preferred display name. A false friend can be a word that is perfectly grammatical but wrong for the system state. The relevant concept is that a legal-name field is not a general nickname field. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Registered name: A. Chen.” Unsafe expansion: “Preferred name: A. Chen.” Controlled wording: “Registered name: A. Chen.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because a legal-name field is not a general nickname field. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Mismatch checking can break or be misrepresented. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The testing question is whether a careful reader would reach a different decision using only the localized version. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine credential property definition and issuer naming record. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Show official and preferred names side by side without overwriting. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the credential subject, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. The decisive issue is the boundary between the source fact and the reader’s interpretation. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 10 — Name order

Setting. A credential schema stores family and given names separately. Translation and authorization meet here but remain distinct disciplines. The relevant concept is that display order must not collapse two stored fields. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “familyName = Silva; givenName = Mara.” Unsafe expansion: “Full name: Silva Mara (single canonical field).” Controlled wording: “Family name: Silva; given name: Mara.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because display order must not collapse two stored fields. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Verifiers may search the wrong component. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine source schema field keys and rendered view. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Round-trip each component through a different display order. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the registration clerk, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. This example shows why terminology is a controlled interface to evidence rather than decorative prose. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 11 — Transliteration

Setting. An issuer stores a name in two scripts with explicit attestation. Begin with the role that owns the assertion and the role that will act on it. The relevant concept is that a transliteration can be a supported alternate representation without changing legal identity. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Name (original script): …; romanization: ….” Unsafe expansion: “Romanization is official legal name.” Controlled wording: “Original-script name and provided romanized form.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because a transliteration can be a supported alternate representation without changing legal identity. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. The translation may appear to assert an unapproved spelling. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine issuer-provided alternate-name attribute and provenance. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Remove the alternate-name field to see whether it is being invented. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the records administrator, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Read this as an operational contract between a person and a service. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 12 — Diacritics

Setting. A support system compares names containing marks. The decisive issue is the boundary between the source fact and the reader’s interpretation. The relevant concept is that Unicode lookalikes and normalization do not prove identity equivalence. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Name includes combining accent in issuer record.” Unsafe expansion: “Name spelling normalized and certified as identical.” Controlled wording: “Display name as supplied; matching rules are application-specific.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because Unicode lookalikes and normalization do not prove identity equivalence. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Search mismatches or false matches can occur. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine original Unicode code points and matching policy. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Compare visually identical strings with distinct code sequences. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the support analyst, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. A false friend can be a word that is perfectly grammatical but wrong for the system state. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The testing question is whether a careful reader would reach a different decision using only the localized version. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 13 — Birth date

Setting. An age-check credential reveals a full birth date in source data. This example shows why terminology is a controlled interface to evidence rather than decorative prose. The relevant concept is that a threshold result need not justify releasing the underlying date. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Date of birth available to verifier.” Unsafe expansion: “Exact date required for age check.” Controlled wording: “Over-threshold result; do not disclose date unless required.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because a threshold result need not justify releasing the underlying date. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Excessive personal information may escape. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine privacy policy and minimal-attribute requirement. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Run flow with only over-threshold proof enabled. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the end user, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Translation and authorization meet here but remain distinct disciplines. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 14 — Age condition

Setting. A service requires age greater than or equal to a threshold. Read this as an operational contract between a person and a service. The relevant concept is that inclusive threshold differs from strictly greater-than comparison. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Age 18 or above.” Unsafe expansion: “Older than 18.” Controlled wording: “At least 18 years old.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because inclusive threshold differs from strictly greater-than comparison. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. An eligible person could be rejected on a birthday. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine comparison operator and threshold definition. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Test exactly 18, below 18 and above 18. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the eligibility reviewer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Begin with the role that owns the assertion and the role that will act on it. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 15 — Residence

Setting. A credential attests current residence, not nationality. A false friend can be a word that is perfectly grammatical but wrong for the system state. The relevant concept is that residence and citizenship are different statuses. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Resident at address recorded.” Unsafe expansion: “Citizen of issuing territory.” Controlled wording: “Residence address as recorded.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because residence and citizenship are different statuses. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A user may be told the wrong legal fact. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The testing question is whether a careful reader would reach a different decision using only the localized version. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine issuer’s residence property definition. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Cross-check address evidence independently of nationality. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the service desk, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. The decisive issue is the boundary between the source fact and the reader’s interpretation. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 16 — Pronouns and gender

Setting. A contact field has a voluntary display preference. Translation and authorization meet here but remain distinct disciplines. The relevant concept is that communication preferences do not make a government-identity claim. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Preferred form of address: they.” Unsafe expansion: “Legal sex: unspecified.” Controlled wording: “Preferred form of address: they.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because communication preferences do not make a government-identity claim. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A target translation may fabricate sensitive attributes. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine preference field and consent record. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Delete the preference; inspect whether another field is filled in. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the accessibility reviewer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. This example shows why terminology is a controlled interface to evidence rather than decorative prose. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 17 — Unknown value

Setting. An identity form has no issuer-attested middle name. Begin with the role that owns the assertion and the role that will act on it. The relevant concept is that unknown, absent and confirmed none are distinct data states. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Middle name: not provided.” Unsafe expansion: “Middle name: none.” Controlled wording: “Middle name not provided.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because unknown, absent and confirmed none are distinct data states. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Missing evidence may be turned into a false assertion. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine nullable schema and form rules. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Check empty, absent and explicit no-value states separately. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the identity assessor, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Read this as an operational contract between a person and a service. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

8. Worked casebook — Credential data, language and structure

Machine-readable credentials have fields whose bytes and relationships carry meaning independently of visible text. A translator’s intervention must respect that boundary while giving the human reader a clear description of the field. Each case below uses invented identifiers and hypothetical transactions; no example is a real credential, legal determination or deployed protocol instance. “Controlled” means an illustrative semantic repair subject to the actual issuer schema, privacy rules, and product owner review.

Diagnostic 18 — Credential identifier

Setting. A verifiable credential has a machine identifier. This example shows why terminology is a controlled interface to evidence rather than decorative prose. The relevant concept is that identifiers are references rather than prose to translate. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Credential id: urn:example:credential:4f92.” Unsafe expansion: “Credential id: urn:translated:credential:4f92.” Controlled wording: “Preserve the credential identifier unchanged.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because identifiers are references rather than prose to translate. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Resolution, status lookup or signature checks can fail. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine raw identifier and verification report. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Compare exact bytes before and after localization. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the integration engineer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Translation and authorization meet here but remain distinct disciplines. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 19 — JSON-LD context

Setting. A credential uses a referenced semantic context. Read this as an operational contract between a person and a service. The relevant concept is that JSON-LD keys and context URLs are not user-interface nouns. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “@context: https://www.w3.org/ns/credentials/v2.” Unsafe expansion: “@contexte: translated URL.” Controlled wording: “Keep @context and its URL as defined.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because JSON-LD keys and context URLs are not user-interface nouns. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. The processor may fail or interpret properties differently. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine schema and JSON-LD processor validation. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Run credential parser on original and localized UI project. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the schema steward, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Begin with the role that owns the assertion and the role that will act on it. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 20 — Claim property

Setting. A typed field is bound to its defined predicate. A false friend can be a word that is perfectly grammatical but wrong for the system state. The relevant concept is that field names and labels are separate layers. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “credentialSubject.achievement.” Unsafe expansion: “credentialSubject.accomplishment (renamed by translator).” Controlled wording: “Keep the schema property; translate only approved display label.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because field names and labels are separate layers. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A verifier may not recognize the changed field. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The testing question is whether a careful reader would reach a different decision using only the localized version. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine property definition and expected type. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Property-path diff and controlled render test. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the API integrator, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. The decisive issue is the boundary between the source fact and the reader’s interpretation. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 21 — Credential type

Setting. A credential uses a registered type name. Translation and authorization meet here but remain distinct disciplines. The relevant concept is that changing a type alters what relying software believes it received. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “type: TrainingCertificateCredential.” Unsafe expansion: “type: LocalizedTrainingPass.” Controlled wording: “Preserve the registered type unless formally versioned.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because changing a type alters what relying software believes it received. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Interoperability or trust policy selection can fail. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine credential-type registry and issuance profile. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Process with supported profile and unsupported profile. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the wallet developer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. This example shows why terminology is a controlled interface to evidence rather than decorative prose. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 22 — Language tags

Setting. A credential includes localized human-readable descriptions. Begin with the role that owns the assertion and the role that will act on it. The relevant concept is that language identifiers label content, not a user’s preference. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “name language: fr; name text: Certification.” Unsafe expansion: “name language: en after translating only UI.” Controlled wording: “Keep each text string correctly tagged with its actual language.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because language identifiers label content, not a user’s preference. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Wrong speech synthesis and misleading multilingual selection. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine BCP 47 tag and text provenance. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Test two strings of different languages on one screen. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the localization engineer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Read this as an operational contract between a person and a service. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 23 — Right-to-left text

Setting. An identifier appears within a right-to-left instruction. The decisive issue is the boundary between the source fact and the reader’s interpretation. The relevant concept is that visual text order can differ from underlying character sequence. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Confirm ID ABC-42 before continuing.” Unsafe expansion: “Displayed ID 42-CBA.” Controlled wording: “Preserve identifier order and isolate bidirectional rendering.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because visual text order can differ from underlying character sequence. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Users may enter the wrong identifier. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine string boundaries and bidi test screenshots. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Copy displayed identifier and compare exact value. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the screen-reader tester, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. A false friend can be a word that is perfectly grammatical but wrong for the system state. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The testing question is whether a careful reader would reach a different decision using only the localized version. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 24 — Date representation

Setting. A validity date is stored in ISO-style representation. This example shows why terminology is a controlled interface to evidence rather than decorative prose. The relevant concept is that localized calendars and offsets must not silently change instants. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “validUntil: 2028-06-30T23:59:59Z.” Unsafe expansion: “Expires 01/07/2028 everywhere.” Controlled wording: “Valid until the instant represented in the source; show time zone explicitly where needed.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because localized calendars and offsets must not silently change instants. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A user may wrongly believe a credential remains active. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine canonical timestamp and date-format requirements. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Test immediately before and after the exact deadline. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the release tester, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Translation and authorization meet here but remain distinct disciplines. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 25 — Numeric score

Setting. An issuer records a scored outcome with scale metadata. Read this as an operational contract between a person and a service. The relevant concept is that decimal conventions can change, but denominator and measurement meaning cannot. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Score 4.5 of 5.” Unsafe expansion: “Score 4,5 of 10.” Controlled wording: “Score 4.5 out of 5.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because decimal conventions can change, but denominator and measurement meaning cannot. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Eligibility rules may apply the wrong threshold. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine numeric type and scale definition. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Verify numeric round-trip and all boundary scores. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the assessment reviewer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Begin with the role that owns the assertion and the role that will act on it. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 26 — Evidence link

Setting. A credential describes supporting records at a stable endpoint. A false friend can be a word that is perfectly grammatical but wrong for the system state. The relevant concept is that a prose translation cannot create a new authoritative endpoint. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “evidence URL: https://example.org/e/182.” Unsafe expansion: “evidence URL: https://example.org/translated-e/182.” Controlled wording: “Keep the evidence URL unless the issuer registers a replacement.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because a prose translation cannot create a new authoritative endpoint. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Verification can lose its documented evidence. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The testing question is whether a careful reader would reach a different decision using only the localized version. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine issuer endpoint map and response hash where applicable. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Resolve both links under approved test conditions. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the technical reviewer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. The decisive issue is the boundary between the source fact and the reader’s interpretation. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

9. Worked casebook — Issuance, wallet and presentation workflows

Wallets mediate actions, not merely documents. Localized phrases need to show whether the person is requesting, receiving, storing, selecting, presenting, declining or recovering a credential at that exact step. Each case below uses invented identifiers and hypothetical transactions; no example is a real credential, legal determination or deployed protocol instance. “Controlled” means an illustrative semantic repair subject to the actual issuer schema, privacy rules, and product owner review.

Diagnostic 27 — Issuance protocol

Setting. An issuer distributes credentials using OpenID4VCI. Begin with the role that owns the assertion and the role that will act on it. The relevant concept is that issuance and presentation are separate OpenID workflow stages. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Request credential from issuer.” Unsafe expansion: “Present credential to verifier.” Controlled wording: “Request issuance of a credential from the issuer.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because issuance and presentation are separate OpenID workflow stages. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Users may perform the wrong action or expose credentials. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine protocol step and endpoint type. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Trace credential request versus presentation request. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the wallet user, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Read this as an operational contract between a person and a service. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 28 — Presentation protocol

Setting. A relying service asks for supported credential attributes. The decisive issue is the boundary between the source fact and the reader’s interpretation. The relevant concept is that the wallet presents; the original issuer is not necessarily contacted in every presentation. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Present selected attributes.” Unsafe expansion: “Issue selected attributes.” Controlled wording: “Present the selected credentials or attributes.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because the wallet presents; the original issuer is not necessarily contacted in every presentation. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. The UI could imply unauthorized new issuance. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine OpenID4VP request and response model. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Replay a consent decision in a simulated presentation. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the verifier operator, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. A false friend can be a word that is perfectly grammatical but wrong for the system state. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The testing question is whether a careful reader would reach a different decision using only the localized version. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 29 — Wallet offer

Setting. An application offers a credential for optional acceptance. This example shows why terminology is a controlled interface to evidence rather than decorative prose. The relevant concept is that offering, accepting and issuing are separate user states. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Add credential to wallet.” Unsafe expansion: “You have enrolled automatically.” Controlled wording: “Accept credential offer to add it to your wallet.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because offering, accepting and issuing are separate user states. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Users may believe they possess a credential they never accepted. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine credential offer and issuance state. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Decline and inspect the screen text. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the new user, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Translation and authorization meet here but remain distinct disciplines. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 30 — Deferred issuance

Setting. An issuer requires additional processing before delivery. Read this as an operational contract between a person and a service. The relevant concept is that pending is not refusal or invalidity. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Credential request pending.” Unsafe expansion: “Credential rejected.” Controlled wording: “Credential is being processed; check the indicated status later.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because pending is not refusal or invalidity. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Users may abandon a valid workflow. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine deferred issuance state and expiration rules. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Simulate delayed server and completed server. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the customer support, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Begin with the role that owns the assertion and the role that will act on it. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 31 — Presentation selection

Setting. A wallet offers choices among credentials. A false friend can be a word that is perfectly grammatical but wrong for the system state. The relevant concept is that choice should not silently widen the disclosure scope. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Choose credential to present.” Unsafe expansion: “Share all stored identity documents.” Controlled wording: “Choose the credential needed for this request.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because choice should not silently widen the disclosure scope. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Unnecessary attributes may be shared. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The testing question is whether a careful reader would reach a different decision using only the localized version. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine request scope and presented attribute list. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Use a wallet with unrelated credentials. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the privacy officer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. The decisive issue is the boundary between the source fact and the reader’s interpretation. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 32 — Selective disclosure

Setting. A credential supports a proof of age threshold. Translation and authorization meet here but remain distinct disciplines. The relevant concept is that attribute minimization and protocol support must be true for this deployment. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Share proof that age requirement is met.” Unsafe expansion: “Send your full date of birth.” Controlled wording: “Share the supported age-threshold proof.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because attribute minimization and protocol support must be true for this deployment. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A translation can encourage privacy-invasive disclosure. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine credential format and verifier request contract. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Verify that the verifier never receives date of birth. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the privacy tester, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. This example shows why terminology is a controlled interface to evidence rather than decorative prose. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 33 — Holder binding

Setting. An issuer-bound credential includes a holder proof requirement. Begin with the role that owns the assertion and the role that will act on it. The relevant concept is that credential subject and holder proof are not interchangeable. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Proof of possession required.” Unsafe expansion: “Credential subject must log in.” Controlled wording: “The wallet must complete the required holder-binding proof.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because credential subject and holder proof are not interchangeable. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A wrong actor may be asked to authenticate. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine binding method and challenge semantics. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Try a valid credential with missing holder proof. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the security reviewer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Read this as an operational contract between a person and a service. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 34 — Offline checks

Setting. A wallet presents a credential where network status may be unavailable. The decisive issue is the boundary between the source fact and the reader’s interpretation. The relevant concept is that offline proof validation does not imply all live checks succeeded. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Signature checked; current status unavailable.” Unsafe expansion: “Credential is fully current.” Controlled wording: “Proof checked; current revocation status could not be confirmed.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because offline proof validation does not imply all live checks succeeded. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. The verifier may overstate freshness. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine offline policy and last status timestamp. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Switch connectivity off and compare statuses. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the frontline verifier, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. A false friend can be a word that is perfectly grammatical but wrong for the system state. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The testing question is whether a careful reader would reach a different decision using only the localized version. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 35 — Wallet recovery

Setting. A user loses a device holding credentials. This example shows why terminology is a controlled interface to evidence rather than decorative prose. The relevant concept is that wallet recovery and credential replacement depend on system design. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Recover wallet access and re-obtain eligible credentials.” Unsafe expansion: “Send backup key to support.” Controlled wording: “Follow the authorized recovery flow; never share secret recovery material.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because wallet recovery and credential replacement depend on system design. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Social engineering and loss of key custody become more likely. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine documented recovery and re-issuance procedure. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Test lost device without granting support key access. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the helpdesk author, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Translation and authorization meet here but remain distinct disciplines. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

10. Worked casebook — Status, security, privacy and error handling

Security messages are dangerous places for comforting paraphrase. A system that cannot check a status should say exactly that; a service that has checked a signature should not imply that it has verified every biographical fact. Each case below uses invented identifiers and hypothetical transactions; no example is a real credential, legal determination or deployed protocol instance. “Controlled” means an illustrative semantic repair subject to the actual issuer schema, privacy rules, and product owner review.

Diagnostic 36 — Revoked status

Setting. An issuer withdraws the validity of a credential. A false friend can be a word that is perfectly grammatical but wrong for the system state. The relevant concept is that revocation is different from an interrupted lookup or temporary suspension. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Credential revoked.” Unsafe expansion: “Credential temporarily unavailable.” Controlled wording: “Credential revoked under the issuer’s status process.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because revocation is different from an interrupted lookup or temporary suspension. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A person may rely on withdrawn evidence. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The testing question is whether a careful reader would reach a different decision using only the localized version. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine status type, reason policy and update time. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Simulate revoked versus status endpoint outage. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the verifier, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. The decisive issue is the boundary between the source fact and the reader’s interpretation. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 37 — Suspended status

Setting. An issuer pauses a credential pending review. Translation and authorization meet here but remain distinct disciplines. The relevant concept is that suspension need not be irreversible revocation. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Credential suspended.” Unsafe expansion: “Credential permanently cancelled.” Controlled wording: “Credential temporarily suspended, subject to status policy.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because suspension need not be irreversible revocation. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Users may wrongly abandon a reinstatement process. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine status scheme and reinstatement route. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Restore active status and check wording. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the support agent, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. This example shows why terminology is a controlled interface to evidence rather than decorative prose. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 38 — Unknown status

Setting. A status endpoint does not answer. Begin with the role that owns the assertion and the role that will act on it. The relevant concept is that absence of a fresh check is not evidence of invalidity. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Status could not be checked.” Unsafe expansion: “Credential has been revoked.” Controlled wording: “Credential status is currently unknown.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because absence of a fresh check is not evidence of invalidity. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Automated decisions can falsely reject individuals. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine connection error and policy for unknown responses. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Force timeout and compare behavior against revoked result. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the verifier, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Read this as an operational contract between a person and a service. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 39 — Signature

Setting. Cryptographic verification reports a valid signature. The decisive issue is the boundary between the source fact and the reader’s interpretation. The relevant concept is that signature checks do not independently establish every asserted fact. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Signature verification passed.” Unsafe expansion: “All personal details confirmed true.” Controlled wording: “Credential integrity and authorship check passed.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because signature checks do not independently establish every asserted fact. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Users may overestimate the evidence. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine signed payload and verification method. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Inject an irrelevant claim and confirm no overbroad label. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the compliance reviewer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. A false friend can be a word that is perfectly grammatical but wrong for the system state. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The testing question is whether a careful reader would reach a different decision using only the localized version. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 40 — Hash integrity

Setting. A localized interface package includes a downloadable record. This example shows why terminology is a controlled interface to evidence rather than decorative prose. The relevant concept is that integrity comparisons do not create certified translations. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Record hash matches original.” Unsafe expansion: “Document translation independently certified.” Controlled wording: “Downloaded record matches the referenced hash.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because integrity comparisons do not create certified translations. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A checksum could be misused as proof of semantic accuracy. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine hash algorithm and expected digest. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Modify one byte and observe mismatch. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the auditor, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Translation and authorization meet here but remain distinct disciplines. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 41 — Consent checkbox

Setting. A wallet UI asks whether to disclose a requested claim. Read this as an operational contract between a person and a service. The relevant concept is that specific disclosure choice is not a blanket privacy consent. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Share selected credential with verifier.” Unsafe expansion: “I consent to every future use of my identity.” Controlled wording: “Share the selected information for this request.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because specific disclosure choice is not a blanket privacy consent. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A localized checkbox may solicit unapproved permissions. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine request scope and privacy information. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Check refusal, acceptance and subsequent requests separately. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the wallet user, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Begin with the role that owns the assertion and the role that will act on it. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 42 — Privacy notice

Setting. An identity service describes retention. A false friend can be a word that is perfectly grammatical but wrong for the system state. The relevant concept is that event logs, credential copies and personal attributes can have different retention rules. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “We may retain the verification event for 30 days.” Unsafe expansion: “Your identity data will never be stored.” Controlled wording: “Verification event retention is described in the applicable notice.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because event logs, credential copies and personal attributes can have different retention rules. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. The privacy statement could become false. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The testing question is whether a careful reader would reach a different decision using only the localized version. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine data inventory and owner-approved retention schedule. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Inspect a retention period change without updating translation. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the privacy counsel, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. The decisive issue is the boundary between the source fact and the reader’s interpretation. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 43 — Phishing prompt

Setting. A spoofed help screen requests secrets. Translation and authorization meet here but remain distinct disciplines. The relevant concept is that imperative negation is security-critical. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Never share a recovery phrase or authentication code.” Unsafe expansion: “Send your code to our agents.” Controlled wording: “Do not share recovery phrases or one-time codes with support.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because imperative negation is security-critical. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Users can be deceived into disclosing secrets. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine security advisory and approved contact channel. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Ask bilingual reviewer to identify forbidden action in two seconds. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the security trainer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. This example shows why terminology is a controlled interface to evidence rather than decorative prose. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 44 — Error taxonomy

Setting. An identity workflow cannot parse a presentation. Begin with the role that owns the assertion and the role that will act on it. The relevant concept is that parsing incompatibility is not evidence of fraud. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Unsupported credential format.” Unsafe expansion: “Identity fraudulent.” Controlled wording: “Unsupported credential format.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because parsing incompatibility is not evidence of fraud. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Misclassification can lead to unjustified accusations. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine parser error code and supported format matrix. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Test malformed data versus deceptive data independently. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the support responder, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Read this as an operational contract between a person and a service. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

11. Worked casebook — Governance, accessibility and transfer

Governance and accessibility determine whether translated identities remain usable outside the happy path. A sentence that is correct in a design file can still fail a screen reader, a reviewer, a handoff or a change in credential scope. Each case below uses invented identifiers and hypothetical transactions; no example is a real credential, legal determination or deployed protocol instance. “Controlled” means an illustrative semantic repair subject to the actual issuer schema, privacy rules, and product owner review.

Diagnostic 45 — Screen-reader name

Setting. A button icon controls sharing. This example shows why terminology is a controlled interface to evidence rather than decorative prose. The relevant concept is that assistive technology needs an action-specific label. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Accessible name: Present selected credential.” Unsafe expansion: “Accessible name: Next.” Controlled wording: “Present selected credential.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because assistive technology needs an action-specific label. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A user may authorize sharing without realizing it. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine accessibility tree and localized strings. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Navigate with screen reader without looking at the screen. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the accessibility auditor, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Translation and authorization meet here but remain distinct disciplines. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 46 — Long strings

Setting. A compact wallet UI has a narrow button. Read this as an operational contract between a person and a service. The relevant concept is that meaning can be lost by shortening the target-language label. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Check current credential status.” Unsafe expansion: “Check.” Controlled wording: “Check current credential status.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because meaning can be lost by shortening the target-language label. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. The user may mistake a status check for submission. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine design copy constraints and recorded user task. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Test at maximum text expansion and zoom. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the product designer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Begin with the role that owns the assertion and the role that will act on it. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 47 — Voice prompts

Setting. An audio assistant reads a credential type aloud. A false friend can be a word that is perfectly grammatical but wrong for the system state. The relevant concept is that speech output must keep category and action distinct. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Read type as professional license credential.” Unsafe expansion: “Read type as account password.” Controlled wording: “Announce the actual credential type in spoken language.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because speech output must keep category and action distinct. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. People navigating by voice can be misled. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The testing question is whether a careful reader would reach a different decision using only the localized version. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine screen-reader pronunciation dictionary and field type. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Listen in the target language with screen hidden. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the voice user, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. The decisive issue is the boundary between the source fact and the reader’s interpretation. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 48 — Education award

Setting. A university credential asserts award completion. Translation and authorization meet here but remain distinct disciplines. The relevant concept is that admission, enrollment, completion and conferral are different events. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Degree conferred on 2027-09-01.” Unsafe expansion: “Student enrolled since 2027-09-01.” Controlled wording: “Degree awarded on the recorded date.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because admission, enrollment, completion and conferral are different events. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A verifier may falsely treat attendance as qualification. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine issuer’s award record and schema. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Compare enrolled-only and conferred graduates. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the credential evaluator, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. This example shows why terminology is a controlled interface to evidence rather than decorative prose. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 49 — Professional standing

Setting. A licensing issuer asserts current registration. Begin with the role that owns the assertion and the role that will act on it. The relevant concept is that registration scope may exclude tasks or conditions. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Registration active for defined scope.” Unsafe expansion: “Authorized for all professional work.” Controlled wording: “Registration active for the stated professional scope.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because registration scope may exclude tasks or conditions. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. A translated badge may overauthorize practice. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine license conditions and current status. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Check a scope-excluded task with a still-active credential. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the professional verifier, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Read this as an operational contract between a person and a service. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 50 — Employment role

Setting. An employer issues role credentials. The decisive issue is the boundary between the source fact and the reader’s interpretation. The relevant concept is that operational delegation is not ownership or directorship. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Employee may approve invoices up to limit.” Unsafe expansion: “Employee is company director.” Controlled wording: “Employee has the recorded approval authority.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because operational delegation is not ownership or directorship. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Purchasing controls may be exceeded. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine authorization matrix and role period. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Submit request one unit over approved limit. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the organization administrator, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. A false friend can be a word that is perfectly grammatical but wrong for the system state. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. The testing question is whether a careful reader would reach a different decision using only the localized version. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 51 — Disability accommodation

Setting. An access credential indicates eligibility for a service. This example shows why terminology is a controlled interface to evidence rather than decorative prose. The relevant concept is that an eligibility attestation need not reveal diagnosis. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Accessibility support eligibility confirmed.” Unsafe expansion: “Disability diagnosis confirmed.” Controlled wording: “Eligibility for the specified accommodation confirmed.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because an eligibility attestation need not reveal diagnosis. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Sensitive health inferences may be invented. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. A reviewer should be able to identify the data owner and the authoritative field without guessing from an attractive button label. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine minimum required eligibility claim. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Test with diagnosis field absent. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the service provider, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Translation and authorization meet here but remain distinct disciplines. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Linguists can repair the display of meaning; policy owners and engineers must approve any change to entitlement, proof format or permissible action. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 52 — Guardian authority

Setting. A guardian acts for a dependent under defined conditions. Read this as an operational contract between a person and a service. The relevant concept is that representative capacity must not erase subject identity. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Guardian may present required credential.” Unsafe expansion: “Guardian is identity subject.” Controlled wording: “Guardian is authorized to present on behalf of the subject.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because representative capacity must not erase subject identity. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Consent and rights may be attributed to the wrong person. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The localized text must give the person enough information to accept, decline or seek review without claiming actions the system never performed. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine delegation and age-specific rule. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Test after delegated authority has ended. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the guardian support team, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. Begin with the role that owns the assertion and the role that will act on it. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. Then test the resulting phrase against the actual state transition, not merely against another dictionary entry. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

Diagnostic 53 — Cross-system mapping

Setting. Two verifiers use different credential type vocabularies. A false friend can be a word that is perfectly grammatical but wrong for the system state. The relevant concept is that a comparable label is not automatically an equivalent entitlement. In an ordinary translation task, a reviewer might ask whether the words sound natural. In this task, the stronger question is whether the displayed message remains consistent with the claim’s actor, scope, evidence and state. Because a credential can be machine-processed, the reviewer also needs to know whether the text is merely a view of the source or part of an issued, protected credential that requires a controlled re-issuance procedure.

Fictional source and competing renderings. Source phrase: “Training completion certificate.” Unsafe expansion: “Professional qualification license.” Controlled wording: “Training completion certificate.” The unsafe expansion is not rejected because it sounds awkward; it is rejected because a comparable label is not automatically an equivalent entitlement. The controlled line should be checked against the exact application state and the approved target-language concept. If a supported target language needs a longer phrase, prioritize this distinction over visual brevity.

What can go wrong. Users may receive a status they are not entitled to. This is especially likely when a translator sees a screenshot without the API contract, when a reviewer has only the English copy and no sample state, or when a product team reuses a generic success string for several operations. The corrective action is to recover the field and actor definitions, identify what the screen is actually claiming, and refuse any target-language addition that exceeds the source evidence. The testing question is whether a careful reader would reach a different decision using only the localized version. The outcome to preserve is not an optimistic tone; it is the same truthful decision boundary.

Evidence and repair. Examine mapping approval and issuer scope. Ask the owner which parts of the representation are fixed machine data and which are translatable labels. Lock the immutable value, prepare a concept-level explanation in the termbase, and provide one target-language rendering for review with a literal back-gloss. If the current source line is itself misleading, log a source-copy defect rather than silently repairing the product behavior in one language. A bilingual revision pass should then compare source intent, target wording and the observed user journey without using personal data from live credential holders.

Diagnostic release test. Run each schema against the other verifier’s policy. Repeat the test with the interface language changed, with screen-reader output if the control is interactive, and with the relevant negative or missing-data state. Record the exact displayed string and expected result. The release gate fails if the target version claims a stronger proof, a different actor, a larger disclosure or an authorization the product did not grant. It also fails when a technically correct field becomes impossible to understand or operate in the target language.

Transfer to a new reader. For the interoperability designer, begin with an everyday explanation of what the field means, then preserve the specialist term where it is needed for policy, support or audit. The decisive issue is the boundary between the source fact and the reader’s interpretation. Write a one-sentence support response that describes the result without blaming the person or pretending the problem has been resolved. A change of audience can justify a clearer explanation, but it cannot justify inventing a different recorded fact. Keep the resulting explanation in the translation record so the same distinction will survive a new language, an updated interface and a future schema version.

12. Cross-case failure modes and how to diagnose them

1. Actor collapse

The visible symptom is that issuer, verifier, wallet and relying party are described using one convenient noun. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Put each source statement on an actor graph and ask which entity can correct it; repair only the incorrect mapping. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

2. Proof inflation

The visible symptom is that a cryptographic check is announced as universal factual certainty. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Name exactly what was verified and keep substantive claim review separate from cryptographic validation. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

3. Unwarranted consent

The visible symptom is that a single share action appears to authorize unlimited later processing. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Compare scope, retention, refusal and lawful basis with the approved privacy notice and request. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

4. Implicit re-issuance

The visible symptom is that localized fields alter an already protected credential. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Restore signed data, determine whether a new credential must be issued, and version any authorized re-issuance. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

5. Status conflation

The visible symptom is that revoked, suspended, expired, unknown and offline are rendered as one failure. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Generate one test fixture per state and test the localized outcome and accessible description. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

6. Threshold drift

The visible symptom is that at least and greater than are treated as synonyms. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Test exact boundary values and translate the comparison operator rather than the surrounding intuition. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

7. Attribute oversharing

The visible symptom is that the ui asks for a complete document to establish one property. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Examine selective-disclosure support, purpose, verifier policy and the smallest necessary presentation. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

8. Mixed-script identity

The visible symptom is that a right-to-left label reorders an embedded identifier visually. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Use proper bidirectional isolation and verify both copied characters and rendered order. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

9. Date ambiguity

The visible symptom is that an expiry instant is presented as a different day without time-zone context. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Check the canonical timestamp at multiple offsets and communicate a clear local time interpretation. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

10. Transliteration overreach

The visible symptom is that a readable spelling becomes an invented legal name. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Keep attested originals and transliterations in their own approved fields with provenance. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

11. Accessibility loss

The visible symptom is that a shortened translated button hides the action. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Inspect semantic accessible names and task completion by keyboard and screen reader. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

12. Protocol inversion

The visible symptom is that receiving a credential is translated as presenting one. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Trace issuance and presentation events separately using the actual endpoint and request. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

13. Trust-scope expansion

The visible symptom is that a trusted issuer for one credential type is implied trusted for all types. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Inspect the trust policy’s recognized type and scope at the decision point. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

14. Governance mismatch

The visible symptom is that an engineering team updates schema labels without the terminology owner. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Review schema changes and release strings together under version control. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

15. Security instruction reversal

The visible symptom is that negation disappears from a warning about secret material. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Run bilingual imperative and negation review on all recovery, code and phishing strings. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

16. Error accusation

The visible symptom is that a parser error is presented as evidence that a person forged a credential. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Keep technical failure codes distinct from findings of deception, which require independent evidence. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

17. Source ambiguity

The visible symptom is that an english source phrase cannot be mapped to a unique state. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Pause translation, return a source-copy query, and record the approved meaning before localization. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

18. Cross-language drift

The visible symptom is that a new translator changes a controlled concept during a later release. The immediate diagnostic is to reproduce the decision in the source-language interface and compare the exact data state, actor and permitted action. A translated phrase cannot be approved solely because back-translation resembles the source. Repair: Run automated term detection plus a human semantic regression test against earlier approved states. Then create one positive and one negative fixture, record the expected words, and ask an independent reviewer whether the target text implies more or less than the source. Keep a change record that explains the reason for the correction; otherwise the same mistake may return in a later language or software release.

13. End-to-end workshop: from source string to controlled multilingual release

Workshop stage 1: Capture

Export the source message, screenshot context, UI state, credential schema, actor map and policy owner; classify each as protected data, human display or guidance. The deliverable is a named artifact that another reviewer can verify. If the team cannot explain which field or system state prompted a particular sentence, the string is not ready for release. Work from invented test data whenever possible. For each language, include a full-sentence explanation, the exact control label, a negative or error-state version, and a known good example. In this way the translation remains part of a functioning user journey instead of becoming a loose collection of translated words.

Workshop stage 2: Decompose

Write the logical proposition: actor, action, subject, conditions, evidence, time and audience. Mark every term that could add a claim or shift a responsibility. The deliverable is a named artifact that another reviewer can verify. If the team cannot explain which field or system state prompted a particular sentence, the string is not ready for release. Work from invented test data whenever possible. For each language, include a full-sentence explanation, the exact control label, a negative or error-state version, and a known good example. In this way the translation remains part of a functioning user journey instead of becoming a loose collection of translated words.

Workshop stage 3: Align

Match propositions to verified field definitions, protocol role names and status semantics. Resolve any source-language inconsistency before drafting target versions. The deliverable is a named artifact that another reviewer can verify. If the team cannot explain which field or system state prompted a particular sentence, the string is not ready for release. Work from invented test data whenever possible. For each language, include a full-sentence explanation, the exact control label, a negative or error-state version, and a known good example. In this way the translation remains part of a functioning user journey instead of becoming a loose collection of translated words.

Workshop stage 4: Translate

Draft from a concept termbase and the intended audience. Preserve tokens, identifiers, status values, thresholds and placeholders; prefer explanatory words over invented assurances. The deliverable is a named artifact that another reviewer can verify. If the team cannot explain which field or system state prompted a particular sentence, the string is not ready for release. Work from invented test data whenever possible. For each language, include a full-sentence explanation, the exact control label, a negative or error-state version, and a known good example. In this way the translation remains part of a functioning user journey instead of becoming a loose collection of translated words.

Workshop stage 5: Review

Have a second linguist inspect truth conditions, negation, register, readability and cultural assumptions. Ask a domain specialist to inspect the operational meaning. The deliverable is a named artifact that another reviewer can verify. If the team cannot explain which field or system state prompted a particular sentence, the string is not ready for release. Work from invented test data whenever possible. For each language, include a full-sentence explanation, the exact control label, a negative or error-state version, and a known good example. In this way the translation remains part of a functioning user journey instead of becoming a loose collection of translated words.

Workshop stage 6: Integrate

Load the strings into the real interface, never into a counterfeit signed payload. Check fallback languages, plural rules, truncation, directionality and date formatting. The deliverable is a named artifact that another reviewer can verify. If the team cannot explain which field or system state prompted a particular sentence, the string is not ready for release. Work from invented test data whenever possible. For each language, include a full-sentence explanation, the exact control label, a negative or error-state version, and a known good example. In this way the translation remains part of a functioning user journey instead of becoming a loose collection of translated words.

Workshop stage 7: Simulate

Run issuer accepted, issuer rejected, status unknown, wallet offline, missing field, consent refused, authorized sharing and failed binding as separate fixtures. The deliverable is a named artifact that another reviewer can verify. If the team cannot explain which field or system state prompted a particular sentence, the string is not ready for release. Work from invented test data whenever possible. For each language, include a full-sentence explanation, the exact control label, a negative or error-state version, and a known good example. In this way the translation remains part of a functioning user journey instead of becoming a loose collection of translated words.

Workshop stage 8: Measure

Log semantic defects, accessibility failures, false positives, false negatives, time to find a recovery action and user misunderstanding; do not log unnecessary personal claims. The deliverable is a named artifact that another reviewer can verify. If the team cannot explain which field or system state prompted a particular sentence, the string is not ready for release. Work from invented test data whenever possible. For each language, include a full-sentence explanation, the exact control label, a negative or error-state version, and a known good example. In this way the translation remains part of a functioning user journey instead of becoming a loose collection of translated words.

Workshop stage 9: Approve

Record the specific approving owner and evidence. A clean machine test does not replace a language or privacy sign-off, and a clean language review does not replace protocol validation. The deliverable is a named artifact that another reviewer can verify. If the team cannot explain which field or system state prompted a particular sentence, the string is not ready for release. Work from invented test data whenever possible. For each language, include a full-sentence explanation, the exact control label, a negative or error-state version, and a known good example. In this way the translation remains part of a functioning user journey instead of becoming a loose collection of translated words.

Workshop stage 10: Monitor

Watch support tickets and regression tests after release. Feed new mistakes back into source copy, the termbase and fixtures without altering the existing credential data. The deliverable is a named artifact that another reviewer can verify. If the team cannot explain which field or system state prompted a particular sentence, the string is not ready for release. Work from invented test data whenever possible. For each language, include a full-sentence explanation, the exact control label, a negative or error-state version, and a known good example. In this way the translation remains part of a functioning user journey instead of becoming a loose collection of translated words.

14. Transfer exercises: can the method survive a new situation?

Transfer drill 1: Scholarship eligibility

An educational issuer attests successful completion, but a scholarship service needs additional criteria. Translate the completion claim without promising the scholarship outcome. Begin by writing an actor–claim–purpose–time table in plain language. Decide which proposition is evidenced, which is a business rule and which is merely a user-interface instruction. Draft a safe source-language phrase before translating; otherwise a translator may be asked to fix a conceptual error with elegant wording. Prepare two variants for distinct readers: a short action label and a longer help explanation. Ensure both variants are consistent with the same truth conditions. Then run a counterexample that makes the original proposition false or unavailable, and observe whether the localized text changes accordingly. Finish with a reviewer note identifying the invariant and the one field or policy document that controls it.

Transfer drill 2: Professional license renewal

A credential is active but its renewal reminder is approaching. Distinguish valid-until from renewal-due and from a revoked state. Begin by writing an actor–claim–purpose–time table in plain language. Decide which proposition is evidenced, which is a business rule and which is merely a user-interface instruction. Draft a safe source-language phrase before translating; otherwise a translator may be asked to fix a conceptual error with elegant wording. Prepare two variants for distinct readers: a short action label and a longer help explanation. Ensure both variants are consistent with the same truth conditions. Then run a counterexample that makes the original proposition false or unavailable, and observe whether the localized text changes accordingly. Finish with a reviewer note identifying the invariant and the one field or policy document that controls it.

Transfer drill 3: Temporary offline inspection

A verifier can check proof integrity offline but cannot obtain current status. Draft a message that does not misstate freshness. Begin by writing an actor–claim–purpose–time table in plain language. Decide which proposition is evidenced, which is a business rule and which is merely a user-interface instruction. Draft a safe source-language phrase before translating; otherwise a translator may be asked to fix a conceptual error with elegant wording. Prepare two variants for distinct readers: a short action label and a longer help explanation. Ensure both variants are consistent with the same truth conditions. Then run a counterexample that makes the original proposition false or unavailable, and observe whether the localized text changes accordingly. Finish with a reviewer note identifying the invariant and the one field or policy document that controls it.

Transfer drill 4: Multilingual disability access

A person uses voice navigation to approve a limited attribute request. Write the accessible name and warning without requiring diagnosis disclosure. Begin by writing an actor–claim–purpose–time table in plain language. Decide which proposition is evidenced, which is a business rule and which is merely a user-interface instruction. Draft a safe source-language phrase before translating; otherwise a translator may be asked to fix a conceptual error with elegant wording. Prepare two variants for distinct readers: a short action label and a longer help explanation. Ensure both variants are consistent with the same truth conditions. Then run a counterexample that makes the original proposition false or unavailable, and observe whether the localized text changes accordingly. Finish with a reviewer note identifying the invariant and the one field or policy document that controls it.

Transfer drill 5: Guardian presentation

A guardian presents on behalf of a dependent. Preserve actor, subject and consent constraints in two separate sentences. Begin by writing an actor–claim–purpose–time table in plain language. Decide which proposition is evidenced, which is a business rule and which is merely a user-interface instruction. Draft a safe source-language phrase before translating; otherwise a translator may be asked to fix a conceptual error with elegant wording. Prepare two variants for distinct readers: a short action label and a longer help explanation. Ensure both variants are consistent with the same truth conditions. Then run a counterexample that makes the original proposition false or unavailable, and observe whether the localized text changes accordingly. Finish with a reviewer note identifying the invariant and the one field or policy document that controls it.

Transfer drill 6: Alias and official name

A wallet shows an official identity name and a chosen display name. Produce labels that do not imply one field legally replaced the other. Begin by writing an actor–claim–purpose–time table in plain language. Decide which proposition is evidenced, which is a business rule and which is merely a user-interface instruction. Draft a safe source-language phrase before translating; otherwise a translator may be asked to fix a conceptual error with elegant wording. Prepare two variants for distinct readers: a short action label and a longer help explanation. Ensure both variants are consistent with the same truth conditions. Then run a counterexample that makes the original proposition false or unavailable, and observe whether the localized text changes accordingly. Finish with a reviewer note identifying the invariant and the one field or policy document that controls it.

Transfer drill 7: Employment delegation

An employee has purchasing authority up to a limit. Test the exact value at the boundary and one value above it. Begin by writing an actor–claim–purpose–time table in plain language. Decide which proposition is evidenced, which is a business rule and which is merely a user-interface instruction. Draft a safe source-language phrase before translating; otherwise a translator may be asked to fix a conceptual error with elegant wording. Prepare two variants for distinct readers: a short action label and a longer help explanation. Ensure both variants are consistent with the same truth conditions. Then run a counterexample that makes the original proposition false or unavailable, and observe whether the localized text changes accordingly. Finish with a reviewer note identifying the invariant and the one field or policy document that controls it.

Transfer drill 8: Credential no longer recognized

A verifier’s trust list stops recognizing a given issuer type. Avoid saying that the issuer itself is criminal or fraudulent. Begin by writing an actor–claim–purpose–time table in plain language. Decide which proposition is evidenced, which is a business rule and which is merely a user-interface instruction. Draft a safe source-language phrase before translating; otherwise a translator may be asked to fix a conceptual error with elegant wording. Prepare two variants for distinct readers: a short action label and a longer help explanation. Ensure both variants are consistent with the same truth conditions. Then run a counterexample that makes the original proposition false or unavailable, and observe whether the localized text changes accordingly. Finish with a reviewer note identifying the invariant and the one field or policy document that controls it.

Transfer drill 9: Migration to new schema

An issuer adds a new attribute to its credential type. Decide which terminology, UI strings, fixtures and machine mappings must be versioned. Begin by writing an actor–claim–purpose–time table in plain language. Decide which proposition is evidenced, which is a business rule and which is merely a user-interface instruction. Draft a safe source-language phrase before translating; otherwise a translator may be asked to fix a conceptual error with elegant wording. Prepare two variants for distinct readers: a short action label and a longer help explanation. Ensure both variants are consistent with the same truth conditions. Then run a counterexample that makes the original proposition false or unavailable, and observe whether the localized text changes accordingly. Finish with a reviewer note identifying the invariant and the one field or policy document that controls it.

Transfer drill 10: Recovery-phishing drill

A fake message asks a user to send a recovery code. Translate the genuine warning while preserving strong, understandable negation. Begin by writing an actor–claim–purpose–time table in plain language. Decide which proposition is evidenced, which is a business rule and which is merely a user-interface instruction. Draft a safe source-language phrase before translating; otherwise a translator may be asked to fix a conceptual error with elegant wording. Prepare two variants for distinct readers: a short action label and a longer help explanation. Ensure both variants are consistent with the same truth conditions. Then run a counterexample that makes the original proposition false or unavailable, and observe whether the localized text changes accordingly. Finish with a reviewer note identifying the invariant and the one field or policy document that controls it.

Transfer drill 11: Cross-script identifier

A credential identifier contains Latin letters and digits in a right-to-left interface. Test rendered order, copy-and-paste and spoken output. Begin by writing an actor–claim–purpose–time table in plain language. Decide which proposition is evidenced, which is a business rule and which is merely a user-interface instruction. Draft a safe source-language phrase before translating; otherwise a translator may be asked to fix a conceptual error with elegant wording. Prepare two variants for distinct readers: a short action label and a longer help explanation. Ensure both variants are consistent with the same truth conditions. Then run a counterexample that makes the original proposition false or unavailable, and observe whether the localized text changes accordingly. Finish with a reviewer note identifying the invariant and the one field or policy document that controls it.

Transfer drill 12: Consent declined

A person refuses an optional disclosure but can still use part of a service. Avoid turning refusal into an identity verification failure. Begin by writing an actor–claim–purpose–time table in plain language. Decide which proposition is evidenced, which is a business rule and which is merely a user-interface instruction. Draft a safe source-language phrase before translating; otherwise a translator may be asked to fix a conceptual error with elegant wording. Prepare two variants for distinct readers: a short action label and a longer help explanation. Ensure both variants are consistent with the same truth conditions. Then run a counterexample that makes the original proposition false or unavailable, and observe whether the localized text changes accordingly. Finish with a reviewer note identifying the invariant and the one field or policy document that controls it.

15. Frequently asked questions about digital identity translation

1. Can I translate the text inside a signed verifiable credential?

You can propose multilingual human-readable values when the issuer’s data model and issuance process support them. Editing a protected payload after issuance can invalidate its proof or create a record the issuer did not authorize. Treat re-issuance as an issuer-controlled action rather than an ordinary localization step. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

2. What is the difference between a credential issuer and a verifier?

An issuer asserts the claim. A verifier checks a credential or presentation according to its defined rules. One organization may implement both roles, but translations must describe the role actually involved in each event. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

3. Does a valid cryptographic signature prove the person’s claim is true?

Not by itself. A signature supports authorship and integrity checking. A relying party still has to evaluate issuer trust, scope, claim relevance, freshness, status and the transaction’s rules. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

4. Is identity proofing the same as authentication?

No. Proofing establishes confidence in an asserted identity under an identity-proofing process. Authentication checks control of an authenticator or participation in a login at a moment in time. Federation communicates related assertions between parties under protocols. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

5. Why preserve technical identifiers instead of translating them?

Identifiers and machine keys often act as exact references. Modifying them can change identity, break a lookup, damage interoperability or invalidate protected content. Translate surrounding explanations and supported natural-language fields. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

6. How should a translated wallet describe a failed status lookup?

Say the status could not be checked, if that is the actual result. Do not automatically translate a network or service failure into revoked, expired, forged or invalid. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

7. Can a verifier request a birth date when it only needs proof of adulthood?

The appropriate design depends on law, policy and supported credential mechanisms. Where a recognized threshold proof is sufficient, requesting the complete birth date can create unnecessary disclosure. Translate the actual supported data request rather than assuming one universal method. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

8. How are language tags relevant to credentials?

A language tag can identify which language a natural-language field uses. The tag must match its contents, and the system may also need writing-direction information. User display preferences do not automatically redefine the language of the source text. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

9. Can a glossary solve digital identity localization on its own?

A glossary is necessary but not sufficient. It cannot decide whether a proof succeeded, a credential is current or a person granted permission. It must connect to state machines, schemas, actor ownership, independent revision and actual interface tests. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

10. What is the difference between issuance and presentation?

Issuance concerns creating and delivering a credential to a wallet or holder. Presentation concerns making credential information available to a verifier under a request and relevant controls. OpenID4VCI and OpenID4VP address different protocol functions. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

11. Are a holder and a credential subject always the same person?

No. The holder controls a credential in the relevant flow; the subject is what or whom its claims describe. They often coincide for a personal ID, but organizational or representative situations can differ. The supported binding must be examined. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

12. Does selective disclosure mean the service is anonymous?

Not necessarily. Selective disclosure can limit revealed attributes, but the resulting transaction may still identify or be linkable to a person depending on the format, proof method and surrounding design. Avoid an absolute privacy promise. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

13. How do translators handle different name orders and scripts?

Preserve canonical fields, the issuer’s spelling, and separately attested alternate representations. Localize the display order when permitted without swapping family and given name in the source record or inventing a legal transliteration. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

14. Should every unsupported credential be described as suspicious?

No. Unsupported format, unknown issuer, expired credential, invalid proof and suspected fraud are different findings. The wording should reflect actual evidence and offer the appropriate next action without an accusation. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

15. What is the value of an independent revision step?

A second qualified reviewer can catch negation errors, hidden status changes, false equivalence, unnatural instructions and accessibility problems. Technical experts must additionally verify field and protocol behavior. ISO 17100 provides process-oriented translation-service context. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

16. How should a team measure translation quality?

Use fixtures with expected decisions and actions, review critical terminology, test comprehension and accessibility, and track defects by severity. A low typographic error count does not prove that a trust decision was communicated correctly. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

17. Can automatic translation be used on credential help screens?

It can support drafting in lower-risk contexts under an approved workflow, but security instructions, consent, identity proofing and verifier outcomes require controlled review. Never feed live personal credentials to an unapproved system merely to obtain translation. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

18. Which standards should a translator consult first?

Start with the specific deployment’s governing schema and policy. For general concepts, read W3C VC Data Model v2.0, applicable OpenID issuance/presentation specifications, NIST’s identity assurance definitions where relevant, BCP 47 for language tags and ISO 17100 for translation process requirements. The practical check is to trace the sentence to an explicit owner, data property and observed state. When the authoritative system cannot provide that evidence, make the uncertainty visible rather than disguising it with a confident synonym. In a multilingual release, carry the same decision rule across every language and preserve a test fixture that could reveal an unintended change.

16. High-authority references and how to use them

• W3C Verifiable Credentials Data Model v2.0 — W3C Recommendation, 15 May 2025; credential roles, data properties, internationalization and security/privacy considerations.
• W3C Verifiable Credential Data Integrity 1.0 — Recommendation, 15 May 2025; cryptographic integrity mechanisms rather than a guarantee of every external fact.
• W3C Bitstring Status List v1.0 — consult the published specification for credential status representations and associated privacy considerations.
• OpenID for Verifiable Credential Issuance 1.0 — Final, 16 September 2025; credential issuance API and associated roles.
• OpenID for Verifiable Presentations 1.0 — Final, July 2025; credential presentation functionality.
• NIST SP 800-63-4 Digital Identity Guidelines — 2025 final; distinct assurance levels for proofing, authentication and federation; check applicability to the service.
• IETF RFC 5646 / BCP 47 — language tags and identification conventions.
• W3C Strings on the Web: Language and Direction Metadata — First Public Working Draft, 16 July 2026; informative design guidance, not a final W3C Recommendation.
• ISO 17100:2015 Translation services — Requirements for translation services — process and resource requirements; does not by itself certify identity claims.

Research check: sources above were reviewed for terminology against information available on 30 October 2026. Protocol or draft status can change. The online specification, not this article, controls its own normative language. This article supplies a practical translation and localization framework, not legal advice, security certification, or a claim that a particular wallet conforms to any standard. All examples are fictional and should be replaced by approved non-personal test fixtures before project use.

17. Next routes: preserve meaning without taking over another subject

Return to Master Art of Translation | The Complete System for Moving Meaning Between Languages for the general translation architecture, the relation between source meaning and target meaning, review roles, quality and transfer. That is the parent of this specialist digital-identity child; this child handles multilingual digital credentials, wallets, claims, trust judgments, status and user flows. It does not supplant other branches that own cybersecurity incident messages, identity verification protocols, scholarly evidence, legal wording or software localization.

For the underlying problem of choosing precise terms and keeping closely related concepts apart, follow the protected Vocabulary Learning Hub. For the broader relationship among English words, grammar, audience, communication and meaning, follow How English Works. Their independent ownership remains intact. For a practical start, take one high-risk wallet message, write its actor–claim–evidence–status–purpose record, translate it into one target language, test its negative state and only then approve it for wider reuse.

Final principle: A good multilingual identity system gives different readers equally accurate grounds for a decision. It does not turn translation into issuance, a signature into certainty, a login into identity proofing, an error into guilt, a display preference into an official attribute, or an optional disclosure into blanket consent. Preserve the distinction and the person can act with better information, even when the language changes.