SOFTWARE LOCALIZATION
What makes software localization different?
Software localization is more than translating a list of interface strings. The linguist needs to understand where the text appears, what the user is doing and which technical elements must remain unchanged.
Short labels, buttons and messages can be harder to translate than long paragraphs because a few words may have several possible meanings when they are shown without context.
What is software localization?
Software localization is the process of adapting software content for users in another language or market.
It includes translation, but the translated text also needs to work inside the product. Menus, buttons, settings, notifications, error messages, help text and other interface content must remain clear and consistent in the context where users see them.
Localization may also involve technical elements such as placeholders, variables, tags, character limits and structured files.
Why does context matter so much?
A single software string can have several possible meanings.
For example, the English word ‘Open’ could refer to opening a file, an account that is currently open, an available position, or the state of a setting. Without context, a linguist may choose a translation that is correct in general but wrong in the product.
Useful context can include screenshots, string descriptions, feature names, previous translations and information about where the text appears.
Screen location
Knowing whether the text appears on a button, menu, heading or message helps determine the correct wording.
User action
The meaning may depend on what the user is trying to do.
Feature context
Product and feature information can clarify ambiguous short strings.
Previous usage
Approved earlier translations can show how the same term has already been used in the product.
Why are short strings difficult?
Short source strings often contain less information than complete sentences.
A button such as ‘Save’, ‘Close’, ‘Apply’, ‘Charge’ or ‘Transfer’ may look simple, but the correct translation can depend on the object, action and interface context.
Short strings can also be difficult because the translation may need to remain concise enough to fit the interface.
Ambiguity
A short word may have several meanings without surrounding text.
Grammar
The correct form may depend on whether the string is a command, label or status.
Missing subject or object
The source may omit information that the target language needs grammatically.
Interface space
The most natural translation may be too long for the available UI element.
What are placeholders and variables?
Software strings often contain technical elements that are replaced automatically when the product is used.
Examples may include:
- user names
- dates
- amounts
- percentages
- product names
- links
- item counts
- dynamic values
Why do character limits matter?
Translated text is often longer or shorter than the source.
A button or mobile interface may have very limited space, so a linguist may need to choose wording that is both accurate and concise.
Character limits should ideally be supplied with enough context to show what the text does. A short translation that fits but changes the meaning is not a useful solution.
Buttons
Action labels often need short wording that remains clear.
Mobile interfaces
Small screens can make text expansion more noticeable.
Notifications
Messages may have fixed display limits or need to remain easy to scan.
Terminology needs to stay consistent across the product
Software uses the same feature names, settings, actions and product terms repeatedly.
If the same English feature is translated differently in the menu, help centre and notification messages, users may think these are different functions.
Approved terminology helps the linguistic team use the same wording across interfaces, documentation and future releases.
Feature names
Product and feature terminology can be recorded for consistent use.
Actions
Repeated actions such as save, cancel, transfer or verify should follow the approved language for the product.
Navigation
Menus and navigation terms need to remain aligned across screens.
Support content
Help articles and interface terminology should use the same product language where appropriate.
Why screenshots and reference material help
Screenshots can provide information that is missing from the string itself.
They may show what the user sees before and after an action, whether a term is a heading or button, and how much space is available.
Other useful material can include product documentation, style guides, terminology, previous translations and notes from the product team.
Screenshots
Show where the string appears and how it relates to nearby content.
String descriptions
Explain the purpose of short or ambiguous text.
Style guides
Record tone, spelling and formatting preferences.
Terminology
Provides approved product and feature wording.
Previous translations
Show how recurring content has already been localized.
What does software localization QA check?
Software localization QA can combine linguistic checks with checks for technical elements in the translated files.
Meaning
Whether the translation communicates the intended meaning of the source.
Terminology
Whether approved product terms are used consistently.
Placeholders
Whether variables and technical placeholders remain intact.
Tags
Whether markup or other required technical elements have been preserved.
Missing text
Whether source content has been left untranslated or omitted.
Consistency
Whether repeated interface terms use the same approved wording.
Character limits
Whether translations meet supplied length restrictions where required.
Numbers & formatting
Whether numbers, punctuation and other structured elements remain correct for the project.
Software localization usually continues after launch
Software products change regularly. New features are added, existing strings are updated and old content may be removed.
This means localization often becomes an ongoing process rather than a one-time translation project.
Keeping translation memories, terminology and regular linguistic teams available helps new releases remain consistent with previous versions.
New features
New strings can use existing terminology and approved product language.
Updated strings
Changed source text can be compared with previous translations.
New languages
Existing source terminology and project instructions can support expansion into additional target languages.
Regular releases
Translation and review can follow the product’s release schedule.
How does a software localization workflow work?
The exact process depends on the client’s product and localization setup, but a typical workflow may include the following stages.
- 01
Project setup
The languages, files, deadlines, context and localization requirements are confirmed.
- 02
Resources prepared
Translation memories, terminology, style guides, screenshots and previous approved content are made available where possible.
- 03
Translation & localization
Linguists translate the strings while considering their interface context and technical requirements.
- 04
Queries
Ambiguous strings and terminology questions can be raised during the project.
- 05
Review & QA
The agreed linguistic review and technical checks are completed.
- 06
Delivery & updates
Localized content is returned in the required environment or format, and approved language resources can be maintained for later releases.
Working in the client’s localization platform
Many software teams already use a localization platform or translation management system.
VIAX can work in client-provided CAT, TMS and localization environments where access is available. This allows linguists to use the client’s existing translation memories, terminology, comments and review workflow.
Where screenshots, context or internal review are available in the platform, they can remain part of the same project environment.
Common software localization problems
No context
A string has several possible meanings and no information about where it appears.
Inconsistent feature names
The same product function is translated differently across the interface.
Broken placeholders
A variable or technical element is changed during translation.
Text expansion
The target text no longer fits the available interface space.
Old terminology
A previous product term continues to appear after the approved wording has changed.
Mixed formal and informal address
The interface uses different levels of formality across screens.
Disconnected help content
The help centre uses different terminology from the product interface.
Source changes without context
An updated source string looks similar to the previous version but has a different meaning.
PROJECT EXAMPLE
Ongoing fintech software localization
VIAX’s long-term fintech localization work includes software, website, marketing, financial and legal content across 21 languages.
Approximately four to seven new requests arrive on a typical working day, so localization resources need to remain available as the product and customer content change.
~9M
Words translated and localized
21
Languages
4–7
Requests daily
7+ years
Long-term cooperation
FAQ
Frequently asked questions
What is the difference between software translation and software localization?
Translation focuses on the language of the source strings. Software localization also considers interface context, product terminology, placeholders, character limits, formatting and how the text works inside the product.
Why do translators need screenshots?
Screenshots can show where a string appears, what the user is doing and how the text relates to nearby interface elements. This can help resolve ambiguity that is not visible in the string alone.
What are placeholders in software localization?
Placeholders are technical elements that are replaced with dynamic information such as names, numbers, dates or amounts. They normally need to remain intact during translation.
Why can one word be difficult to translate?
A short source word can have several meanings. The correct translation may depend on whether it is a button, status, heading, action or another type of interface element.
Can software localization use translation memory?
Yes. Translation memories can store approved previous translations and help reuse consistent wording when the same or similar strings appear in later releases.
Can software localization be handled inside our own platform?
Yes, where appropriate access is available. VIAX can work in client-provided CAT, TMS and localization environments and use the project resources available there.
Does software localization need ongoing maintenance?
Usually, yes, if the product continues to change. New features, revised strings and additional languages can make localization an ongoing part of the release process.
RELATED
Related VIAX resources
Software & Website Localization
Localization of software, apps, websites, interfaces and regular product releases.
Learn moreTranslation vs. localization
See how localization differs from professional translation.
Learn moreTechnology & Quality
Translation memories, terminology, review and quality processes for multilingual content.
Learn moreTerminology Management
Creation and maintenance of approved product and technical terminology.
Learn more
Planning a software localization project?
Send us the languages, files or platform details, expected volume and release schedule. If you already have translation memories, terminology or screenshots, include those as well.