Interface language
A short string
can need a long explanation
‘Open’ can describe a status or instruct an action. ‘Save’ can store a record or refer to a commercial saving. A list of strings without context hides these distinctions. Software localisation needs the function of the text, the object it refers to and the screen on which it appears.
Screenshots, stable string identifiers and developer comments help establish that context. A useful comment explains behaviour: whether a control opens a window, creates a file or submits a record. It also identifies restrictions that cannot be inferred from the words, such as a fixed label width or a variable inserted at runtime.
The language work connects interface labels with help content, user guides and release notes. A feature should retain its agreed name across those surfaces. Related manuals belong within technical translation; public product pages have their own website translation requirements.
Localisation constraints
Protect the function
as well as the meaning
| String feature | Language risk | Briefing requirement |
|---|---|---|
| Variables and placeholders | An inserted name or number may change the grammar of the surrounding sentence. | Identify protected tokens and explain the values they represent. |
| Plural messages | Languages do not all divide singular and plural forms in the same way. | Supply the complete message structure and explain supported forms. |
| Shared short labels | One source word may require different translations in different contexts. | Identify every screen or function using the shared string. |
| Length limits | A correct translation may occupy more space than the source. | Specify actual limits and distinguish character counts from visual width. |
| Dates and numbers | A familiar source format can be ambiguous in another locale. | State which formats the application controls and which are editable text. |
Examples describe localisation considerations. Accepted file formats, technical preparation and implementation checks are defined for the individual project.
Terminology decisions
Name the feature
once, then use it consistently
Interface terminology is part of product behaviour: it tells people what can be selected, changed, deleted or confirmed.
A glossary should distinguish product names from translatable feature names and explain terms with several meanings. A ‘workspace’, for example, might be an account area, a shared folder or a physical location. An approved equivalent without a definition can carry the same ambiguity into every translated screen.
Consistency also requires judgement. A menu command and a sentence in a help article may need different grammatical forms while referring to the same feature. Reusing a term does not mean copying an inflected word mechanically. Native-speaker translators can keep the concept stable while making each occurrence grammatical.
Babylon Translations uses CAT tools, including Trados, and dedicated QA software. Translation memory provides reusable bilingual segments; terminology records identify approved concepts. Neither replaces reading the message in context. The agency’s translation process includes proofreading and review before delivery.
Release preparation
Make the language package
ready for a release
Identify the source version
The package should carry a release reference and distinguish new, changed and retired strings. Stable identifiers help connect translation questions with the correct message. Previous approved translations are valuable references, especially where the English wording has changed but the underlying feature has not.
Resolve product questions
Assign a product contact who can explain behaviour and approve terminology. A compact question record should include the string identifier, context and decision. Answers about shared controls can affect several languages, so those decisions need to reach every relevant language team before approval.
Check the implemented text
Linguistic review compares the translation with its source. The product team’s checks in the application address a different set of questions: clipping, missing text, incorrect string placement and runtime behaviour. The brief should allocate responsibility for each check and allow time for resulting text corrections.
Localise the task, not a sequence of fragments
A sentence assembled from several translated fragments can become ungrammatical when the target language changes word order, gender or case. Complete messages usually give translators more control over meaning. Where the application requires fragments, the brief needs to show the combinations that can actually occur.
Each market brings its own constraints: scripts, text expansion, date and number formats, and forms of address. The 32 languages and variants offered by Babylon Translations include distinct regional forms of English, French, Spanish and Portuguese. Selecting the intended locale before translation prevents conflicting language conventions within a release.
Software localisation questions
Before the strings
leave development
What files are needed for software localisation?
Software localisation needs editable source text with enough structure to connect each message to its function. The file format and handover method should be agreed before translation. Stable identifiers, screenshots, developer comments, character limits and previous translations make the package more useful; a format name alone does not establish that the context is complete.
How are placeholders handled in translated software?
Placeholders should remain recognisable as protected technical elements, while the surrounding language reflects the values they represent. The brief must distinguish editable text from tokens and explain any ordering restrictions. A placeholder check can identify technical mismatches, but a linguist still needs context to judge whether the completed message will be grammatical and accurate.
Why do translators need screenshots for software strings?
Screenshots show the role and surrounding context of a string that may otherwise be ambiguous. They help distinguish commands from statuses, identify the object being described and reveal space constraints. Screenshots are most useful when linked to string identifiers and accompanied by explanations of interactions that a static image cannot show.
Can translation memory support later software releases?
Translation memory can support later releases by presenting previously translated segments for reuse or comparison. New and changed strings still need assessment in their current context. A matching source sentence may now describe a different function, while a small source edit can change the meaning enough to require a fresh translation decision.
Is software localisation the same as software testing?
Software localisation concerns language and locale requirements; software testing examines application behaviour. Linguistic review does not demonstrate that a translated build displays every string correctly or handles every input. Implementation checks should cover the actual interface, and the project brief should state who supplies context, approves language and verifies the resulting build.
How is software localisation priced and scheduled?
A software localisation estimate depends on text volume, language combinations, existing translations, context quality and technical constraints. Short strings can require substantial clarification, so word count alone does not describe the effort. A release date, stable source package and clear review responsibilities provide the basis for a meaningful scope and schedule.