Translate MFA Prompts and Recovery Codes Correctly

How do you translate two-factor authentication prompts correctly? Preserve precisely what an MFA screen asks the user to verify, which authenticator or recovery method is available, whether a sign-in is pending or completed, and which security action is permitted. A translation that turns ‘deny this request’ into ‘confirm the request’, or a one-time recovery code into an ordinary password, can make a security interface actively misleading.

People looking for two-factor authentication translation, authenticator app localisation, passkey prompt wording, one-time password translation, MFA recovery code instructions and security alert messages need an answer more careful than a glossary. Account-security language is action language: readers may tap a button, enter a code, ignore a warning, or contact an official recovery channel based on a few words. The translation must preserve the source application’s decision logic.

This guide explains how to localize login verification messages, backup codes, trusted-device notices, suspicious sign-in warnings and account recovery steps into clear English or another language. It concentrates on the human-facing evidence and instructions, not on reprogramming authentication systems or bypassing access controls. We use fictional examples, official security guidance and a repeatable bilingual quality test.

The visible problem: a fluent sentence can still create the wrong action

A sign-in screen often places a long process behind two short buttons. ‘Approve’ and ‘Deny’ look simple, but their meaning depends on whether the reader initiated the sign-in, which account is involved and whether the prompt has already expired. If a translator makes ‘request’ sound like ‘successful login’, the reader loses the distinction between an attempted action and a completed one.

A recovery code, an authenticator-app one-time passcode, a password, an emailed verification link and a passkey are different mechanisms. A translation that calls each one ‘the login key’ prevents readers from recognising the intended method. Some codes are one-time; some are valid for a limited period; others may be retained for future emergency recovery. The source determines which distinction applies.

Threat language is also easy to overstate. ‘A sign-in was attempted from an unfamiliar device’ does not establish that an attacker entered the account. Similarly, ‘request received’ does not establish that an account recovery request has been approved. Accurate localisation must keep the difference between signal, suspicion, investigation and confirmed outcome.

The guiding question is operational: what would a responsible reader do after seeing only the translated prompt? If they would share a code with a stranger, approve an unknown prompt, assume recovery has finished or fail to notice a denied request, the translation has not done its job.

The purpose of this guide is narrow. It teaches how to translate two-factor authentication prompts, account recovery notices and security alerts while preserving the actual authority, status, limits, sequence and next action. It does not replace official instructions from the issuer. Examples are fictional teaching cases; none confirms an actual account, venue, animal or competition. Check live source material whenever a decision has real consequences. Keeping this boundary is what allows a translation to be useful without pretending to be a new decision maker.

First principles: what must survive the language change?

1. Protect the direction of the action

Approval means allowing a particular authentication request. Denial means refusing it. The translation must name the request clearly enough that readers know what they are approving, and it must preserve the negative instruction without awkward double negatives.

In practice, the translator should be able to point to the exact source-language evidence for this distinction. Ask what a reader is authorised to believe, what remains uncertain, and which action the original permits or prohibits. If a target-language expression sounds easier but silently strengthens the claim, return to the source. The right result is not the most reassuring sentence; it is the sentence that preserves the same decision boundary for a person protecting or recovering a digital account.

2. Separate methods of proof

An authenticator app, passkey, security key, SMS code, email link and saved recovery code serve different roles. Translate explanatory labels while retaining the technical distinctions; a brand or standard name may remain untranslated when the issuer uses it as an identifier.

3. Preserve the state machine

Sent, awaiting confirmation, expired, invalid, accepted, denied, locked and recovered are different account states. A pending response must not become an authenticated session simply because the interface is trying to be encouraging.

4. Keep secrets confidential

The translator should not solicit, display or reproduce real passwords, authentication seeds, QR codes or recovery codes. Training examples should use obvious placeholders. The intended reader may need to enter a secret into the legitimate service, not disclose it to the translator.

5. Distinguish alert from proof

An unfamiliar location, browser or device is a signal for investigation, not always an established compromise. Preserve whether a system says ‘possible’, ‘detected’, ‘blocked’ or ‘confirmed’.

6. Respect time and attempts

Time-limited codes, retry counters, cooldown periods and deadlines must retain their units and scope. Where the system does not specify the length of validity, do not invent it from general authentication knowledge.

7. Preserve fallback conditions

A fallback option available to one account is not necessarily available to every user. Translate ‘if you have saved recovery codes’ as a condition rather than promising that codes are available.

