Managing website localisation on a CMS is not the same as translating a document. Content is spread across templates, database fields, metadata, and interface strings. Overlooking that structure is the most common reason projects run over time and over budget.
This guide covers what matters before you start: how to prepare the CMS, how to structure the workflow with your translation team, and where projects typically go wrong.
What website localisation actually involves
Localising a website is not a word-substitution exercise. It means adapting content to the target market: currency, date formats, units of measurement, tone, cultural references, and typographic conventions. A website in English prepared for the German market needs more than text translation. It needs layout review for longer strings, verification against local data protection requirements, and adaptation of calls to action to match the register German users expect.
Modern CMS platforms (WordPress, Drupal, Sitecore, Contentful, Webflow, and others) handle content differently. Some separate content from structure clearly; others mix translatable text with template logic. Before sending any file for translation, you need to know exactly what can be exported, in which format, and what falls outside the export workflow.
The elements most often left out of standard exports include: text embedded in images, image alt attributes, SEO metadata, URLs and slugs, and automated system notifications. These must be identified and handled separately.
How to prepare the CMS before starting
CMS preparation determines the quality and speed of the project. The steps below apply to most platforms.
Audit existing content. Before localising, establish exactly what exists. Outdated pages, duplicate content, and obsolete text translated at full cost generate no value. A content audit before the project starts saves time and reduces volume.
Define the language architecture. Subdomain (fr.example.com), subdirectory (/fr/), or separate domain (example.fr) have different implications for SEO and content management. This decision must be made before any localisation work begins. Changing architecture mid-project is disruptive and expensive.
Configure the internationalisation plugin or module. Most CMS platforms have native or third-party solutions for multilingual management (WPML, Polylang, Drupal Language, etc.). These tools must be configured before exporting content, with translatable fields correctly mapped.
Export in a format compatible with CAT tools. XLIFF and PO/POT are the standard formats for translation work. They allow the translation team to apply translation memories and glossaries, maintaining terminological consistency across the project. Word or Excel exports are acceptable for small volumes but become difficult to manage in multi-language projects or when content updates frequently.
How to structure the workflow with your translation team
The most common problem in website localisation projects is not translation quality. It is the lack of coordination between the technical team and the language team.
Assign a single project manager. One point of contact between the client, the CMS, and the translation team removes ambiguity and reduces response time. Without this role, terminology questions go unanswered, content updates arrive unannounced, and rework accumulates.
Prepare a glossary before translation begins. Brand terms, product names, and technical terminology must be agreed before the translation starts. A client-approved glossary reduces revision rounds and ensures consistency across pages and future updates.
Establish a process for content updates. Websites change. The localisation process must include a clear procedure for new or updated content: who identifies changes, in what timeframe they are sent for translation, and how they are reimported into the CMS.
Validate in the live environment. A correct translation in an XLIFF file can still produce problems once reimported: text truncated by fixed-length fields, special characters incorrectly encoded, internal links pointing to the original-language version. Final validation must happen in the CMS, not in the export file. For projects with higher quality requirements, ISO 17100-certified localisation for SaaS platforms ensures an audited process with independent review.
Where localisation projects fail
Most problems are predictable. These are the most frequent.
- Forgotten non-translatable content: images with embedded text, videos without subtitles, attached PDFs. These elements exist outside the CMS and must be treated separately.
- Multilingual SEO ignored: metadata, hreflang tags, and localised URLs have a direct effect on the site's visibility in target markets. Translating body text without addressing technical SEO is a common and costly omission.
- Review done only in the file: approving a translation without validating it on the actual page leads to formatting, layout, and functionality problems discovered only after launch.
- Volume underestimated: the content visible to users is often less than half the actual translatable content of a website. Error messages, form confirmations, and automated emails are part of the product and must be localised.
How M21Global supports CMS localisation projects
The technology and software localisation team at M21Global works with the export formats of the main CMS platforms and integrates client-approved translation memories and glossaries into every project. For websites with frequent content updates, the workflow includes incremental TM management, which reduces both time and cost on each update cycle.
Projects with high quality requirements are handled through the Estratégica service tier, with three linguists, independent review, and a dedicated project manager. For high-volume content with lower criticality, the IAH+ service combines machine translation with selective human review. Get in touch to discuss your project architecture and receive a proposal matched to your website's volume, language pairs, and update cadence.
Related Services
Request a free software localisation quote
- Request a free software localisation quote
- Mobile App Localisation Angola Mozambique
- Iso 17100 Localization For Saas Platforms
- A Surprising Amount Of Content Available Online Is Generated By Artificial Intelligence
Frequently Asked Questions
What is the difference between translating and localising a website?
Translation replaces text in one language with equivalent text in another. Localisation goes further: it adapts date formats, currency, tone, cultural references, and visual conventions to the target market. A localised website feels built for that market, not simply translated.
Which export format should I use to send CMS content for translation?
XLIFF and PO/POT are the most suitable formats for CAT tool workflows, because they preserve content structure and enable the use of translation memories and glossaries. Word or Excel exports work for small volumes but become difficult to manage in multi-language projects or where content updates frequently.
Does localisation affect website SEO?
Yes. Multilingual SEO localisation covers the translation of metadata (title, description), the configuration of hreflang tags, and the definition of localised URLs. Omitting these elements limits the site's visibility in search engines in the target markets.
How should content updates be handled after the localised site launches?
A clear process must be defined before launch: who identifies new or changed content, in what timeframe it is sent for translation, and how it is reimported into the CMS. Translation memories allow previously approved segments to be reused, reducing time and cost on each update.
What website content is most often overlooked during localisation?
The most frequently missed elements are: images with embedded text, attached PDFs, videos without subtitles, error messages, form confirmations, and automated system emails. These exist outside the CMS's standard export flow and must be identified and handled separately.
