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.
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
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.
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.
02
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.
03
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.
04
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.
05
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.
06
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.
From format support to sprint integration: our localisation moves with your development team, not the other way around.
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 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.
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 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 experienceSpecialism per domain
ICU MessageFormat / CLDR compliantPluralisation, dates, numbers, collation per locale
Pseudo-localisation QA as standardHard-coded strings and layout breaks exposed before translation
Git / CI/CD integrationPhrase, Lokalise, Crowdin, memoQ Server
NDA-protectedSource code and strings kept confidential
From practice
Concrete localisation projects
From SaaS dashboards and fintech mobile apps to AAA games shipping across multiple languages.
01SaaS · 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-PRworkflow
sprintcadence
per clientTM
02Fintech · 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+HERTL
per marketformats
live buildQA
03Games · 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.
AAAscope
screenshotscontext
synclaunch
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
HPMinistry of JusticeDSMSiemensASMLAmazonINGCalvin KleinRocheShellEuropean Court of JusticeBoschBMWPhilipsAudi
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.
01What 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.
02What 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.
03Which 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.
04Do 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.
05Can 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.
06How 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.
07Do 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.
01 / 03
Need software localised?
No-obligation — response within one hour during business hours