Website and app translation is different from translating a normal document because the words are part of a working interface. A button label has to fit. A variable has to survive. A plural form has to work when the number changes. A date has to make sense in the target locale. A link has to point somewhere useful. A string that looks simple in a spreadsheet may be impossible to translate correctly until you know where it appears on screen and what action the user is trying to take.
Searches for website localization, app localization, software translation, UI translation, localization workflow, translate website professionally, localization QA, translate app interface, placeholders in translation and localization testing all converge on one practical truth: digital translation is not finished when the target sentence is linguistically correct. It is finished when the target language works inside the product.
This guide shows how professional translators and localization teams protect both meaning and interface behaviour. It covers string context, UI conventions, variables and placeholders, plurals, gender, character limits, text expansion, buttons, errors, navigation, dates, numbers, currency, accessibility, links, screenshots, source changes, pseudolocalization, linguistic testing and final in-context review. The goal is to make the localized product feel designed for the target user rather than translated after the fact.
This article sits inside eduKateSG’s Master Art of Translation architecture and builds on the professional workflow established in Translate Like a Pro | Manage a Translation Project from Intake to Delivery.
1. Translate the user action, not the isolated string
A digital string rarely exists for itself. It asks a user to do something, explains what just happened, names a destination, confirms a state or prevents a mistake. The same source word can require different target translations depending on that function. “Save” may be a button that stores changes, a command in a menu, a noun in game software or part of a warning such as “save before closing.”
Before translating short strings, ask where they appear, what happens when the user activates them and what other interface elements surround them. A screenshot, wireframe or product preview can resolve problems that a dictionary cannot. If context is unavailable, the string should carry metadata: screen name, component type, character limit, developer comment and any variable meaning.
The professional habit is simple: treat every UI string as part of an interaction. Linguistic meaning and product behaviour must agree.
2. Separate interface labels from explanatory prose
Websites and apps contain several language systems at once. Navigation labels need scanability. Buttons need action clarity. Form-field labels need precision. Error messages need diagnosis and recovery. Onboarding copy can be warmer. Help articles can use full sentences and examples. Legal notices may require formal exactness. A single global tone rule is rarely enough.
Create style rules by component. A button may prefer a short imperative verb. A menu item may prefer a noun. A confirmation message may use past tense because the action has already happened. An error message should state what went wrong and, where possible, how to recover. When component roles are consistent, users learn the interface faster.
Do not force a beautiful full sentence into a space designed for a two-word label. Equally, do not make explanatory help text read like a sequence of cryptic interface fragments. Digital localization succeeds when language fits the component’s job.
3. Demand context for ambiguous microcopy
The shorter the string, the less linguistic context it contains. “Open”, “Apply”, “Close”, “Order”, “Back”, “Free”, “Address” and “View” can each have several meanings. In ordinary prose the sentence resolves the ambiguity. In a string table, that evidence may be gone.
Use screenshots, source code comments, neighbouring strings, screen names, product behaviour and design prototypes to restore context. If “Apply” appears beside filters, it may mean apply selected filters. If it appears on a job listing, it means submit an application. If it appears beside a voucher field, it may mean apply a code. These are different target actions and should not be forced into one equivalent.
When the same source string represents different actions, developers should ideally create separate resource keys or contextual metadata. Translation memory should not be allowed to erase interface distinctions merely because the source text is identical.
4. Protect placeholders and variables as functional content
Digital strings often contain placeholders such as {name}, %s, {{count}} or numbered tokens. These are not decorative symbols. They are instructions to software about where dynamic information will appear. Changing, deleting or duplicating them can break the interface even if the surrounding translation is perfect.
The translator needs to know what each variable represents. “Welcome, {name}” is easy. “{count} left” is not, because the grammatical form may depend on number and on what is left. A placeholder named {user} may insert a person’s name of unknown gender. A date variable may already arrive formatted or may require locale formatting elsewhere in the software stack.
Preserve required syntax exactly and use automated QA to compare placeholder counts. But do not treat placeholders as frozen word order. Many languages need them in a different position. The engineering system should support grammatical reordering rather than force source-language syntax.
5. Handle plurals with the product’s localization system
English often distinguishes one item from many items with a simple singular/plural pair. Other languages may use more plural categories, and some use grammatical forms that depend on the exact number. A naive string such as “You have {count} message(s)” is already poor English and becomes much worse across languages.
Use the product’s pluralisation framework rather than inventing punctuation hacks. Translators need separate forms according to the target language rules supported by the platform. Developers need to pass the numeric value correctly. Reviewers need to test representative numbers, not only 1 and 2.
Pluralisation is a good example of why localization is a system problem. The translator cannot solve grammar if the software provides only one fixed string, and the developer cannot invent the correct linguistic categories without language knowledge. Product quality appears when both sides meet.
6. Plan for grammatical gender and agreement
Some interfaces insert names, roles, adjectives or status words into sentences that require gender agreement. If the software does not know the user’s gender—or should not assume it—the target language may need a neutral construction. A literal translation of the source template may become impossible or socially inappropriate.
Audit dynamic sentences before production. Ask what values variables can contain and whether those values control surrounding grammar. Where possible, redesign the string so the variable sits in a grammatically stable structure. This often produces better localization than creating a complex set of gendered variants.
The same principle applies to formality and pronouns. A product must decide whether it addresses users formally or informally in languages that mark the distinction. That decision belongs in the style guide, not in each translator’s personal preference.
7. Expect text expansion and contraction
Target text can be longer or shorter than source text. A concise English button can expand significantly in another language. A long English phrase may become compact elsewhere. Fixed-width designs that assume English length often fail during localization.
Character limits should be classified as hard or soft. A hard technical limit—such as an SMS field or database restriction—must be respected. A visual design preference may be better solved by resizing the component rather than forcing awkward abbreviations. Translators need to know the difference so they do not sacrifice clarity unnecessarily.
Design systems should allow flexible width, line wrapping and responsive layouts where possible. Good localization architecture treats text as variable content. If the interface breaks whenever a translation is 30 percent longer, the problem may be the layout rather than the language.
8. Translate buttons around consequences
Buttons should tell users what happens next. Generic labels such as “OK” can be acceptable for simple acknowledgment, but high-impact actions benefit from specific verbs. “Delete account”, “Cancel subscription”, “Send message” or “Save changes” reduce uncertainty because the user can predict the consequence.
When translating, preserve the action distinction. Do not map several different source verbs to one vague target verb simply for consistency. Conversely, if the source uses Save, Submit and Confirm inconsistently for the same action, the localization team may need a product decision rather than three faithful inconsistencies.
Destructive actions deserve special attention. The target wording should not soften deletion into a harmless-sounding continuation or make irreversible action sound temporary. Interface clarity is part of user safety.
9. Write error messages for recovery, not blame
An error message serves two jobs: explain enough of the problem and help the user recover. “Invalid input” may be technically true but operationally weak. “Enter a date after 18 September” tells the user what to change. Localization should preserve that recovery path.
Avoid adding blame that the source does not contain. Some languages make direct statements sound harsher when translated literally. Prefer neutral descriptions of the state where appropriate: “The password does not meet the requirements” rather than language that sounds like an accusation.
Keep technical error codes unchanged when they are used for support or debugging, but translate the human explanation around them. If support documentation references an exact code or English label, verify whether localized versions need cross-language searchability.
10. Localize navigation as an information system
Navigation labels help users build a mental map of the product. They should be short, distinctive and consistent across pages. A translation that is semantically accurate but too broad can make different destinations sound identical. A clever synonym may reduce recognition if users already expect a standard local term.
Translate navigation in sets rather than one label at a time. Compare sibling items side by side. Ask whether the categories remain parallel and whether one translated label accidentally contains another’s meaning. Test breadcrumbs, menus, tabs and page titles together.
Search behaviour also matters. If the website’s internal search indexes target-language terms, navigation and content terminology should align with what users are likely to search. Localization is partly an information-retrieval problem.
11. Localize dates, times, numbers and currency deliberately
Digital products often generate dates and numbers automatically, which means translators may never see the final values until testing. Confirm who owns locale formatting: translation files, application code, internationalisation library or server. Do not duplicate responsibility across layers.
Date order can create serious confusion. Time formats can vary between 12-hour and 24-hour conventions. Decimal and thousands separators vary. Currency symbols may appear before or after numbers and can be ambiguous without currency codes. Measurement units may be retained, converted or dual-displayed according to product policy.
Test realistic data. A date component that works for 8 May may overflow on 18 September. A price with two digits may fit where a four-digit price does not. Localization QA should use edge cases, not only ideal examples.
12. Treat links as localized content
A target-language sentence can be correct while its link sends the user to a source-language page. That may be acceptable if no localized destination exists, but it should be intentional. Where equivalent target pages exist, link mapping belongs in localization scope.
Anchor text also needs review. “Click here” gives little information and can be weak for accessibility. Descriptive link text should remain descriptive after translation. If legal or support documents are linked by exact title, verify that the localized title matches the actual destination.
After import, click representative links. Broken URLs, language mismatches and redirected paths are not visible in the translation string itself.
13. Localize metadata and invisible text
Websites contain language that users may not see directly: page titles, meta descriptions, image alt text, form accessibility labels, ARIA labels, structured data, email subject templates, notification previews and social-sharing text. Leaving these in the source language creates a fragmented experience and can damage accessibility or search presentation.
Not every metadata field should be translated identically to visible copy. A page title may need concise search language. Alt text should describe the image’s functional content, not mechanically copy a caption. Accessibility labels should clarify controls for assistive technology.
Inventory hidden strings during intake. If they are discovered only after launch, they often become the forgotten tail of localization.
14. Protect accessibility during translation
Accessibility is not language-neutral. A screen-reader label that works in the source can become vague after translation. Instructions that rely on colour, shape or left/right position may not suit every layout or writing direction. Acronyms that are pronounced one way in the source may be read letter by letter or as nonsense in the target.
Keep control labels meaningful without visual context. Preserve heading hierarchy and list structure. Do not remove explanatory text because it looks repetitive if that text supports assistive technology. For languages with different reading directions, verify component order and punctuation visually.
Localization should make the same task reachable, not merely render the same strings in another language.
15. Use developer comments and screenshots as translation infrastructure
High-quality source strings include context. A developer comment can say “Button that submits a job application” or “Noun: saved document, not verb.” A screenshot can show whether a string is a heading, error, tooltip or navigation item. These small additions reduce translator queries dramatically.
If the product lacks contextual metadata, the localization process should create it for recurring ambiguous strings. Do not accept a permanent workflow in which every translator repeatedly asks what “Open” means. Each resolved question is an opportunity to improve the source resource.
Context should travel with the string through the localization platform so it is available to future translators and reviewers, not stored only in a one-time chat.
16. Use pseudolocalization to expose engineering problems early
Pseudolocalization replaces normal source strings with transformed text that expands length, adds accented characters or simulates another writing direction while preserving the software’s mechanics. It is not a real translation. It is a stress test for whether the product can survive localization.
This can reveal hard-coded strings, clipping, font problems, broken placeholders, concatenated text, unsupported characters and layouts that assume source-language length. Finding those issues before real translation begins is cheaper than discovering them across ten languages after launch.
The professional lesson is broader: localization quality depends on product internationalisation. Translators should not be expected to compensate forever for software architecture that was designed for only one language.
17. Avoid concatenated sentences
Developers sometimes build sentences from fragments: “You have” + number + “new messages.” This appears efficient in English but creates grammar problems elsewhere because word order, plural form or case may depend on the whole sentence. Translators cannot safely rearrange pieces they never receive together.
Whenever possible, expose complete translatable messages with placeholders inside them. Let each language control word order. If several variants are needed, define them through plural or grammatical rules rather than fragment assembly.
Concatenation is a classic example of a technical shortcut creating permanent localization cost. Fixing the source architecture often improves every language at once.
18. Test the translation inside the product
Bilingual review in a localization platform cannot reveal every interface problem. In-context linguistic testing should examine real screens or a staging environment. Reviewers should look for truncation, wrong line breaks, incorrect component assignment, duplicated text, untranslated strings, broken links, inconsistent terminology, awkward variables and language that no longer matches the action.
Test user journeys rather than isolated screens. Create an account, recover a password, change a setting, buy an item, cancel an action or submit a form. A string can be correct in isolation and wrong in sequence—for example, a confirmation message may use future tense even though the action already happened.
Where feasible, test on representative devices and viewport sizes. Desktop success does not guarantee mobile success.
19. Manage source-string changes carefully
Software text changes frequently. A developer may alter punctuation, replace one word or rewrite the entire meaning. Localization systems often mark changed strings for review, but translators need to understand the scale of change. A minor source edit may not require a new translation; a one-word change such as adding “not” absolutely does.
Do not rely only on match percentage. Compare old and new meaning. If a source change affects terminology or user flow, search related strings too. Product updates should trigger targeted regression testing where the language is most likely to break.
Keep source and translation histories clean so future releases can distinguish approved reuse from outdated legacy text.
20. Localize for search without turning every string into SEO copy
Public websites have a search-discovery layer that apps may not. Page titles, headings, explanatory articles and meta descriptions can benefit from target-language search phrasing. But interface buttons and legal text should not be distorted to insert keywords. Search intent belongs where users naturally search and read, not everywhere words appear.
Research how the target audience names the concept. A literal term may be technically accurate while users search for a different established phrase. Align public information architecture, headings and explanatory copy with target-language usage while preserving conceptual precision.
SEO localization is therefore a language-and-intent task, not a keyword replacement task. The localized page should answer the target user’s question in the target user’s vocabulary.
A professional website and app localization workflow
- Inventory all visible and hidden translatable content.
- Confirm target locales, product purpose and user groups.
- Collect screenshots, developer comments and component metadata.
- Identify placeholders, tags, plural rules and technical constraints.
- Build UI terminology and component-level style conventions.
- Translate representative screens before scaling production.
- Resolve ambiguous strings and improve source context.
- Run placeholder, number, terminology and tag QA.
- Import the translation into staging.
- Perform in-context linguistic testing across user journeys.
- Check layout, links, accessibility and hidden metadata.
- Fix defects in both target text and source architecture where appropriate.
- Regression-test changed areas before release.
- Preserve validated strings and context for the next version.
Eight localization failure cases
1. “Apply” is translated the same way everywhere
One screen applies a coupon, another applies a filter, and another lets a user apply for a role. The source string is identical but the user actions differ. The fix is contextual translation and, ideally, separate resource keys or metadata.
2. A placeholder disappears
The source says “Hello, {name}” and the translated string omits the token. The page now greets everyone with the same static sentence. Automated placeholder comparison should catch this before release.
3. A translated button no longer fits
The target term is accurate but twice as long. Do not immediately abbreviate it into obscurity. Check whether the button can expand, whether a standard shorter UI term exists and whether the supposed character limit is technical or merely visual preference.
4. A plural rule handles 1 and 2 but fails at 5
The localization system was configured using an English assumption. Test the full plural categories required by the target language. This is an internationalisation defect as much as a translation defect.
5. A payment page shows the wrong decimal convention
The currency symbol is correct, but number formatting follows the source locale. Because users interpret money quickly and visually, locale formatting should be handled by the appropriate internationalisation layer and tested with realistic values.
6. The help link opens the source language
The interface looks localized until the user needs support. Maintain locale-aware link mapping and test critical journeys. Translation quality includes where the user lands next.
7. A screen reader gets an untranslated label
The visible icon looks fine, but its accessibility label remains in the source language. Hidden interface text belongs in localization scope. Accessibility QA must include the semantic layer that sighted users do not see.
8. A confirmation message describes the wrong state
The source wording changed from “will be deleted” to “has been deleted”, but a high translation-memory match reused the old target. In-context journey testing catches temporal and state errors that isolated string review can miss.
Localization QA checklist
- Every visible string has context.
- Buttons describe the correct action.
- Navigation labels are parallel and distinct.
- Placeholders and tags are preserved exactly.
- Plural and gender logic works for representative values.
- Text expansion does not break layout.
- Dates, time, numbers, currency and units follow locale policy.
- Links resolve to appropriate target-language destinations.
- Alt text, accessibility labels and metadata are localized.
- Errors explain the problem and recovery path.
- No source-language strings remain unintentionally.
- Mobile and desktop layouts have been reviewed.
- Changed strings receive regression testing.
- Final target language sounds natural inside real user journeys.
Frequently asked questions
What is the difference between translation and localization?
Translation moves meaning between languages. Localization adapts the broader product experience for a target locale, which can include dates, numbers, currency, units, interface conventions, links, layout, cultural references and technical behaviour. Localization contains translation but extends beyond it.
Do translators need to know code?
They do not need to be software engineers, but professional digital translators benefit from understanding placeholders, tags, resource keys, plural rules, variables and common file constraints. That knowledge prevents accidental breakage and improves communication with developers.
What is the most dangerous type of UI string?
Short ambiguous strings are surprisingly risky because they contain little context, while destructive actions and high-stakes confirmations carry greater consequences. Both deserve strong contextual metadata.
Should every string have a character limit?
No. Limits should reflect real constraints. Arbitrary limits can force poor language. Flexible interface design is usually preferable, while genuine technical or component limits should be visible to translators.
Can machine translation be used for app localization?
It can help with suitable content, but output still needs context, terminology control, placeholder safety and in-product testing. Machine systems are especially vulnerable when isolated short strings have multiple meanings.
What is pseudolocalization for?
It tests whether the software architecture and layout are ready for other languages before real translation is complete. It can expose hard-coded text, clipping, character-set problems and broken variables early.
Why do strings need screenshots?
Screenshots reveal component role, neighbouring text, visual hierarchy and user action. They can turn a one-word ambiguous string into an obvious translation decision.
When is website localization complete?
When the target language is linguistically sound, all intended content is localized, technical elements remain functional, links and metadata work, and representative users can complete important journeys without language-specific defects.
The larger lesson: localize the product, not the spreadsheet
The deepest mistake in digital translation is believing that the string table is the product. It is only a representation of the product’s language. Real meaning appears when a user sees a label beside a field, taps a button, receives an error, reads a price, follows a link or hears a screen reader announce a control.
Professional localization therefore moves back and forth between language and interface. Translators need context from product design. Developers need linguistic requirements from translators. Reviewers need staging environments. Product teams need source strings written for reuse across languages. When those pieces connect, localization stops being a late export task and becomes part of product quality.
Continue with Translate Like a Pro | Build and Use a Translation Style Guide and the wider Master Art of Translation.