Software localisation: interface, strings and documentation to one standard

A software product, whether a desktop app, a SaaS platform, an ERP system or a technical tool, talks to the user through thousands of strings: menus, dialogs, error codes, logs, tooltips, help articles. If this voice is inconsistent, if "Export" becomes one Georgian word on one screen, another on the next and stays in English altogether on a third, the user perceives the product as unreliable and the support department receives a stream of unnecessary questions. Software localisation (L10n) ensures exactly this consistency and technical precision.

Internationalisation and localisation: two stages, one goal

In professional practice two concepts complement each other:

• Internationalisation (i18n) is the developer's task: the code must be built so that text is stored in resource files separate from the code, dates and numbers are formatted according to the system locale, and the interface withstands changes in text length.
• Localisation (L10n) is our task: the linguistic, cultural and technical adaptation of these resource files for a specific market.

If the product was built without internationalisation (text is written directly in the code, strings are assembled from several parts), localisation becomes difficult and unreliable. So at the start of the project we carry out a technical audit and give the development team specific recommendations before we start translating.

What software localisation covers

• Interface strings: menus, buttons, dialogs, the settings panel, the status bar, context menus, descriptions of keyboard shortcuts.
• Error and system messages: error codes, warnings, log entries, which often must be unambiguously identifiable for technical support as well.
• Installer and licence: the installation wizard, the licence agreement (EULA), update notifications.
• Help system and documentation: user manual, online help centre, knowledge base, subtitles for video tutorials, technical specifications.
• API and developer documentation: where the explanatory text is localised while the code examples stay unchanged.
• Training and marketing materials: product tours, onboarding emails, release notes.

String resources: where the technical risks hide

A software string is rarely a "simple sentence". A typical resource file contains:

• Variables and placeholders: "%s", "%d", "{0}", "{{name}}", "${count}". Each must stay unchanged and land in the grammatically correct place in the sentence.
• Plural rules: ICU MessageFormat, .stringsdict, Android plurals. Georgian, Russian, Polish and Arabic use radically different logic from each other.
• Shortcuts and ampersands: in Windows apps "&File" means that the letter F is activated with the Alt combination. In a localised menu these letters must not repeat.
• HTML and Markdown fragments: strings often contain links, bold text, line break characters.
• Concatenation: when a sentence is assembled from several strings ("You have" + count + "new messages"), the word order in the target language may not match. We record such cases and advise the developer to merge the string.
• Comments and context: msgctxt, developer comments, screenshots. "Open" may be a verb or an adjective, and without context the choice depends on guesswork.

Our CAT tools protect variables and tags automatically, while the QA module checks every string for lost variables, duplication, exceeded length limits and deviation from the terminology base.

The file formats we work with

• .NET: .resx, .resw
• Java: .properties, ResourceBundle
• Windows: .rc, .dll resources, WiX installer files
• macOS and iOS: .strings, .stringsdict, .xcstrings
• Qt: .ts files
• GNU: PO/POT (gettext)
• web and cross-platform: JSON, YAML, XLIFF 1.2 and 2.0, ARB, TOML
• documentation: Markdown, DITA, DocBook, HTML, AsciiDoc, Confluence export
• platforms: Crowdin, Lokalise, Phrase, Transifex, Weblate, as well as direct integration with the Git repository and inclusion in the CI/CD process

We return the file in the same structure, preserving the encoding (UTF-8) and the line ending style (LF/CRLF), so that the translation goes directly into the build process.

Terminology management: the product language that does not change

A software product develops over years, often by the hands of different teams. The only guarantee of consistency is a centralised terminology base and translation memory:

• The glossary records every key term of the product, its approved translation, definition and forbidden variants. For example: "workspace" = one approved Georgian term, not a transliteration and not a near-synonym.
• The style guide sets the form of address (formal or informal), the verb form on buttons (imperative or infinitive), punctuation and the use of capital letters.
• Translation memory ensures that a string once approved repeats itself automatically in every update, which also reduces deadlines: in a typical update new strings are 5-15% of the whole volume.

Linguistic and functional testing

After the finished resource file is built into the product it goes through testing:

1. Linguistic QA: the tester goes through the localised build in the real environment (Windows, macOS, browser) and checks cut-off text, strings that landed in the wrong context, untranslated elements, encoding problems.
2. Functional QA: the behaviour of the localised version does not differ from the original: shortcuts work, formats match the system locale, sorting follows the Georgian alphabet, fields accept Georgian characters.
3. Regression at updates: in every new version only the changed and new strings are checked, which makes the process fast.

Every problem is recorded with the string identifier, a screenshot and a proposed fix, so that the developer does not need an additional search.

Continuous localisation in agile teams

Modern products ship in two-week sprints or even more often. Localisation must follow this rhythm, not hold it back. In the continuous localisation model new strings go automatically from the repository to the localisation platform, our team processes them within 1-2 working days, and the translation comes back as a pull request. As a result every release happens in every language at the same time, and the "let's release in English first, Georgian later" practice, which makes the local user feel second-class, is no longer needed.

Frequently asked questions