8. Keep accessibility and reading order

Short UI strings may be separated from the full flow; screen readers and right-to-left layouts may change presentation. Test whether labels remain distinguishable and whether code placeholders, masking characters and instructions survive localization.

A repeatable twelve-stage translation method

Use this workflow before publishing MFA screens, recovery instructions and security notifications. It can be applied by a student, a professional translator, a bilingual reviewer or a localisation team. The stages are deliberately ordered: observe first, interpret second, draft third and verify last. Skipping the source analysis often creates an attractive sentence that is operationally wrong.

Stage 1: Identify the exact screen

Record the product, account flow, step, device and locale for the prompt. A button inside account recovery may have a different effect from the same button during ordinary sign-in; never translate detached strings without context.

Record the evidence in a two-column working sheet: the original field or sentence on one side and the proposed target-language wording on the other. Add a separate note for uncertainty rather than hiding it inside smooth prose. A reviewer should be able to reconstruct why the wording was selected, especially when a person may approve an unknown login, reveal a secret or misinterpret a recovery requirement. If the source is incomplete, mark it for issuer clarification; translation is not a licence to complete the missing facts.

Stage 2: Classify the requested action

Label each item as identity verification, user approval, account recovery, warning, device registration or session management. The classification determines the nouns, modal verbs and risk emphasis.

Stage 3: Build a field inventory

Extract button names, headings, errors, help links, code labels, countdowns and state banners. Keep the exact IDs and placeholders separate from natural-language strings.

Stage 4: Mark confidential data boundaries

Replace live secrets with test placeholders, and distinguish a display-only masked phone number from a value the user must type. The translation workflow must not expose private security material.

Stage 5: Resolve pronouns and actors

Determine whether ‘we’, ‘you’, ‘your device’ or ‘the administrator’ is the actual actor. A request sent by a service is not a request submitted by a user simply because both are called requests.

Stage 6: Map conditions and negation

Underline ‘if’, ‘unless’, ‘only’, ‘never’, ‘not’, ‘before’ and ‘after’. Connect each condition to its proper action; a misplaced qualifier can reverse a security decision.

Stage 7: Keep code instructions exact

Preserve whether the source says enter a six-digit code, scan an enrolment QR image, touch a registered security key or use a saved recovery code. Never substitute one method for another.

Stage 8: Draft for the target reader

Use direct, natural wording that identifies the relevant account and action without introducing false reassurance. Translate the interface as a coherent interaction, not as unrelated dictionary entries.

Stage 9: Test action-button pairs

Read heading, button and confirmation screen together. ‘Deny’ must lead to refusal, ‘Cancel’ must end the intended operation, and ‘Continue’ must not sound like an already completed verification.

Stage 10: Test high-risk paths

Review unknown sign-in, lost device, changed recovery address, code exhaustion, account lock and expired credential scenarios. Have a reviewer describe the next safest step from the translated text alone.

Stage 11: Run bilingual technical QA

Check numerals, timers, masking, variables, plural forms, links and directionality. Ensure documentation strings do not contradict the actual software behaviour.

Stage 12: Release with escalation

Approve the language only after security owner review of sensitive strings. Record unresolved ambiguity, the source revision and a rollback path for wrong security prompts.

Worked translation cases: test the action, not merely the vocabulary

These fictional micro-cases show how an ordinary-looking phrase can alter a real decision. Every example has a source situation, a plausible but damaging interpretation, a safer rendering principle and a specific test. They are not stock sentences for pasting onto documents: revise the grammar and terminology for the actual source and target languages.

Case 01: An unexpected push notification

Source situation. The interface asks the user to approve a sign-in request they may or may not have initiated. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Rendering the heading as ‘Your sign-in is approved’ turns a pending choice into an accomplished event. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Keep ‘Approve sign-in request’ separate from ‘Sign-in approved’, and keep ‘Deny’ visibly distinct. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Can a user who did not initiate the login tell which button refuses the request? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 02: A code that expires

Source situation. The screen shows a numerical countdown alongside a verification-code field. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Calling the countdown an account expiry or a password reset deadline invents the wrong object. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Translate it as the remaining validity of that specific code only if that is what the source confirms. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Does the reader know whether the code or the whole account is expiring? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 03: A saved recovery code

