Skip to main content
Professional software localization services
Software Localisation Services Premium

Software localisation in over 225 languages — ICU MessageFormat, CLDR and pseudo-localisation QA

Native technical translators, ICU/CLDR-compliant pluralisation and date/number formats, pseudo-localisation pre-translation QA, and Git/CI integration — for SaaS, mobile, desktop, games and enterprise applications.

Software localisation is more than translating UI strings. ICU MessageFormat for pluralisation and variable substitution, CLDR for locale-aware dates and numbers, pseudo-localisation QA before translation begins, and Git/CI integration for continuous releases — every piece in the i18n chain has to hold. Our native technical translators work in your tooling and your release cadence. NDA on every project.

  • NDA on every project
  • over 225 languages
  • ICU MessageFormat & CLDR
  • Pseudo-localisation QA
Software localisation — Ecrivus International
Our approach

Localised software that feels like a native build

String by string, context by context — specialists with software/i18n experience localise your software per ICU MessageFormat and CLDR conventions. Embedded in your Git/CI workflow so every release is ready in every language on release day.

  • Specialists with software / i18n experience
  • Pseudo-localisation QA and context-aware build review
  • ICU MessageFormat / CLDR plus RTL support per market
225+
languages
from Afrikaans to Zulu
10.000+
technical translators
active worldwide
25.000+
projects
delivered since 2006
99%
satisfaction
20+ years of experience
Definition

What is software localisation?

Localisation mistakes tend to be small but costly: a truncated button label, a wrong date format, an incorrect plural stem in Russian, or UI that fails to mirror in RTL. Our workflow starts with pseudo-localisation as standard, exposing hard-coded strings, layout breaks and concatenation bugs before the translation phase begins — engineering fixes happen in code, not across fifteen translations later. For ongoing releases we move with your development team via Git, CI/CD and TMS integration.

Language reach

Software localisation in over 225 languages

From core EU languages to Arabic, Hebrew, Farsi and Urdu (RTL) — specialists with software/i18n experience per market, with full attention to UI conventions.

Our process

How it works

  1. Technical analysis and format check

    We analyse your software files — gettext .po/.mo, XLIFF, JSON i18n, RESX, .properties, Apple .strings/.stringsdict, Android XML — and draw up a localisation plan. Strings, variables, placeholders and context-dependent elements are identified upfront.

  2. Pseudo-localisation as pre-translation QA

    Standard step: pseudo-localisation temporarily replaces source strings with expanded test characters (for example "[!!! Säve čhängēs !!!]") to expose hard-coded strings, layout breaks, concatenation bugs and missing externalised strings before translators begin.

  3. Localisation infrastructure and CI integration

    We configure an efficient workflow via Git, GitHub/GitLab Actions and TMS (Phrase, Lokalise, Crowdin, memoQ Server). Pull-request driven workflow with version control and delta strings — only new or changed strings re-enter translation.

  4. Localisation by a specialist with software/i18n experience

    A specialist with software-engineering training or i18n sector experience localises every UI string with an eye for context: a three-word button label needs a different approach to an extensive help text or an error message. ICU MessageFormat and CLDR plural categories are applied correctly throughout.

  5. Linguistic QA and context review

    Where the project scope, release cadence or volume requires it, a second specialist checks the translations in context — with screenshots or a live build — to verify strings fit the available space, placeholder integrity is preserved and the interface reads logically.

  6. Delivery and continuous partnership

    We deliver localised files in your source format, import-ready via PR or your TMS. For ongoing releases we become your dedicated localisation partner — every sprint, release or hotfix.

Context is everything in software

Localisation without context becomes guesswork. We make context concrete.

A string like 'Delete' can be a button (imperative, short) or a confirmation header (calmer, explained). Without context a translator can miss the tone or place a placeholder incorrectly. Our approach uses screenshots, live build access and UI QA — where the project scope, release cadence or volume requires it. Combined with pseudo-localisation before the translation phase, hard-coded strings and layout breaks are fixed in code first.
Ecrivus International — software localisation
Why Ecrivus

