To translate a website’s buttons, navigation menus and error messages into another language, preserve what every control actually does. A translated Save draft must still save a draft, not publish the page. A Delete account warning must describe the same loss and recovery options as the source. A good website translation makes the interface easy to use without changing the user’s permissions or next action.
People searching for how to translate website buttons, website menu translation, UI text localization or how to translate error messages need to work beyond the visible words. Website labels are connected to actions, form validation, navigation, consent and application states. A sentence can be fluent in the new language yet lead a person to click the wrong command or misunderstand a successful payment.
This guide explains user-interface translation for multilingual websites, covering menus, call-to-action buttons, login pages, form validation, alerts, accessibility, dates, placeholders, checkout states and mobile layouts. The guiding test is practical: a visitor using the target language should be able to complete the same task with the same rights, information and consequences as a visitor using the original.
Quick method: connect each translated label to its real action
For every interface string, record its screen, user intention, action, resulting state and relevant constraints. Translate with that context, protect variables and exact identifiers, and test the completed target screen. If a wording change affects consent, payment, deletion, identity or other consequential actions, obtain product-owner review before release.
Fourteen principles for safe, useful website translation
Start with the action behind every label
A website string is often part of an interaction: it tells a visitor where a link goes, what a button does, what a status means, or which input needs correcting. Translate the intended action first. A ‘Save draft’ button must not turn into ‘Publish now’, and a ‘Request a quote’ action must not promise that a booking is complete. The words can be short, but their consequences can be large. Build a map connecting the source label, component, destination, permission and resulting state before choosing a target phrase.
Ask what the user would expect to happen after clicking, and verify that against the actual interface. Natural language may differ across cultures, but the underlying operation should remain identical. When the source label is itself vague, query the product owner rather than adding an unsupported guarantee or redirect.
Differentiate navigation labels from action buttons
Navigation takes the visitor to another page or section; an action button submits, changes, saves, starts or cancels something. Translate a menu such as ‘Pricing’ or ‘Help Center’ so users can predict its destination. Translate ‘Submit payment’ with its true financial consequence rather than giving it a generic ‘Continue’ label that hides the step. A link and a button may look visually similar, but their semantic roles differ.
Review menus in context. ‘Plans’ might mean subscription tiers, architectural drawings or a personal to-do list. The target should reflect the destination content. Clicking the translated menu and reading the destination page is a practical translation check that a spreadsheet of isolated UI strings cannot perform.
Preserve distinctions between account states
Sign in, sign up, create an account, verify an email address, recover an account, reset a password and log out are separate operations. A target-language term that confuses existing-user login with new-user registration sends people down the wrong route. Security-related language often includes conditions on identity verification and whether a reset link was actually sent.
Use the application state and surrounding screen as context. A button cannot be evaluated separately from its heading and subsequent screen. Confirm which account action occurs after activation, which data is required and whether the user can go back without losing progress. Do not claim successful verification if the system merely sent a request.
Distinguish save, submit, publish and send
A saved draft may still be private or incomplete; submit may hand a form to a reviewer; publish may make material visible to others; send may transmit a message. Translating all four as a generic ‘done’ can lead to accidental release or mistaken expectations. Describe the state transition in the target label, and keep confirmation messages consistent with what actually happened.
Test the action with a safe sample record. Did a draft persist? Was an application transmitted? Is content publicly visible? If the interface has asynchronous processing, ‘Request received’ differs from ‘Request approved’. The user’s real task should determine which wording is acceptable.
Protect destructive actions and reversibility
Delete, move to trash, archive, remove from a list, clear a filter, unsubscribe and permanently erase have different consequences. Users must know what is reversible and what might be lost. A translated confirmation that promises ‘You can undo this’ when the system has no undo path is misleading. Preserve scope: removing one item is not deleting the entire account.
Check the destructive flow end to end: menu label, confirmation heading, warning details, primary action and result message. Use plain verbs rather than euphemisms for serious operations. If the service performs a soft delete with recovery available, describe that truthfully; if recovery is unavailable, do not promise it.
Translate validation errors as actionable feedback
An error message should tell the user what field or action failed and how to correct it when possible. ‘Enter a valid email address’ is more useful than a generic ‘Invalid’. Translation can make an error worse if it omits a required format, changes a character limit or tells users to retry an action that actually needs a different permission. The target message must match the application’s underlying validation.
The W3C’s WCAG explanation of error identification stresses identifying detected input errors in text. Check blank required inputs, out-of-range numbers, format errors and failed submission paths in the translated site. Error text and software behavior must agree, or visitors will remain stuck even after following the instructions.
Separate errors, warnings and success states
An error indicates something did not work; a warning signals a possible problem or consequence; success confirms a completed operation. Do not translate ‘Your request was received’ as ‘Your request was approved’. A toast saying ‘Changes saved locally’ is not evidence the server synchronized them. A timeout message may leave the transaction state uncertain, so the target should not declare failure or success when the system has not verified either.
Map each string to the event that triggers it, including loading and pending states. In a multilingual checkout or application, the precise state matters more than warmth or brevity. Test network interruption and duplicate submission in a safe environment to see whether the target wording guides the user appropriately.
Protect placeholders, variables and plural forms
Software strings may include parameters such as a person’s name, a count, a date, an amount or a product code. These are data fields, not words to replace indiscriminately. In a localised message such as ‘{count} new messages’, the target language may require different plural rules or a different word order. A translator needs to know the meaning and type of each parameter.
Do not delete placeholder syntax or reorder identifiers outside the localisation system’s supported method. Test zero, one, two and larger counts as appropriate for the target language. Names and prices should display correctly in realistic output. A string that looks fine in a translation editor may break when the interface inserts a variable.
Respect language direction, length and typography
Translations can be longer than source labels, especially in small navigation bars and buttons. A string that fits a desktop header may clip on a phone. Right-to-left scripts also affect menu direction, breadcrumbs, mixed Latin product names, numeric expressions and focus order. Do not solve layout problems by omitting warnings or replacing precise verbs with vague ones.
Test target fonts, contrast, text zoom, narrow screens and keyboard navigation. Text expansion is a layout responsibility shared by designers and developers, not a reason to weaken translation. An interface should remain readable in every language it officially offers.
Maintain accessible names and visible labels
A control can have visible text, a programmatically supplied accessible name and additional instructions for assistive technology. These should identify the same action. A visually translated ‘Search’ button that a screen reader still announces as ‘Delete’ is a serious mismatch. W3C’s labeling guidance explains why controls need clear names tied to their purpose.
Check focusable controls with a screen reader or another accessibility review method where possible. Preserve required-field markers and error announcements. The target language should not rely on color, icons or position alone to explain a destructive or consequential operation. Accessible names are part of the translation inventory, not optional metadata.
Keep locale data separate from plain translation
Dates, currencies, numbers, phone formats and addresses may need locale-specific presentation, but the underlying information must remain correct. Changing ‘$10’ into ‘€10’ does not convert money. A date such as 04/05/2026 may be ambiguous without the locale, and a displayed hour can involve a time-zone conversion the translator is not authorized to perform.
Use reliable internationalization libraries and the product’s approved market settings for formatting rather than freehand string replacement. Test checkout totals, invoice dates, appointment times and numeric thresholds at their boundaries. Language choice alone should not alter an amount owed, a deadline or a user’s identity.
Translate forms, consent and privacy boundaries precisely
Web forms may ask for contact details, cookie preferences, marketing consent, payment authority or permission to publish material. Translate who requests information, which fields are optional and what the button authorises. ‘Accept selected cookies’ is not the same as ‘Accept all’. ‘Subscribe to updates’ should not imply acceptance of unrelated marketing if the source does not.
Privacy and security language should be reviewed by responsible owners for the target audience. Do not add stronger guarantees about encryption, deletion or anonymity than the system actually offers. A visitor should be able to decline or grant the same choices in every supported language, and the stored preference should reflect the target label.
Protect search, filters and sorting functions
A site may offer filters for available items, price, distance, age, rating or date. Translate the condition precisely: ‘At most $50’ includes $50, while ‘Under $50’ may exclude it. Sorting labels such as ‘Newest’, ‘Price: low to high’ and ‘Most relevant’ should correspond to the result order the software actually uses.
Test a small known dataset. A target label that reverses ascending and descending sort produces an interface that behaves contrary to what users understand. Search-result empty states also require a clear next step, such as removing a filter, rather than claiming no products exist in the entire catalog.
Review the whole journey, not a string list
Translation files contain words without necessarily showing the screens where they appear. The same source word ‘Open’ can mean open a file, open a menu, open an account or an active status. A reviewer needs screenshots, component IDs, user tasks and state transitions. Build a translation glossary that distinguishes these meanings rather than forcing one equivalent everywhere.
Conduct a task-based test in every target language: create an account, search, apply filters, complete a form, recover from a validation error and navigate back. Include a small-screen layout and assistive technology review where possible. If a user following the target words reaches a different result from a source-language user, the translation or interface still needs work.
Interface quality begins with the user journey
A language switch should not become a different product experience. Every link, alert, button, form and confirmation should give people truthful information about what will happen next. The best way to find errors is to perform real tasks, including a deliberate mistake, in the localized interface. That is more revealing than checking a spreadsheet of translated words in isolation.
Twenty-eight worked cases: when a small UI translation changes a real action
Each scenario is illustrative and shows a translation problem that may only appear when someone uses the interface. Read the source state, identify the potentially misleading interpretation and test the target button or message against the software’s actual action.
1. Sign in is not sign up
Source situation: The source has separate buttons: ‘Sign in’ for existing accounts and ‘Create account’ for new users. Both are translated as ‘Register’, making returning members unsure which route to take.
Potential misunderstanding: The problem is not a stylistic inconsistency; the two buttons initiate different workflows. An existing user’s login details may be rejected by the registration page, while a newcomer may search for a nonexistent sign-up path.
Verification and fix: Use terms that clearly distinguish authentication from account creation. Check the screen reached after each target-language button. A new user and returning user should each find the right path on the first attempt.
2. Save draft versus Publish
Source situation: A content editor has ‘Save draft’ and ‘Publish’ beside each other. The target translation uses the same word for both, because each can colloquially mean ‘finish’.
Potential misunderstanding: One action preserves unpublished work; the other may expose information to readers immediately. The translation hides a meaningful privacy and workflow boundary, especially when a user is preparing a sensitive article.
Verification and fix: Translate state transitions explicitly and check the resulting status with a sample item. A target user should know whether their work remains private and whether another person can see it.
3. Delete, archive and move to trash
Source situation: A messaging app offers to archive a conversation or delete it. The target uses one generic verb meaning ‘remove’.
Potential misunderstanding: Archiving can hide a conversation while retaining the record; deleting may discard it. The target could cause a user to lose information they intended merely to tidy away.
Verification and fix: Use distinct terms, and ensure each confirmation dialog describes the actual operation and available recovery path. Never promise Undo unless the product really supports it for that action.
4. Remove one file versus close an entire account
Source situation: A settings screen says ‘Remove this file’. A translation reads ‘Delete account’ due to reuse of an unrelated string entry.
Potential misunderstanding: The target drastically widens the scope of the apparent operation. Even if the underlying button still removes only a file, users may be frightened into abandoning the task.
Verification and fix: Map every source string to its component ID and object scope. In the target, the noun should identify precisely which file, list, session or account the action affects.
5. A payment request mistaken for confirmation
Source situation: The checkout button reads ‘Pay now’. A translated variant says ‘Payment complete’ before any payment has been submitted.
Potential misunderstanding: This changes expectation from starting a transaction to receiving evidence it succeeded. The user may navigate away or assume the charge was processed.
Verification and fix: Keep the action wording on the button, and show a distinct outcome message only after a verified payment event. Test failed authorization, success and pending states separately.
6. Save locally versus saved to the cloud
Source situation: An offline note-taking app reports ‘Saved on this device; sync pending’. The target shortens it to ‘Saved everywhere’.
Potential misunderstanding: Local persistence does not prove that other devices have received the file. The user may shut down or share a link assuming colleagues can already access the work.
Verification and fix: Preserve local and cloud state as distinct messages. A target reviewer should know when it is safe to rely on synchronized availability and how the app displays incomplete uploads.
7. Password reset link requested versus password reset
Source situation: After a user supplies an email, the website says ‘If this account exists, reset instructions will be sent’. The target says ‘Your password has been changed’.
Potential misunderstanding: No password has actually been changed, and the original may deliberately avoid confirming whether an account exists. The new statement is a security and state error.
Verification and fix: Translate the conditional outcome and future action rather than pretending the reset is complete. Test the screen after submission without inventing account verification or delivery guarantees.
8. The email is invalid, not the person
Source situation: A registration error reads ‘Please enter a valid email address’. The target says ‘You are not valid’.
Potential misunderstanding: The message becomes hurtful and fails to identify the input problem. A person using a screen reader may receive no actionable information about what needs changing.
Verification and fix: Name the field and correction in natural language. The W3C recommends identifying input errors in text. Test the error with blank and malformed addresses, ensuring the same instruction is relevant.
9. Too few characters versus too many
Source situation: A username field accepts 8 to 20 characters. The target error says ‘Use at most eight characters’, reversing the lower boundary.
Potential misunderstanding: The error invites users to enter another value that the software will reject. They may be trapped in a loop despite doing exactly what the translated message asks.
Verification and fix: Keep both minimum and maximum, or identify the violated boundary precisely. Test values of 7, 8, 20 and 21 characters in each language.
10. An inclusive spending filter
Source situation: The original filter says ‘Price: $50 or less’. The translation uses a phrase meaning ‘under $50’.
Potential misunderstanding: A product priced exactly $50 belongs in the source results but seems excluded by the target label. The label and actual filtering logic now contradict each other.
Verification and fix: Preserve inclusive comparisons and the currency. Use sample products at $49.99, $50.00 and $50.01, then compare displayed results with the target description.
11. Sort high to low becomes low to high
Source situation: A catalog sorts products by price descending. The translated label says ‘Cheapest first’.
Potential misunderstanding: The user expects low prices while the site shows expensive items. Even if the numbers and products are correct, the direction of the interaction is wrong.
Verification and fix: Translate the ordering rule explicitly. Test with three prices and verify the first result. Sorting terms such as newest, oldest, most relevant and highest rated require the same attention.
12. A search no-results state claims no product exists
Source situation: A filtered catalog shows ‘No results with these filters’. The translation says ‘This product does not exist’.
Potential misunderstanding: The source describes a temporary filtered view, not whether a product exists anywhere in the store. This can falsely discourage someone from trying a different size or removing a price limit.
Verification and fix: Preserve the current search scope and provide the same recovery action, such as clearing filters. Test the target empty state by applying and removing a restrictive filter.
13. The checkout says shipping instead of delivery
Source situation: An order summary states ‘Dispatch estimate: three working days’. The target calls this ‘Delivery guaranteed in three days’.
Potential misunderstanding: The translation changes the logistical event, its certainty and the type of days. It creates a promise the fulfilment system may not make.
Verification and fix: Keep dispatch and delivery distinct and preserve estimated versus guaranteed language. Verify the selected shipping method and what the checkout actually calculates before publication.
14. Accept selected cookies becomes accept all
Source situation: A consent banner has ‘Accept selected’ and ‘Accept all’. The target uses the equivalent of ‘Agree’ for both actions.
Potential misunderstanding: The difference determines whether a user grants limited preferences or broad tracking consent. Reusing one label can make privacy controls confusing or misleading.
Verification and fix: Translate scope rather than merely positivity. Test that each button stores the intended selection and that the target-language confirmation reflects what was actually chosen.
15. A newsletter checkbox changes from optional to mandatory
Source situation: The source says ‘Email me occasional updates’ beside an unchecked optional box. The target claims updates are required to use the service.
Potential misunderstanding: The localized site now pressures a user to accept marketing beyond the original flow, even if the underlying software still leaves the checkbox optional.
Verification and fix: Keep voluntariness and purpose clear. Check the interface and actual recorded preference, then ask a target-language reader whether they understand the choice can be declined.
16. A count variable is dropped
Source situation: The source string reads ‘{count} items selected’. During localization the placeholder is removed because a translator thinks it looks like code noise.
Potential misunderstanding: The software may display an incomplete phrase or fail to insert the count. The target no longer tells the user the scope of the bulk action, which matters before deletion or export.
Verification and fix: Protect exact placeholder syntax and use the supported plural message system. Test zero, one and several selected items; each target rendering should convey the right number.
17. A translated message inserts the wrong user’s name
Source situation: The app renders ‘Welcome back, {name}’ but the localization system associates the variable with a different field after a resource-key change.
Potential misunderstanding: The text may appear fluent while revealing someone else’s name or misleading the user about which account is active. This is a data-binding defect, not merely an awkward sentence.
Verification and fix: Preserve resource identifiers and verify variables in realistic test accounts. Do not manufacture names or hard-code a translation sample into the live user interface.
18. A zero count becomes singular
Source situation: The source says ‘No files found’. A target plural template displays ‘1 file found’ when the count is zero because the grammar rule was incorrectly set.
Potential misunderstanding: Count categories vary by language, and the visible state contradicts the data. Users may try to open an item that is not there.
Verification and fix: Use a locale-aware message mechanism and test zero, one, two and other relevant values. Preserve the actual number and whether it represents available, selected or pending records.
19. The error identifies the wrong field
Source situation: A form highlights a missing postal code. Its translated error says ‘Password required’ because two strings share an ambiguous translation-memory entry.
Potential misunderstanding: The user may search the screen for a password input that does not exist and cannot fix the actual missing postal code.
Verification and fix: Review errors with their source field, validation condition and screen location. A good target message names the right field and allows correction without guessing.
20. A status is pending, not approved
Source situation: A scholarship form shows ‘Application received; review pending’. The target says ‘Application approved’.
Potential misunderstanding: The applicant might assume eligibility or funding is guaranteed. This changes a procedural status, not a tone of voice.
Verification and fix: Retain received, under review, approved, rejected and completed as separate controlled terms. Test the outcome displayed at each stage of the application workflow.
21. A right-to-left menu reverses identifiers
Source situation: A target Arabic navigation bar contains Arabic labels alongside a Latin product code, a price and an email address. Manual character reversal causes the code and punctuation to display incorrectly.
Potential misunderstanding: The content may look acceptable in a screenshot but become unusable when copied into a search box or message. Directionality of text and identity of characters are different matters.
Verification and fix: Use proper bidirectional layout support and protect literal identifiers. Copy test IDs from the rendered page and verify they match the original character for character.
22. A breadcrumb loses the parent category
Source situation: The original breadcrumb reads ‘Home > Products > Cameras’. The target translates only Home and Cameras, omitting Products.
Potential misunderstanding: A user may still find the current page, but the route and accessible hierarchy no longer communicate the same structure. This matters on complex sites with similarly named categories.
Verification and fix: Translate each visible level and keep navigation links pointing to the correct destination. Verify keyboard and screen-reader navigation, not only the desktop appearance.
23. A mobile navigation label is clipped
Source situation: The source’s ‘Account settings’ fits in a small tab. The target phrase is longer and truncates to a confusing fragment.
Potential misunderstanding: Deleting half the target text may produce a word that no longer means account settings. The problem is an interface layout constraint, not a need for a less accurate translation.
Verification and fix: Allow responsive wrapping or a validated short form, with accessible full label where appropriate. Test common viewport widths and text zoom before release.
24. Success message appears before the server confirms
Source situation: A file-upload interface shows progress in English and displays ‘Upload complete’ only when the server confirms. The translated version renders that message when uploading starts.
Potential misunderstanding: The target user may navigate away while data is still moving, causing loss or incomplete submission. ‘Started’ and ‘completed’ are separate events.
Verification and fix: Map each translation key to its actual event trigger and ensure the status is shown at the same stage as in the source. Test slow connection and interrupted upload in a safe environment.
25. An accessibility label names a different action
Source situation: On screen, a target-language icon button says ‘Search’; its hidden accessible label remains ‘Delete item’ from a copied component.
Potential misunderstanding: Screen-reader users hear a destructive action while sighted users see a search action. This inconsistency can block navigation or cause serious confusion.
Verification and fix: Translate visible and accessible names as a matched set, using the true component behavior. Test with an assistive-technology review where possible and confirm the control’s action and label agree.
26. A confirmation dialog misstates reversibility
Source situation: The source warns ‘Permanently remove your exported archive; this cannot be undone’. The target says ‘Temporarily hide the archive; you can restore it later’.
Potential misunderstanding: The translated warning understates the consequence and may lead someone to proceed without making a backup. Accuracy is especially important when a task cannot be reversed.
Verification and fix: Retain the exact scope and irreversibility condition. Check the product’s recovery behavior, then read the dialog as someone about to act on its promise. Do not soften safety or loss warnings for comfort.
27. A language switch forgets an unsaved form
Source situation: A user changes the website language midway through completing an application. The switch reloads the page and loses draft responses, but the target switcher suggests it will only change display text.
Potential misunderstanding: This is a product behavior issue revealed during localization, and the visible wording may need to explain it. Translators should not promise that progress is safe when the software does not preserve it.
Verification and fix: Test the switch during a partially completed form. Where the product cannot retain data, the owner should provide accurate warning and a recovery path. Keep that warning equivalent in every supported language.
28. An error code is translated like a sentence
Source situation: Technical support displays ‘Error E1024’ with an explanatory phrase. The localized string changes E1024 to a different-looking alphanumeric code.
Potential misunderstanding: Support staff and documentation search by exact identifiers, and the target code no longer refers to the same problem. A decorative change can make troubleshooting ineffective.
Verification and fix: Preserve error identifiers exactly while translating the explanation in clear language. Verify copy/paste, search results and the error’s real recovery instruction on the target page.
A complete website localization workflow
Inventory every language surface
Collect navigation, buttons, form labels, helper text, validation messages, dialog copy, error codes, success alerts, accessible names, tooltips, pagination, search states and emails that the site generates. Attach context: page, screenshot, underlying action, resource key and what the user should do next. Protect literal codes and variables.
Create a risk-based glossary
Distinguish sign in from sign up, save from publish, archive from delete, request received from approved, and dispatch from delivery. Define target terms consistently where the application states are identical. Do not force the same equivalent for an English word that means different things on different screens.
Translate with screen context
Use natural target-language wording that fits the action, not just a dictionary replacement. Check consent scope, currency and date formatting, validation limits, and the ability to read every instruction on a phone. Raise product-owner questions for inaccurate source copy or unverified guarantees.
Test actions, failures and recovery
A happy-path test is insufficient. Try a wrong password, an invalid email, an empty required field, a failed payment, a restrictive search filter and a destructive confirmation on safe test data. Compare user expectations with actual behavior in the target language. Check that error messages identify problems and explain correct next steps.
Verify accessibility and visual layout
Inspect responsive menus, long labels, text zoom, right-to-left support and mixed numeric or Latin content. Check the relation between visible text and accessible control names. Do not let design constraints silently remove qualifiers or move a warning away from the action it governs.
Release with monitoring and version control
Keep translations tied to software resource IDs and product versions. When the UI changes, retest affected interactions and update the glossary. A new button or option may reuse an English word in a different sense, so continuous context review is necessary for trustworthy localization.
Frequently asked questions
What should I translate first on a website?
Prioritize the user’s main journey: navigation, search, key calls to action, forms, error messages and confirmation states. These strings determine what users can actually accomplish, and their consequences are often clearer than long marketing paragraphs.
Can machine translation handle interface buttons?
It can suggest wording, but short strings lack context. Human and functional review are needed to distinguish actions such as Save, Publish, Submit, Delete and Archive.
Why do placeholders matter in UI translation?
They represent dynamic values such as names, dates and counts. Breaking placeholder syntax or plural rules can produce incorrect messages or software errors. Test realistic inserted values in the target.
Should ‘Delete’ and ‘Archive’ use the same translated word?
No, not if their consequences differ. Users should be able to tell what will disappear, what remains stored and whether recovery is available.
How should error messages be translated?
Keep the identified problem, relevant field and correction instructions. Test the actual invalid-input state and follow W3C accessibility guidance so errors are understandable, not merely visually highlighted.
Can website translation change currencies and dates?
Formatting can be localized, but underlying amounts, dates and time zones must remain accurate. A new currency symbol without conversion changes the apparent offer. Use approved locale data and calculations.
How do I check right-to-left site localization?
Test mixed scripts, links, form fields, prices, exact IDs, focus order and responsive layout in the delivered interface. Do not reverse literal codes or addresses manually.
What is the best final quality test?
Give a target-language user a concrete task, such as creating a draft, correcting an error or cancelling an action. They should anticipate the same consequences and reach the same result as someone using the source language.
Final website translation audit
Before release, verify main navigation, user-account states, calls to action, form controls, validation messages, success and pending states, dates, currencies, variable placeholders, plurals, accessible names, search and filter behavior, responsive layout, consent, payment, destructive actions, recovery conditions and revision history. The localized website should let someone confidently perform the same intended task and understand the same consequences as the source-language visitor.
Good UI translation is invisible in the best sense: people do not need to fight labels or guess what happens next. It turns a website into a reliable tool in another language while keeping its actions, data and promises intact.
Reference reading: W3C: Labeling Controls · W3C: Error Identification · W3C Internationalization · Master Art of Translation · Survey Forms and Answer Choices.