Source situation. A setup page invites the user to securely store a recovery code for a later emergency. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Describing it as a code that will be texted every time changes the storage method. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Differentiate a saved recovery code from a freshly issued code, without reproducing live codes. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Can the user identify which secret must be saved and which is generated later? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 04: Single-use recovery

Source situation. A service says a saved recovery code may be used only once. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. A translation that says ‘can be reused’ creates a security and access problem. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Preserve single-use status and any explicit replacement process. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Does the reader expect the old code to remain valid after use? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 05: Passkey invitation

Source situation. The platform offers ‘Create a passkey’ as an alternative sign-in method. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Calling it ‘write down a password’ misrepresents the method and may encourage unsafe recording. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Keep passkey as the named method and explain any device-based confirmation the source actually shows. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Can the user distinguish passkey enrolment from creating another password? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 06: Unknown browser sign-in

Source situation. An alert describes a request from a browser the service does not recognise. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. The wording ‘an attacker entered your account’ asserts an outcome not established. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Keep the event as an attempted or detected sign-in, as appropriate, and preserve suggested review steps. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Does the translated notice distinguish suspicious activity from proven compromise? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 07: Authenticator migration

Source situation. Instructions say to transfer a registered authenticator before removing the old device. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. A translation that advises removing the old device first may strand the user. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Retain the order and distinguish transfer completion from the request to begin transfer. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Can the user perform the steps without disabling the only working factor prematurely? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 08: Security-key touch

Source situation. The interface tells the user to touch a connected security key. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. A vague phrase about pressing any keyboard key would misidentify the hardware. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Describe the registered hardware authenticator rather than a general keyboard or button. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Would the user reach for the correct device after reading the translation? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 09: Email link or SMS code

Source situation. The source lists different recovery options depending on the account. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Combining the options into ‘you will get a text’ promises a channel that might be unavailable. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Retain separate channel labels and conditional availability. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Can a user whose account lacks SMS still understand the available option? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 10: Retry limit

Source situation. A message states that additional attempts are temporarily blocked after repeated failures. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Translating blocked attempts as permanent account closure overstates the event. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Retain temporary restriction, any known duration and the actual support route. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Does the user know whether to wait, recover access or contact an administrator? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 11: Clock mismatch

Source situation. The help text says a device’s time settings may cause changing one-time codes not to match. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Suggesting that the app itself is always broken creates false certainty. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Preserve the tentative diagnosis and the approved troubleshooting step. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Is a possible cause still described as a possibility rather than a diagnosis? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 12: Trust this device

Source situation. A tick box offers to remember a device for a defined duration. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Calling it ‘this device is permanently secure’ turns a preference into a guarantee. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Translate the exact remembered period and whether the user may opt out. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Does the user understand that trust applies to the present sign-in workflow? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 13: Biometric prompt

Source situation. A local device asks for fingerprint or face confirmation before using a stored credential. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Describing this as sending biometric data to a website adds an unverified privacy claim. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Describe the verification step actually shown and avoid speculation about data storage. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Is the location of verification and its actual purpose preserved? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 14: Recovery email change

Source situation. The interface warns that changing a recovery address may trigger an additional check. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Calling the change completed immediately omits a potential verification step. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Differentiate ‘requested’, ‘pending confirmation’ and ‘changed’ in the account state. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Would the user know whether the new address is already active? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 15: Incomplete MFA setup

Source situation. The setup wizard says enrolment is not complete until a test code is accepted. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. A cheerful ‘You’re protected now’ banner is premature before confirmation. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Preserve the incomplete status and its required test or confirmation. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Does the translated flow distinguish device addition from successful enrolment? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 16: Disable protection

Source situation. The system requires a recent verification before turning off MFA. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Writing ‘MFA is disabled’ in advance states a result that has not happened. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Use conditional or pending language until the interface confirms completion. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Does the user know whether the protection is currently still active? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 17: Unrecognised location

Source situation. A security alert gives an approximate geographic region for a sign-in attempt. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Presenting the location as a verified street address may mislead the user. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Retain the original precision and any uncertainty about IP-derived geography. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Does the reader treat the place as approximate rather than a certain physical location? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 18: QR enrolment image

Source situation. A setup page asks the user to scan a QR code containing authenticator setup data. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Describing the QR image as safe to publish in a screenshot risks exposure of a setup secret. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Maintain confidentiality warnings and avoid using real QR codes in translated examples. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Can a reviewer recognise this QR as security material rather than a decorative link? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 19: Password reset consequence