Technical and linguistic — every release, again

From format support to sprint integration: our localisation moves with your development team, not the other way around.

  • ICU MessageFormat and CLDR-compliant software localisation — Ecrivus International

    ICU MessageFormat & CLDR-compliant

    Pluralisation per CLDR plural categories (zero/one/two/few/many/other), locale-aware date/number/currency formats and placeholder validation via ICU MessageFormat. No string concatenation hacks for plural forms.

  • Pseudo-localisation QA — Ecrivus International

    Pseudo-localisation QA before translation

    We run pseudo-localisation before the real translation begins to expose hard-coded strings, layout breaks and concatenation bugs. Engineering fixes happen before the translation phase, not after — saving costly retranslate cycles.

  • Multilingual software localisation including RTL — Ecrivus International

    Over 225 languages, RTL as standard

    From core European languages to Arabic, Hebrew, Farsi and Urdu (RTL): localisation for every market, with UI mirroring, BiDi text rendering, locale-aware date and currency formats and CLDR collation rules.

  • Context-aware software localisation — Ecrivus International

    Context-aware translation with build access

    We always ask for the context of each string. An error message, a tooltip and a button label each demand a different tone and length. Specialists with software/i18n experience receive screenshots or direct build access.

Quality assurance

Your software, our responsibility

Every localisation runs through a quality process — from format check to context QA inside your live build environment.

  • Specialists with software / i18n experience Specialism per domain
  • ICU MessageFormat / CLDR compliant Pluralisation, dates, numbers, collation per locale
  • Pseudo-localisation QA as standard Hard-coded strings and layout breaks exposed before translation
  • Multi-format support PO/MO · XLIFF · JSON · .strings · Android XML · RESX
  • Git / CI/CD integration Phrase, Lokalise, Crowdin, memoQ Server
  • NDA-protected Source code and strings kept confidential
From practice

Concrete localisation projects

From SaaS dashboards and fintech mobile apps to AAA games shipping across multiple languages.

SaaS dashboard localisation — Ecrivus International SaaS · B2B
Case Study

B2B SaaS dashboard — multilingual, sprint cadence

Project pattern for SaaS providers: every sprint new or changed strings flow through Git integration into multiple languages. Pull-request driven workflow, translation memory per client, specialists with UX sensibility — only delta strings sprint after sprint, no release blockers.

Git-PR workflow
sprint cadence
per client TM
Fintech app localisation — Ecrivus International Fintech · Mobile
Case Study

Fintech mobile app — RTL plus per-market currency

Project pattern for fintech apps live in multiple markets including Arabic and Hebrew: full RTL UI localisation with mirroring, locale-aware currency and date formats per market, accessibility strings included. Context QA in the live build before release.

AR+HE RTL
per market formats
live build QA
Game localisation — Ecrivus International Games · AAA
Case Study

Game publisher — AAA title, many languages

Project pattern for AAA game localisation: dialogue, UI, menus and accessibility strings localised in parallel across many languages. Context screenshots per scene, terminology base for character lore, synchronous launch across every market.

AAA scope
screenshots context
sync launch
Applications

For which software?

8software types

Localisation for every type of software — from B2B SaaS to mobile games, including RTL layouts and analytics dashboards.

  • SaaS platforms and web applications
  • Mobile apps (iOS & Android)
  • Desktop and enterprise applications
  • Games and game interfaces
  • Technical software interfaces
  • Dashboards and analytics tools
  • E-commerce platforms
  • Help and user documentation

Trusted by government, legal institutions & global enterprises

