To translate websites, apps and interface text into any language, the target must do more than sound natural. It must still work. People searching for website translation, app translation, UI translation, translate a webpage, translate interface text or localisation often discover that short strings are surprisingly difficult because buttons, menus, forms, placeholders, error messages and tooltips have functions that are partly visible in the interface rather than in the words alone.
Word-for-word translation can break user experience even when each word is technically correct. A button can become too long. A label can stop matching the field below it. An error message can lose the action the user must take. A placeholder such as {name} or %s can be moved, deleted or grammatically trapped. Accurate interface translation therefore requires context, component function, terminology consistency and testing inside the actual layout.
This guide develops a practical method for translating websites and apps without breaking meaning or usability. It covers navigation, buttons, menus, forms, validation messages, variables, placeholders, product terminology, character expansion, responsive layouts, accessibility, SEO-facing text, AI and machine translation, pseudo-localisation, quality assurance and the boundary between translation and full localisation.
The Translation Problem This Guide Solves
Interface text is compressed language. A one-word button may represent a complex action, and a short label may depend on an icon, field or screen state. Translators who see strings without context are being asked to solve an incomplete problem.
The first requirement is functional context. Know where the string appears, what action it triggers, what appears before and after it, and whether it is a noun, command, status or explanation.
The second requirement is consistency. Users learn interfaces through repeated terminology. If the same feature is called by three different target words across screens, the translation may be linguistically rich but operationally confusing.
The Core Method
Translate the interface function first, then fit natural target language inside the component’s technical and spatial constraints.
The method in this guide is deliberately operational. It treats websites, apps and interface text as a sequence of translation decisions rather than a vocabulary-replacement exercise. The source language supplies meaning, relationships, tone and constraints; the target language supplies a new linguistic form. The translator’s job is to keep the important invariants stable while allowing wording, syntax and surface structure to change when the target language requires it.
- 1. Buttons and Action Labels: translate what clicking does
- 2. Navigation and Information Architecture: keep labels aligned with destinations
- 3. Forms and Field Labels: preserve administrative meaning
- 4. Error and Validation Messages: tell users what failed and what to do next
- 5. Variables and Placeholders: protect dynamic tokens while allowing grammar to change
- 6. Character Expansion and Layout: plan for target text that is longer or shorter
- 7. Terminology and Feature Names: keep product vocabulary stable
- 8. Accessibility Text: translate meaning that may be invisible on screen
- 9. SEO and Public Page Text: preserve user meaning while matching target search language
- 10. Context Screenshots and String Metadata: give translators enough evidence to choose correctly
1. Buttons and Action Labels
A common failure point is choosing a dictionary equivalent without knowing the resulting action. This is easy to miss because a translation can remain fluent even after the underlying communicative job has changed. In websites, apps and interface text, the error matters because readers or listeners act on the target in real time. The first diagnostic question is therefore not “Which word matches?” but “What information or function must survive this part of the source?”
The mechanism is identifying the action state—save, submit, continue, cancel, retry, delete, share—before choosing conventional target UI wording. A careful translator identifies the source-language signal, states its plain function, and then asks how the target language normally performs that same function. This keeps the work anchored to meaning while still allowing natural target-language grammar. It also prevents word-for-word translation from dictating sentence shape before the translator understands the job.
Worked example: A button labelled “Done” after editing may mean save-and-exit rather than simply “finished.” The useful lesson is not the particular wording of one language pair. It is the reasoning path: isolate the communicative constraint, test possible target forms against that constraint, and reject any candidate that sounds smooth but weakens, strengthens, omits or invents information.
A reliable check is to ask what happens immediately after the user activates the control. This turns review into an observable test rather than a vague feeling. If the target fails, return to the source and ask whether the problem began with comprehension, reference, terminology, tone or target-language naturalness. Repair the earliest broken layer instead of polishing around it.
The skill transfers beyond this example. The method applies to menus, mobile gestures and voice-interface commands. When learners practise the transfer deliberately, they begin to recognise the same underlying problem in new language pairs, new genres and new tools. That is how translation becomes a reusable reasoning system rather than a collection of memorised equivalents.
2. Navigation and Information Architecture
A common failure point is translating menu items attractively but inconsistently with page headings and user expectations. This is easy to miss because a translation can remain fluent even after the underlying communicative job has changed. In websites, apps and interface text, the error matters because readers or listeners act on the target in real time. The first diagnostic question is therefore not “Which word matches?” but “What information or function must survive this part of the source?”
The mechanism is mapping each navigation label to its destination and using stable target terminology across menus, breadcrumbs and headings. A careful translator identifies the source-language signal, states its plain function, and then asks how the target language normally performs that same function. This keeps the work anchored to meaning while still allowing natural target-language grammar. It also prevents word-for-word translation from dictating sentence shape before the translator understands the job.
Worked example: “Account,” “Profile” and “Settings” may be separate destinations and should not collapse into one generic word. The useful lesson is not the particular wording of one language pair. It is the reasoning path: isolate the communicative constraint, test possible target forms against that constraint, and reject any candidate that sounds smooth but weakens, strengthens, omits or invents information.
A reliable check is to click through the target interface and confirm that each label predicts the destination. This turns review into an observable test rather than a vague feeling. If the target fails, return to the source and ask whether the problem began with comprehension, reference, terminology, tone or target-language naturalness. Repair the earliest broken layer instead of polishing around it.
The skill transfers beyond this example. This supports websites, dashboards, learning platforms and e-commerce systems. When learners practise the transfer deliberately, they begin to recognise the same underlying problem in new language pairs, new genres and new tools. That is how translation becomes a reusable reasoning system rather than a collection of memorised equivalents.
3. Forms and Field Labels
A common failure point is treating similar labels such as surname, given name, nationality and residence as interchangeable. This is easy to miss because a translation can remain fluent even after the underlying communicative job has changed. In websites, apps and interface text, the error matters because readers or listeners act on the target in real time. The first diagnostic question is therefore not “Which word matches?” but “What information or function must survive this part of the source?”
The mechanism is identifying the data concept behind each field and using the target culture’s clearest equivalent without changing the stored meaning. A careful translator identifies the source-language signal, states its plain function, and then asks how the target language normally performs that same function. This keeps the work anchored to meaning while still allowing natural target-language grammar. It also prevents word-for-word translation from dictating sentence shape before the translator understands the job.
Worked example: A field asking for “country of residence” should not become “nationality” simply because the latter is more familiar. The useful lesson is not the particular wording of one language pair. It is the reasoning path: isolate the communicative constraint, test possible target forms against that constraint, and reject any candidate that sounds smooth but weakens, strengthens, omits or invents information.
A reliable check is to compare the target label with the data the backend expects. This turns review into an observable test rather than a vague feeling. If the target fails, return to the source and ask whether the problem began with comprehension, reference, terminology, tone or target-language naturalness. Repair the earliest broken layer instead of polishing around it.
The skill transfers beyond this example. The same principle protects surveys, registrations and application forms. When learners practise the transfer deliberately, they begin to recognise the same underlying problem in new language pairs, new genres and new tools. That is how translation becomes a reusable reasoning system rather than a collection of memorised equivalents.
4. Error and Validation Messages
A common failure point is translating errors as technical descriptions that provide no recovery path. This is easy to miss because a translation can remain fluent even after the underlying communicative job has changed. In websites, apps and interface text, the error matters because readers or listeners act on the target in real time. The first diagnostic question is therefore not “Which word matches?” but “What information or function must survive this part of the source?”
The mechanism is preserving the problem, cause when known, and next action while maintaining the source’s certainty. A careful translator identifies the source-language signal, states its plain function, and then asks how the target language normally performs that same function. This keeps the work anchored to meaning while still allowing natural target-language grammar. It also prevents word-for-word translation from dictating sentence shape before the translator understands the job.
Worked example: “Password must contain at least 12 characters” should retain the minimum requirement exactly. The useful lesson is not the particular wording of one language pair. It is the reasoning path: isolate the communicative constraint, test possible target forms against that constraint, and reject any candidate that sounds smooth but weakens, strengthens, omits or invents information.
A reliable check is to ask whether a target reader can repair the problem from the message alone. This turns review into an observable test rather than a vague feeling. If the target fails, return to the source and ask whether the problem began with comprehension, reference, terminology, tone or target-language naturalness. Repair the earliest broken layer instead of polishing around it.
The skill transfers beyond this example. This applies to payment errors, upload failures and login validation. When learners practise the transfer deliberately, they begin to recognise the same underlying problem in new language pairs, new genres and new tools. That is how translation becomes a reusable reasoning system rather than a collection of memorised equivalents.
5. Variables and Placeholders
A common failure point is deleting, translating or trapping placeholders inside target grammar. This is easy to miss because a translation can remain fluent even after the underlying communicative job has changed. In websites, apps and interface text, the error matters because readers or listeners act on the target in real time. The first diagnostic question is therefore not “Which word matches?” but “What information or function must survive this part of the source?”
The mechanism is treating tokens such as {name}, {count}, %s or {{date}} as fixed data slots whose position may change but identity must not. A careful translator identifies the source-language signal, states its plain function, and then asks how the target language normally performs that same function. This keeps the work anchored to meaning while still allowing natural target-language grammar. It also prevents word-for-word translation from dictating sentence shape before the translator understands the job.
Worked example: “Welcome, {name}” may require different punctuation or word order, but {name} must survive intact. The useful lesson is not the particular wording of one language pair. It is the reasoning path: isolate the communicative constraint, test possible target forms against that constraint, and reject any candidate that sounds smooth but weakens, strengthens, omits or invents information.
A reliable check is to run the string with sample values and inspect every grammatical form. This turns review into an observable test rather than a vague feeling. If the target fails, return to the source and ask whether the problem began with comprehension, reference, terminology, tone or target-language naturalness. Repair the earliest broken layer instead of polishing around it.
The skill transfers beyond this example. This principle is critical in notifications, transactional email and software localisation. When learners practise the transfer deliberately, they begin to recognise the same underlying problem in new language pairs, new genres and new tools. That is how translation becomes a reusable reasoning system rather than a collection of memorised equivalents.
6. Character Expansion and Layout
A common failure point is forcing meaning into the source character count even when the target naturally expands. This is easy to miss because a translation can remain fluent even after the underlying communicative job has changed. In websites, apps and interface text, the error matters because readers or listeners act on the target in real time. The first diagnostic question is therefore not “Which word matches?” but “What information or function must survive this part of the source?”
The mechanism is prioritising concise conventional wording and testing the real component at narrow screen widths. A careful translator identifies the source-language signal, states its plain function, and then asks how the target language normally performs that same function. This keeps the work anchored to meaning while still allowing natural target-language grammar. It also prevents word-for-word translation from dictating sentence shape before the translator understands the job.
Worked example: A short English menu label may require a longer phrase in German or Spanish; truncation can remove distinguishing information. The useful lesson is not the particular wording of one language pair. It is the reasoning path: isolate the communicative constraint, test possible target forms against that constraint, and reject any candidate that sounds smooth but weakens, strengthens, omits or invents information.
A reliable check is to test buttons, tabs and labels on the smallest supported layout. This turns review into an observable test rather than a vague feeling. If the target fails, return to the source and ask whether the problem began with comprehension, reference, terminology, tone or target-language naturalness. Repair the earliest broken layer instead of polishing around it.
The skill transfers beyond this example. This applies to mobile apps, watches, kiosks and embedded devices. When learners practise the transfer deliberately, they begin to recognise the same underlying problem in new language pairs, new genres and new tools. That is how translation becomes a reusable reasoning system rather than a collection of memorised equivalents.
7. Terminology and Feature Names
A common failure point is allowing AI or multiple translators to vary important feature names for style. This is easy to miss because a translation can remain fluent even after the underlying communicative job has changed. In websites, apps and interface text, the error matters because readers or listeners act on the target in real time. The first diagnostic question is therefore not “Which word matches?” but “What information or function must survive this part of the source?”
The mechanism is maintaining an approved glossary that distinguishes fixed product names from translatable descriptive text. A careful translator identifies the source-language signal, states its plain function, and then asks how the target language normally performs that same function. This keeps the work anchored to meaning while still allowing natural target-language grammar. It also prevents word-for-word translation from dictating sentence shape before the translator understands the job.
Worked example: If a platform feature has an official target-language name, every screen should use that form. The useful lesson is not the particular wording of one language pair. It is the reasoning path: isolate the communicative constraint, test possible target forms against that constraint, and reject any candidate that sounds smooth but weakens, strengthens, omits or invents information.
A reliable check is to search the target build for variants of each protected term. This turns review into an observable test rather than a vague feeling. If the target fails, return to the source and ask whether the problem began with comprehension, reference, terminology, tone or target-language naturalness. Repair the earliest broken layer instead of polishing around it.
The skill transfers beyond this example. Glossary discipline also improves manuals, help centres and release notes. When learners practise the transfer deliberately, they begin to recognise the same underlying problem in new language pairs, new genres and new tools. That is how translation becomes a reusable reasoning system rather than a collection of memorised equivalents.
8. Accessibility Text
A common failure point is ignoring alt text, aria labels or screen-reader-only instructions because they are not visually prominent. This is easy to miss because a translation can remain fluent even after the underlying communicative job has changed. In websites, apps and interface text, the error matters because readers or listeners act on the target in real time. The first diagnostic question is therefore not “Which word matches?” but “What information or function must survive this part of the source?”
The mechanism is treating accessibility strings as functional content that must identify purpose, state or image meaning for assistive technology. A careful translator identifies the source-language signal, states its plain function, and then asks how the target language normally performs that same function. This keeps the work anchored to meaning while still allowing natural target-language grammar. It also prevents word-for-word translation from dictating sentence shape before the translator understands the job.
Worked example: An icon-only close button needs an accessible target label equivalent to “Close dialog.” The useful lesson is not the particular wording of one language pair. It is the reasoning path: isolate the communicative constraint, test possible target forms against that constraint, and reject any candidate that sounds smooth but weakens, strengthens, omits or invents information.
A reliable check is to navigate the target interface with screen-reader output or accessibility inspection tools. This turns review into an observable test rather than a vague feeling. If the target fails, return to the source and ask whether the problem began with comprehension, reference, terminology, tone or target-language naturalness. Repair the earliest broken layer instead of polishing around it.
The skill transfers beyond this example. This extends to captions, form hints and keyboard guidance. When learners practise the transfer deliberately, they begin to recognise the same underlying problem in new language pairs, new genres and new tools. That is how translation becomes a reusable reasoning system rather than a collection of memorised equivalents.
9. SEO and Public Page Text
A common failure point is copying source keywords mechanically even when target users search differently. This is easy to miss because a translation can remain fluent even after the underlying communicative job has changed. In websites, apps and interface text, the error matters because readers or listeners act on the target in real time. The first diagnostic question is therefore not “Which word matches?” but “What information or function must survive this part of the source?”
The mechanism is translating the page for meaning first and then validating natural target query language without distorting claims. A careful translator identifies the source-language signal, states its plain function, and then asks how the target language normally performs that same function. This keeps the work anchored to meaning while still allowing natural target-language grammar. It also prevents word-for-word translation from dictating sentence shape before the translator understands the job.
Worked example: A literal keyword may be linguistically correct but rarely used by target searchers. The useful lesson is not the particular wording of one language pair. It is the reasoning path: isolate the communicative constraint, test possible target forms against that constraint, and reject any candidate that sounds smooth but weakens, strengthens, omits or invents information.
A reliable check is to compare target phrasing with real target-language usage and the page’s actual content. This turns review into an observable test rather than a vague feeling. If the target fails, return to the source and ask whether the problem began with comprehension, reference, terminology, tone or target-language naturalness. Repair the earliest broken layer instead of polishing around it.
The skill transfers beyond this example. This supports multilingual landing pages, product pages and help articles. When learners practise the transfer deliberately, they begin to recognise the same underlying problem in new language pairs, new genres and new tools. That is how translation becomes a reusable reasoning system rather than a collection of memorised equivalents.
10. Context Screenshots and String Metadata
A common failure point is sending isolated interface strings without location, state or component type. This is easy to miss because a translation can remain fluent even after the underlying communicative job has changed. In websites, apps and interface text, the error matters because readers or listeners act on the target in real time. The first diagnostic question is therefore not “Which word matches?” but “What information or function must survive this part of the source?”
The mechanism is providing screenshots, character limits, developer comments and example values alongside the source string. A careful translator identifies the source-language signal, states its plain function, and then asks how the target language normally performs that same function. This keeps the work anchored to meaning while still allowing natural target-language grammar. It also prevents word-for-word translation from dictating sentence shape before the translator understands the job.
Worked example: “Open” can be a verb command, adjective status or noun-like state; the component decides the translation. The useful lesson is not the particular wording of one language pair. It is the reasoning path: isolate the communicative constraint, test possible target forms against that constraint, and reject any candidate that sounds smooth but weakens, strengthens, omits or invents information.
A reliable check is to ask whether the translator can explain where the string appears and what it does. This turns review into an observable test rather than a vague feeling. If the target fails, return to the source and ask whether the problem began with comprehension, reference, terminology, tone or target-language naturalness. Repair the earliest broken layer instead of polishing around it.
The skill transfers beyond this example. Better context improves both human and AI translation workflows. When learners practise the transfer deliberately, they begin to recognise the same underlying problem in new language pairs, new genres and new tools. That is how translation becomes a reusable reasoning system rather than a collection of memorised equivalents.
Worked Example Laboratory
Example 1: A Destructive Button
A settings screen contains a button labelled “Remove account.” Before translating, identify the source-language action, the information that cannot change, and the parts that may be restructured. The action is destructive and may mean disconnecting locally or permanently deleting data; context must decide.
Use the target term that matches the actual backend action and preserve warning strength. The target wording can vary by language, but the acceptance test stays stable: the translated reader should recover the same practical meaning, tone and constraints without needing access to the source.
Example 2: A Dynamic Notification
“{name} shared {count} files with you.” Before translating, identify the source-language action, the information that cannot change, and the parts that may be restructured. Two placeholders carry dynamic data and target grammar may require a different order.
Reorder the sentence naturally while preserving both tokens and testing singular/plural behaviour where the system supports it. The target wording can vary by language, but the acceptance test stays stable: the translated reader should recover the same practical meaning, tone and constraints without needing access to the source.
Example 3: A Form Error
“Enter a valid date in DD/MM/YYYY format.” Before translating, identify the source-language action, the information that cannot change, and the parts that may be restructured. The message combines validation, required action and a format constraint.
Translate the instruction but preserve the exact accepted format unless the product itself localises date input. The target wording can vary by language, but the acceptance test stays stable: the translated reader should recover the same practical meaning, tone and constraints without needing access to the source.
Example 4: A Navigation Label
A menu item says “Billing.” Before translating, identify the source-language action, the information that cannot change, and the parts that may be restructured. The destination may include invoices, subscriptions and payment methods.
Choose the target navigation term that best predicts that destination rather than translating the dictionary noun in isolation. The target wording can vary by language, but the acceptance test stays stable: the translated reader should recover the same practical meaning, tone and constraints without needing access to the source.
Practice and Checking
Practice 1: Screenshot Context Drill
Translate ten UI strings first without screenshots and then with screenshots. Do the task once without AI or machine translation so that your own interpretation is visible. Then compare with a tool-generated version if useful. Mark every difference that changes meaning, certainty, tone, reference, terminology or usability.
Identify every translation that changed once component function became visible. Keep a short note of the error type rather than only the corrected answer. Repeated error types reveal what to practise next: source comprehension, context recovery, vocabulary sense selection, register, target grammar, collocation or quality assurance.
Practice 2: Placeholder Integrity
Translate a set of dynamic strings containing names, counts and dates. Do the task once without AI or machine translation so that your own interpretation is visible. Then compare with a tool-generated version if useful. Mark every difference that changes meaning, certainty, tone, reference, terminology or usability.
Substitute sample values and verify that no placeholder was lost, duplicated or made ungrammatical. Keep a short note of the error type rather than only the corrected answer. Repeated error types reveal what to practise next: source comprehension, context recovery, vocabulary sense selection, register, target grammar, collocation or quality assurance.
Practice 3: Character-Expansion Test
Place target strings inside the narrowest supported button or tab layout. Do the task once without AI or machine translation so that your own interpretation is visible. Then compare with a tool-generated version if useful. Mark every difference that changes meaning, certainty, tone, reference, terminology or usability.
Shorten only by removing redundancy, never by dropping required meaning. Keep a short note of the error type rather than only the corrected answer. Repeated error types reveal what to practise next: source comprehension, context recovery, vocabulary sense selection, register, target grammar, collocation or quality assurance.
Practice 4: Terminology Audit
Create a five-term product glossary and search the target interface for inconsistent variants. Do the task once without AI or machine translation so that your own interpretation is visible. Then compare with a tool-generated version if useful. Mark every difference that changes meaning, certainty, tone, reference, terminology or usability.
Distinguish legitimate grammatical inflection from true naming inconsistency. Keep a short note of the error type rather than only the corrected answer. Repeated error types reveal what to practise next: source comprehension, context recovery, vocabulary sense selection, register, target grammar, collocation or quality assurance.
Practice 5: Usability Walkthrough
Complete one full task in the translated interface, such as creating an account or submitting a form. Do the task once without AI or machine translation so that your own interpretation is visible. Then compare with a tool-generated version if useful. Mark every difference that changes meaning, certainty, tone, reference, terminology or usability.
Record every point where the target wording makes the next action less predictable. Keep a short note of the error type rather than only the corrected answer. Repeated error types reveal what to practise next: source comprehension, context recovery, vocabulary sense selection, register, target grammar, collocation or quality assurance.
Independent-Use Workflow
- Read or inspect the complete source before translating.
- Define audience, purpose, target language and required register.
- Mark names, numbers, terminology, conditions, negation and ambiguity.
- State difficult source meaning in plain language.
- Draft the target in natural chunks rather than copying source order.
- Compare source and target for omissions, additions and changed force.
- Read the target alone for grammar, collocation and usability.
- Run a final factual and structural check before sending or publishing.
This workflow is intentionally compatible with manual translation, bilingual dictionaries, specialised terminology resources, machine translation and generative AI. Tools can accelerate individual stages, but they do not change what must be checked. The source still determines meaning; the target still needs to function naturally; and the final user still needs the same practical information.
For independent use, build a small decision log. Record recurring terms, accepted target forms, difficult cases and the reason a solution was chosen. Over time this becomes a personal translation memory. It reduces repeated uncertainty and helps you notice when a familiar-looking phrase is being used in a new way.
AI and Machine Translation
AI and machine translation can be excellent first-draft systems for websites, apps and interface text, especially when the source is clear and the language pair is well supported. The safest use is human-in-the-loop: provide enough context, specify audience and register, preserve critical terms, and ask the system to flag ambiguity rather than invent certainty. A fluent output should be treated as a candidate, not as proof of accuracy.
When a tool struggles, separate the problem into stages. First ask what the source means. Then ask for two or three target alternatives. Finally compare those alternatives for tone, precision and naturalness. This is often more reliable than repeatedly requesting “a better translation,” because the model is forced to expose the decision it is making.
Transfer to Other Language Pairs
The examples in this guide are language-neutral by design. English may express one relationship with word order while another language uses particles, morphology or context. A good method therefore preserves functions rather than grammatical shapes. If a target language requires information that the source leaves implicit, use context carefully and avoid inventing unsupported detail.
Translation quality also depends on the direction of translation. When translating into your strongest language, the danger is over-editing: natural writing can become freer than the source. When translating into a language you are still learning, the danger is false confidence in unfamiliar vocabulary or syntax. In both directions, source-target comparison is the control mechanism.
Useful Internal Routing
For the general reasoning system behind this article, use Translate Easily to any Language | The Universal Five-Layer Translation Method. It explains how meaning, relationships, context, tone and natural reconstruction fit together.
For tool-assisted work, use How to Use AI and Machine Translation Without Losing Control. For final review, use How to Check Translation Accuracy Before You Send, Submit or Publish. For vocabulary depth, collocation and sense selection, continue through the eduKateSG Vocabulary Learning Hub.
Frequently Asked Questions
What is the difference between translation and localisation?
Translation moves language meaning into the target language. Localisation also adapts conventions such as date formats, currency display, layout, legal requirements, cultural references and sometimes product behaviour.
Should button text be translated literally?
Usually no. Translate the action the button performs using established target-language interface conventions, while preserving any important distinction between similar actions.
How do I translate placeholders safely?
Keep the token itself unchanged, move it only when target grammar requires it, and test with realistic sample values. Never translate variable names unless the software explicitly supports that.
Can AI translate an app interface?
Yes, especially with screenshots, glossary and string metadata. Isolated strings remain risky because the model may guess the wrong component function.
How do I handle text that becomes too long?
First choose the most concise natural target expression. If the interface still breaks, adjust layout or component design rather than deleting necessary meaning.
Do translated websites need different SEO wording?
Often. Translate meaning first, then validate how target-language users naturally search for the topic. Do not force source keywords that sound unnatural or misrepresent the page.
The Rule to Keep
Interface translation is successful when users can act without noticing the translation as an obstacle. Preserve component function, terminology, dynamic tokens, structure and user expectations, then let the target language be concise and natural inside those constraints.
A translated interface is not finished when the words are correct; it is finished when the product still works in the reader’s language.