Source situation. A service warns that resetting a password may sign out current sessions. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Translating ‘may’ as ‘will’ invents guaranteed termination of every session. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Keep the source’s stated modality and any specific devices affected. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Can the reader distinguish a possible effect from a certain consequence? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 20: Codes regenerated

Source situation. A user generates new recovery codes and receives a warning about the old set. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. The phrase ‘additional codes’ might imply both old and new sets remain valid. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Say whether prior codes are invalidated only when the source confirms it. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Would the user continue relying on an invalid old code after this translation? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 21: Recovery review pending

Source situation. An identity review request has been submitted to the service. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Rendering it as ‘Your account has been recovered’ invents approval. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Use submitted or under review until a confirmed decision arrives. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Would a reader expect immediate access when the source gives none? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 22: Factor removed, account retained

Source situation. The interface confirms that one registered device was removed from the account. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Calling it ‘account deleted’ confuses an authenticator with the entire identity record. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Name the removed device or factor and preserve continued account existence. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Can the user differentiate factor management from account closure? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 23: Administrator-enforced MFA

Source situation. An organisation requires a second factor for managed accounts. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Translating a mandatory administrator policy as a suggestion removes the obligation. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Preserve must versus may, and clarify the organisation’s authority if the source names it. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Does the reader still understand that this setting cannot simply be skipped? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 24: No fallback enrolled

Source situation. The user has no saved recovery codes or alternative authenticator registered. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. A translation that promises recovery by code invents a method the account lacks. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Keep the source’s exact available recovery route and refer unresolved cases to official support. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Does a user know what is genuinely available rather than what another provider might offer? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 25: Right-to-left code display

Source situation. A localized screen contains an ASCII recovery token and a right-to-left explanatory sentence. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Reordering the token’s characters in visual display makes the credential fail. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Keep token bytes unchanged and test directionality and copy-paste in the real UI. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Does the same token survive rendering and copying across writing directions? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 26: Masked phone number

Source situation. A notification displays only the final two digits of a registered phone. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. Turning the mask into a full number falsely reveals data the source did not expose. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Preserve masking characters and identify only the visible digits. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Would the reader believe more personal information is known than actually displayed? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 27: Account recovery warning

Source situation. An email states that a recovery attempt was initiated, with a link to review if unexpected. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. An instruction to share the code with support can be inserted by an unsafe paraphrase. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Keep the review purpose, the warning and a legitimate-channel verification step; never request secrets. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Would someone who did not request recovery know to investigate without disclosing credentials? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Case 28: Code accepted, action not completed

Source situation. A code is verified but the next screen still requires user confirmation of an account change. The material is being read by a person protecting or recovering a digital account who may act immediately, without seeing the original language or knowing the institution’s internal workflow.

Tempting but unsafe translation. ‘Verification succeeded’ must not become ‘Account changes saved’ or the workflow ends too early. A phrase can be grammatically elegant and still change whether the instruction is optional, conditional, completed, pending or prohibited. This is the point at which translation quality must be judged by the reader’s resulting decision, not by how pleasant the sentence sounds.

Better translation decision. Keep confirmation of the code separate from confirmation of the requested change. Keep the exact relationship between the actor, action, qualifying condition, time and source record. Do not insert a promise merely because it seems likely. Preserve distinct statuses in separate labels when the source uses them separately; collapsing the labels can hide the crucial distinction.

Verification question. Can the reader identify the remaining action without assuming all work is complete? For this case, the final bilingual check should compare the critical phrase with adjacent screens, forms or instructions. Ask a second reader to explain what happens next using only the translation. If that explanation differs from the original reader’s legitimate understanding, revise the wording before it is distributed.

Failure atlas: what goes wrong and how to repair it

1. Approval and denial collide

Translating approve, confirm, reject and cancel as interchangeable verbs can make the strongest button dangerous. Build a two-button action map with the exact outcome of each control before selecting the target wording.

The repair is to separate source evidence from the translator’s interpretation. Mark the field as verified, unresolved or requiring an issuer decision. Read the surrounding paragraph, check the controlling label and test the same hypothetical person following the source and translation. A correction should remove ambiguity without adding new permissions or invented certainty. This is especially important when a person may approve an unknown login, reveal a secret or misinterpret a recovery requirement.

2. Codes become generic passwords

A one-time passcode, recovery code and account password are not synonyms. Build a method glossary that includes issuing context, whether a code is saved, its validity and the appropriate input field.