HPMinistry of JusticeDSMSiemensASMLAmazonINGCalvin KleinRocheShellEuropean Court of JusticeBoschBMWPhilipsAudi
Legal SectorBASFImmigration ServicesVolkswagenDeutsche BankSolvaySAPMedtronicMaastricht UniversityDSMRabobankJohn DeereRitualsUnilever
What is software localisation?
Software localisation is the process of adapting software to the language, culture, legal and technical conventions of a target market — including ICU MessageFormat for pluralisation, CLDR for locale-aware dates and numbers, and locale-aware sorting (collation). Our workflow follows ICU MessageFormat / CLDR for locale-aware pluralisation, dates, numbers and collation. Internationalisation (i18n) prepares the code to support multiple locales; localisation (l10n) adapts content and conventions per market. Well-localised software feels to the user as if it were originally built in their language — that requires more than text replacement.
What is pseudo-localisation and why does it matter?
Pseudo-localisation replaces source strings with expanded test characters before translation begins, exposing hard-coded strings, layout breaks and concatenation bugs early — so issues are fixed in code, not in 15 translations later. pseudo-localisation before translation: exposes hard-coded strings, layout breaks and concatenation bugs. German is roughly 30% wider than English; RTL languages require UI mirroring — pseudo-localisation simulates that pressure with placeholder characters like "[!!! Säve čhängēs !!!]". Engineering fixes happen before translation, not after, which avoids costly retranslate cycles.
Which file formats do you support?
We work with PO/MO (gettext), XLIFF, JSON i18n, RESX (.NET), .properties (Java), Apple .strings / .stringsdict, Android XML, YAML and CSV — and align on custom formats (Qt .ts, Unity, Unreal Engine, custom JSON schemas) with your engineering team in advance. We are compatible with common CMS export formats (WordPress XLIFF, Drupal i18n, Shopify Markets CSV), and CAT tools (SDL Trados, memoQ) with managed terminology support these formats natively, preserving placeholders, comment context and key names. Files come back import-ready in the source format.
Do you integrate with our Git or CI/CD workflow?
Yes — we work directly with your repository or via your localisation platform (Phrase, Lokalise, Crowdin, memoQ Server) so every sprint, release or hotfix flows through the same pipeline. Pull-request driven workflow with Git, GitHub/GitLab Actions or webhook integration with your own CI/CD. CAT tools (SDL Trados, memoQ) with managed terminology build translation memory that is reused sprint after sprint — only delta strings reach the translator, so the per-sprint cost falls over time.
Can you handle right-to-left languages such as Arabic, Hebrew and Farsi?
Yes — we localise into RTL languages (Arabic, Hebrew, Farsi, Urdu) with mirrored UI handling, bidirectional text rendering (Unicode bidi algorithm), locale-aware date and number formats per CLDR, and context QA in the live build to catch layout breaks before release. Our RTL specialists review not just the translation but the visual rendering: reading direction, alignment, punctuation position and UI element mirroring. For mixed text (Arabic plus Latin brand names) we follow Unicode BiDi conventions.
How do you handle plural forms and gendered languages?
We use ICU MessageFormat with CLDR plural categories (zero/one/two/few/many/other) so plural forms in Russian, Polish, Arabic and other complex-plural languages render correctly — no concatenated strings. CLDR distinguishes six plural categories — Polish and Russian use three, Arabic six; English and Dutch only two. ICU-syntax plural and select blocks are natively supported by our tooling. Our workflow follows ICU MessageFormat / CLDR for locale-aware pluralisation, dates, numbers and collation, including for gendered grammar where the source code provides gender context.
Do you use AI for software localisation?
We combine CAT tools (SDL Trados, memoQ) with managed terminology and translation memory for consistency with native human review — AI translations are always reviewed by a human specialist. For UI-critical strings (buttons, errors, onboarding) we always assign a human specialist; for high-volume, lower-risk content (help articles, knowledge base) MTPE is available with mandatory human review and placeholder validation. Pure machine translation without review is not delivered for UI strings.
Social proof

Client testimonials

What clients say about working with Ecrivus — from SaaS startups to AAA game publishers shipping across multiple languages.

★★★★★
Certified translations for our international cases are delivered quickly and carefully. Our project manager knows our account inside out.

Need software localised?

No-obligation — response within one hour during business hours

Discover more

Below you'll find adjacent services, sectors we translate for often, and the most requested language pairs.

Last updated: May 2026