Website localisation and translation in over 225 languages — beyond literal translation
Three tiers: DIY tools, professional human translation, and full localisation with CMS integration, hreflang and visual QA — for corporates, e-commerce, SaaS and public-sector sites across the UK and continental Europe.
A translated website is not yet a localised one. Currency notation, date formats, hreflang per RFC 5646, locale-specific content and visual QA in a staging environment turn translated copy into a site that feels native to each market. Our native translators and tech team handle WordPress, Drupal, Shopify and headless CMS exports end-to-end. NDA on every project.
Three tiers: translation, localisation, or full multilingual SEO
A strong multilingual site demands more than translated copy. We offer three tiers: (1) DIY tools (Google Translate, DeepL — only for low-risk content), (2) professional human translation, (3) full localisation with CMS integration, hreflang per RFC 5646, currency / date / RTL conventions and visual QA in staging. Our native translators and tech team handle this end-to-end.
What is website localisation, and how does it differ from translation?
We work with every common CMS platform: WordPress (with WPML or Polylang), Drupal, Shopify,
Webflow, Sitecore, Contentful and other headless content management systems. For apps we
handle iOS .strings, Android XML resource files and JSON for cross-platform frameworks
such as React Native and Flutter. SEO optimisation (meta titles, meta descriptions, URLs and
alt text) is part of every website translation as standard. Lead time depends on page count,
languages and CMS workflow — confirmed in writing in the quote.
Language reach
Popular markets for site localisation
From European core languages to APAC and RTL (Arabic) — native translators and technical specialists per market.
We analyse your website or app and inventory every piece of translatable content: pages, menus, buttons, error messages, meta descriptions and image alt text.
02
CMS export
Through an export file, a WPML / Polylang integration or a direct API connection we extract the content for you — no manual copy-and-paste required.
03
Translation with SEO focus
Native translators work with your termbase and optimise for local search terms. Meta titles and URLs are adapted per language.
04
Visual QA in staging
We test the translated site in a preview environment: text length in buttons, overflowing content, cultural fit. Issues are resolved before go-live.
05
Import and launch support
Translated content is imported back into your CMS. Launch support covers hreflang validation and indexing in Google Search Console.
Technical + linguistic + cultural
Our site localisation combines what no single discipline can deliver alone.
A strong site translation is not an isolated step — it is a chain: native translators, SEO specialists, CMS engineers and QA reviewers working together. We safeguard the chain where the project scope, market risk or volume requires it; for brand-critical landing pages a visual staging QA cycle is standard, for internal knowledge-base content we scope to sampling.
Ecrivus International — website and app localisation
From CMS export to visual QA in staging — one team, one point of contact.
CMS integration
WordPress (WPML / Polylang), Drupal, Shopify, Webflow and headless CMS platforms: we work inside your system or with exports — no manual copy-and-paste.
Multilingual SEO included
Meta titles, meta descriptions, URLs and alt text are optimised per language — so your translated site is also discoverable in the target market.
iOS · Android · cross-platform
For apps: .strings / .stringsdict (iOS), XML resource files (Android), JSON for React Native and Flutter. Context and screenshots ensure accurate UI translation.
Visual QA as standard
For every language version we check in a staging environment: do labels fit inside buttons? Are text blocks overlapping? Are RTL pages mirrored correctly?
Quality assurance
Your site live and discoverable in every language — quality scoped to the project
Every website and app localisation runs through the same process — native translation, SEO optimisation, visual QA where the scope requires it, and hreflang per RFC 5646.
SEO optimisationMeta titles, URLs and alt text per language
Visual QA in stagingFor every language version, pre-launch
Hreflang implementationPer RFC 5646 / BCP 47 with x-default
NDA on content & UXPre-launch confidentiality
From practice
Concrete localisation projects
From e-commerce Shopify launches to SaaS dashboards and fintech apps — cross-platform deliveries.
01E-commerce · Fashion
Case Study
Shopify e-commerce site NL → 5 languages
A fashion retailer expanded into five EU markets via Shopify. Translation, localised SEO and visual QA delivered as a phased per-market release. Hreflang and x-default configured; product pages localised in batch.
5languages
450products
ShopifyCMS
02SaaS · B2B EU
Case Study
SaaS dashboard EN → DE, FR, ES
A B2B SaaS company localised both their product dashboard and marketing site. UI strings were integrated through Phrase (Memsource); marketing copy via a Webflow export. Native QA carried out in the staging environment before each go-live.
3languages
2.8Kstrings
Webflow + Phraseplatform
03Fintech · Apps
Case Study
iOS + Android app in 8 languages
A fintech app rolled out across eight EU markets. Native translators worked with iOS .strings and Android XML, supported by context screenshots. Visual QA was completed on staging builds before App Store release.
8languages
1.5Kstrings
2platforms
Platforms & types
For which digital environments?
8platform types
We localise every type of digital platform — from corporate sites and online stores to mobile apps and SaaS dashboards.
Corporate websites
E-commerce (Shopify / Magento / WooCommerce)
SaaS dashboards and admin panels
Mobile apps (iOS / Android)
Government and institutional sites
Online learning platforms
Booking platforms (travel and hospitality)
Patient portals and medical platforms
Trusted by government, legal institutions & global enterprises
HPMinistry of JusticeDSMSiemensASMLAmazonINGCalvin KleinRocheShellEuropean Court of JusticeBoschBMWPhilipsAudi
HPMinistry of JusticeDSMSiemensASMLAmazonINGCalvin KleinRocheShellEuropean Court of JusticeBoschBMWPhilipsAudi
What is website localisation and how does it differ from website translation?
Website localisation is translation plus cultural adaptation plus technical adaptation (currency, date, RTL, hreflang) — translation alone leaves a foreign-feeling site, localisation makes it feel native to each market. Industry-canonical (W3C i18n / GALA): website localisation = translation + cultural adaptation + technical adaptation (currency, date, RTL, hreflang) — not literal translation. In practice that means hreflang per RFC 5646 / BCP 47 with x-default, CLDR conventions for currency and date, RTL support for Arabic and Hebrew, and locale-specific content rather than 1-to-1 translation of source pages.
Which CMS platforms do you work with?
WordPress (with WPML or Polylang), Drupal i18n, Shopify Markets, Webflow, Sitecore, Contentful and other headless CMS platforms — via XLIFF export, plugin integration or direct API. Standard: compatible with common CMS export formats (WordPress XLIFF, Drupal i18n, Shopify Markets CSV). For headless / JAMstack flows we work via GitHub PR or API connection; no manual copy-and-paste required. CAT tools (SDL Trados, memoQ) handle these formats natively while preserving placeholders and variables.
How long does a website localisation project take?
Lead time depends on page count, language count, CMS workflow and visual QA scope — we confirm the timeline in the quote and align it with your release plan; rush deadline confirmed in the quote. For multi-language sites we use phased per-language releases with parallel team coordination. Visual QA in staging adds a separate cycle that we factor into the schedule before go-live.
Do you implement hreflang correctly?
Yes — we implement hreflang per RFC 5646 / BCP 47 with x-default fallback and validate it in Google Search Console before launch. Standard: hreflang implementation per RFC 5646 / BCP 47 with x-default and canonical URL strategy. Our translators integrate localised keywords in meta titles and URLs rather than literal translations — without correct international targeting, a translated site under-performs in Search Console for the target market.
Do you handle right-to-left languages such as Arabic and Hebrew?
Yes — we localise into RTL languages with mirrored layout, locale-aware date and number formats, and visual QA in your staging environment to catch layout breaks before launch. We follow ICU MessageFormat / CLDR conventions for plurals and date formats, and our QA team checks bidirectional alignment, icon mirroring and form-field flow on staging builds.
Do you use AI for website translation?
We combine CAT tools (SDL Trados, memoQ) for terminology consistency with native human review — AI translations are always reviewed by a human specialist before they ship. AI translations are always reviewed by a human specialist. CAT tools manage terminology and translation memory; hero copy, CTAs and brand-critical content go through human specialist translators.
Can you also localise our mobile app or SaaS dashboard?
Yes — for app strings (.strings, .xml, JSON i18n) and SaaS dashboards we run a dedicated software localisation workflow with ICU MessageFormat / CLDR support. For app strings we ask for context screenshots and variable names per UI element so that a three-word button label is treated differently from a longer help text.
01What is website localisation and how does it differ from website translation?
Website localisation is translation plus cultural adaptation plus technical adaptation (currency, date, RTL, hreflang) — translation alone leaves a foreign-feeling site, localisation makes it feel native to each market. Industry-canonical (W3C i18n / GALA): website localisation = translation + cultural adaptation + technical adaptation (currency, date, RTL, hreflang) — not literal translation. In practice that means hreflang per RFC 5646 / BCP 47 with x-default, CLDR conventions for currency and date, RTL support for Arabic and Hebrew, and locale-specific content rather than 1-to-1 translation of source pages.
02Which CMS platforms do you work with?
WordPress (with WPML or Polylang), Drupal i18n, Shopify Markets, Webflow, Sitecore, Contentful and other headless CMS platforms — via XLIFF export, plugin integration or direct API. Standard: compatible with common CMS export formats (WordPress XLIFF, Drupal i18n, Shopify Markets CSV). For headless / JAMstack flows we work via GitHub PR or API connection; no manual copy-and-paste required. CAT tools (SDL Trados, memoQ) handle these formats natively while preserving placeholders and variables.
03How long does a website localisation project take?
Lead time depends on page count, language count, CMS workflow and visual QA scope — we confirm the timeline in the quote and align it with your release plan; rush deadline confirmed in the quote. For multi-language sites we use phased per-language releases with parallel team coordination. Visual QA in staging adds a separate cycle that we factor into the schedule before go-live.
04Do you implement hreflang correctly?
Yes — we implement hreflang per RFC 5646 / BCP 47 with x-default fallback and validate it in Google Search Console before launch. Standard: hreflang implementation per RFC 5646 / BCP 47 with x-default and canonical URL strategy. Our translators integrate localised keywords in meta titles and URLs rather than literal translations — without correct international targeting, a translated site under-performs in Search Console for the target market.
05Do you handle right-to-left languages such as Arabic and Hebrew?
Yes — we localise into RTL languages with mirrored layout, locale-aware date and number formats, and visual QA in your staging environment to catch layout breaks before launch. We follow ICU MessageFormat / CLDR conventions for plurals and date formats, and our QA team checks bidirectional alignment, icon mirroring and form-field flow on staging builds.
06Do you use AI for website translation?
We combine CAT tools (SDL Trados, memoQ) for terminology consistency with native human review — AI translations are always reviewed by a human specialist before they ship. AI translations are always reviewed by a human specialist. CAT tools manage terminology and translation memory; hero copy, CTAs and brand-critical content go through human specialist translators.
07Can you also localise our mobile app or SaaS dashboard?
Yes — for app strings (.strings, .xml, JSON i18n) and SaaS dashboards we run a dedicated software localisation workflow with ICU MessageFormat / CLDR support. For app strings we ask for context screenshots and variable names per UI element so that a three-word button label is treated differently from a longer help text.
Social proof
Client testimonials
What clients say about working with Ecrivus — from Shopify rollouts to fintech app launches.
“
★★★★★
Certified translations for our international cases are delivered quickly and carefully. Our project manager knows our account inside out.
01 / 03
Need website or app localisation?
No-obligation — response within one hour on business days