3. Source-state inflation

A notice about a request in progress becomes an announcement of success. Mark the original status and check whether a second confirmation step remains.

4. Invisible negation

Short warning text loses ‘not’, ‘never’ or ‘only’. Compare negative instructions against the original and use user testing to ensure the prohibited action stays clearly prohibited.

5. Time and retry errors

Numerals, countdown variables or retry thresholds change during localisation. Verify dynamic strings in the product and test singular and plural forms if a countdown is shown.

6. Secrets leak into examples

Screenshots or training examples accidentally display valid credentials or QR seeds. Replace every secret with clearly fake samples and review the published page for accidental disclosure.

7. Fallback is invented

A guide implies every account has SMS or email recovery, even where that service uses a different procedure. Preserve available options for the particular account and flag missing context.

8. Overconfident security claims

A service says it detected a possible risk, while the translation announces a confirmed breach. Preserve the level of evidence and avoid making technical guarantees that the source does not make.

Practice laboratory: train transfer, not phrase memorisation

Try the following exercises without looking for a dictionary substitute first. For each one, write the invariant, the misleading alternative, the safer sentence and the evidence needed to approve it. Then use the suggested reasoning as a model for your own check rather than treating the example as universal policy.

Exercise 1: Unknown-login prompt

Write a bilingual microcopy pair for ‘Did you just try to sign in?’ and two separate actions. Explain why the deny action cannot be softened into a neutral dismissal.

Model reasoning: The invariant is the user’s control over an unverified authentication request. A neutral ‘close’ button may not refuse the request if the source explicitly gives a denial action. The exercise is complete only when your target reader can identify the same next permissible action, the same uncertainty and the same person or organisation responsible for the next step. If you need to invent a missing field to make the sentence read smoothly, record that gap as a query instead.

Exercise 2: Single-use backup code

Translate a short notice saying one saved recovery code has been used and cannot be reused.

Model reasoning: State the consumed status without implying that every remaining recovery code is invalid; the original must tell you whether a whole set was replaced. The exercise is complete only when your target reader can identify the same next permissible action, the same uncertainty and the same person or organisation responsible for the next step. If you need to invent a missing field to make the sentence read smoothly, record that gap as a query instead.

Exercise 3: Ten-minute countdown

Draft an error message for a verification code that is no longer valid after the source’s stated interval.

Model reasoning: Keep the interval attached to the code, not the account or the whole recovery process, and test how the string changes at one minute. The exercise is complete only when your target reader can identify the same next permissible action, the same uncertainty and the same person or organisation responsible for the next step. If you need to invent a missing field to make the sentence read smoothly, record that gap as a query instead.

Exercise 4: Device replacement

Write a three-step instruction that tells users to transfer the factor, verify the new device and then remove the old one.

Model reasoning: Preserve the order of operations; a stylish summary that skips verification changes the risk of being locked out. The exercise is complete only when your target reader can identify the same next permissible action, the same uncertainty and the same person or organisation responsible for the next step. If you need to invent a missing field to make the sentence read smoothly, record that gap as a query instead.

Exercise 5: Passkey versus password

Prepare an accessible explanation that differentiates a passkey from a typed password without promising support for every device.

Model reasoning: Keep the source’s available method, local device interaction and any fallback requirements distinct. The exercise is complete only when your target reader can identify the same next permissible action, the same uncertainty and the same person or organisation responsible for the next step. If you need to invent a missing field to make the sentence read smoothly, record that gap as a query instead.

Exercise 6: Suspicious-access email

Translate an email that reports an unusual sign-in attempt but not a successful compromise.

Model reasoning: Use tentative language and preserve the official review route, without introducing a demand to reply with secret codes. The exercise is complete only when your target reader can identify the same next permissible action, the same uncertainty and the same person or organisation responsible for the next step. If you need to invent a missing field to make the sentence read smoothly, record that gap as a query instead.

Exercise 7: Two audiences

Produce a short plain-language variant for a student and a precise variant for a system administrator.

Model reasoning: Both may vary in register but must preserve policy enforcement and the actual authentication step. The exercise is complete only when your target reader can identify the same next permissible action, the same uncertainty and the same person or organisation responsible for the next step. If you need to invent a missing field to make the sentence read smoothly, record that gap as a query instead.

Exercise 8: QA ticket

Write a translator’s issue report when a button reads ‘Continue’ but the destination screen is unknown.

Model reasoning: Do not infer the button’s security consequence; request the neighbouring screen, interaction mapping and a verified source string. The exercise is complete only when your target reader can identify the same next permissible action, the same uncertainty and the same person or organisation responsible for the next step. If you need to invent a missing field to make the sentence read smoothly, record that gap as a query instead.

Frequently asked questions

What is the safest way to translate an authenticator prompt?

Start by identifying the requested action, whether the user initiated it and what each button actually does. Only then select the target verbs. Preserve pending, approved and denied as separate states.

A useful practical test is to explain the difference in plain language and then verify the corresponding source field. Translation can clarify vocabulary and sentence structure, but it must not quietly reclassify an issuer’s decision. Retain an evidence trail if the phrase can affect safety, cost, eligibility, responsibility or access.

Can ‘one-time code’ and ‘recovery code’ be translated identically?

Not as a general rule. A code entered during normal authentication and a saved code used after losing an authenticator may serve different purposes. Keep the provider’s method names and instructions distinct.

Should passkey always be translated into a local phrase?

Use the localisation choice supported by the product and its audience. Often the product’s established technical label is retained with a brief explanation. Avoid implying it is a traditional memorised password.

Can an AI translator handle login instructions alone?

It can assist with first drafts and terminology comparisons. Human review should inspect state transitions, warning language, interface limits and test scenarios before security-critical strings reach users.

How do I translate a masked number?

Preserve the masking and the exact visible digits. Do not infer or reconstruct hidden digits, and test that left-to-right and right-to-left displays do not change numeric ordering.

What if a source says an account may be compromised?

Preserve the modality. ‘May be’ reports a possibility; it does not prove compromise. Include the original issuer’s next-step guidance where present.

Should recovery instructions say contact support?

Only when the source identifies support as an authorised option. Do not invent email addresses or invite people to send passwords or codes to the translator.

Are SMS codes the same as passkeys?

No. They are different authentication mechanisms with different capabilities. Security properties should be explained from reliable standards rather than asserted by translating both as an ‘access key’.

How do I test a translated MFA screen?

Use synthetic test accounts and non-secret sample values. Run normal, failed, expired, cancelled, lost-device and unknown-request paths while comparing the displayed state and user action in both languages.

What should stay in English?

Product names, protocol identifiers and fixed API tokens may need to remain intact. The surrounding natural-language explanation should still be understandable to the target reader.

Contextual next routes: language foundations and related translation owners

For the underlying principle that words are vehicles for meaning rather than interchangeable tokens, read Translate Meaning, Not Just Words. To calibrate the audience and the source voice, use Context, Tone and Register; for specialised labels and systematic review, consult Terminology, Glossaries and Quality Checks. Figurative wording belongs to the separate Idioms, Culture and Non-Literal Language owner rather than this article’s operational scope.

Build background vocabulary with the Vocabulary Learning Hub. For wider reading and comprehension methods, visit How English Works, especially Translation and Meaning Across Languages. These routes give readers the language infrastructure while this article keeps ownership of two-factor authentication prompts, account recovery notices and security alerts.

References and a responsible handoff

NIST SP 800-63B Digital Identity Guidelines. Defines authenticator categories and account-recovery concepts; it is a standards reference, not a statement about every commercial app.

W3C Internationalization. Guidance on language, scripts and internationalised interfaces, relevant to placeholders, layout and mixed-direction strings.

CISA Secure Our World. Public-facing guidance on account security; use for background explanation rather than assuming each app follows identical prompts.

Official reference documents provide context, not a substitute for the current notice, application, operator or issuer. Policies and interfaces can differ by country and change over time. Apply the method to the latest actual source; confirm any uncertain permission, deadline, health description or security instruction with the accountable organisation. When a translation may affect someone’s safety or rights, arrange qualified bilingual review before real-world use.

Final review: can both readers make the same justified decision?

A good translation of two-factor authentication prompts, account recovery notices and security alerts should pass a simple but demanding test: an original-language reader and a target-language reader, each given the same source facts, should understand the same status, limits, next action and uncertainty. The output may be more idiomatic and easier to read, but it must not invent evidence, erase a condition or silently change a decision. That is the practical foundation of accurate, responsible translation.

Top Ways to Translate Correctly | Translate Two-Factor Authentication Prompts, Recovery Codes and Security Alerts Without Weakening Account Safety