Tool Evaluation
Part of Content management systems for marketing teams
Evaluating localisation support in a CMS
Assess CMS localisation through fields, fallbacks, market approvals, page settings and export, with documented product limits.
Judge localisation support with one known page in Australia and another intended market. Check market-specific fields, missing-wording behaviour, translation and publication status, locale-specific review, and whether each export record identifies its locale. Verify the results in the delivered page and a sample export, not just in an editor preview.
Define what varies by market
Choose a representative campaign page for Australia and another intended market. Mark each field as shared, translated or locally decided. A product identifier may stay shared while the headline, offer wording, page address and search description need separate review. Have the market owner set the rule for each field before testing the CMS.
Include a field that must not silently show another market's wording. Decide whether a missing local offer should keep the page unpublished, while less sensitive copy might use a fallback. Record the acceptable outcome for each field and market; do not assume a language picker defines it.
Check the documented models
In Drupal, Content Translation lets administrators choose which fields are translatable. A field left untranslated is shared, so editing it can affect every translation. The Translations page shows translation status, and the “Flag other translations as outdated” checkbox can mark other translations out of date after an edit.
Drupal Content Moderation uses workflows with states and transitions. Its default “Editorial” workflow can keep a published version live while a separate working copy is reviewed; the workflow can be customised and applied to content types such as Basic Page. Test the required publication decisions for each market version.
Include Contentful locale setup and Content Delivery API localisation in the delivery test. For Webflow, test Collection content, page settings and locale-specific access. Confirm each control against the same market-specific field and review decisions; do not infer missing-wording or publication behaviour from locale controls alone.
Verify the tested controls in the exact plan offered. Treat fallback behaviour and locale identification in exports as unconfirmed until a sample page and export demonstrate the required result.
CMS Localisation Support: Key Features Across Platforms
- Field-Level Translation Control
- Drupal (Content Translation), Contentful (locales), Webflow (Collection & page settings)
- Locale-Specific Access Management
- Webflow (locale-specific access), Contentful (custom roles and permissions)
- Content Moderation Workflow
- Drupal (Content Moderation with custom workflows)
- Translation Status Tracking
- Drupal (Translations page, flag outdated translations)
- API Localization Support
- Contentful (Content Delivery API localization)
Pros and Cons of CMS Localisation Approaches
- Pro: Drupal offers granular control over field translation and moderation workflowsIdeal for complex multi-market campaigns with strict review processes.
- Con: Requires technical setup and ongoing maintenanceNot suitable for non-technical teams without dedicated support.
- Pro: Contentful enables scalable, API-driven localisation with robust delivery optionsWell-suited for digital-first brands managing multiple markets via headless CMS.
- Con: Custom role and permission setups require careful planningMisconfigurations may expose sensitive content or block necessary access.
- Pro: Webflow simplifies localisation through intuitive UI for collections and page settingsUser-friendly for designers and marketers managing regional content.
- Con: Limited automation for fallbacks and export validationRelies heavily on manual checks to ensure locale accuracy.
Inspect the reader's result
For each locale, preview a complete page, one with a missing local field and one whose source version has changed. Check visible text, address, metadata and links to other market versions. Record whether missing content shows another market's wording, stays blank or prevents release, and whether a source change makes the translation visibly due for review.
Use safe sample text with visibly different market wording so an unintended fallback is easy to spot. Export a known record from each locale, including a CSV if that is the proposed format, and check that every record carries an explicit locale identifier. Confirm that shared fields, local fields and missing values remain distinguishable in the export.
Record the shared and local field rules, observed fallback results, translation and publication states, market reviewers, plan dependencies and manual checks required before a page goes live. Check locale-specific access for the intended market reviewer separately from the approval needed to release that market's page.
Testing Localisation in a CMS: Step-by-Step Process
- Define market-specific fieldsMark each field as shared, translated or locally decided for Australia and target market.
- Test translation and fallback behaviourPreview pages with missing local fields; check if content falls back to another locale.
- Verify publication status per localeEnsure each market version can be published independently with correct workflow states.
- Export and validate locale identifiersCheck that exported records (e.g., CSV) include explicit locale tags.
- Confirm reviewer access and approval pathsTest that intended market reviewers have access without overriding approval requirements.
Key Metrics for CMS Localisation Validation
- Pages Tested Per Market
- 2 (Australia + target market)
- Export Formats Validated
- CSV and JSON (as per delivery plan)
- Locale Identifiers Confirmed
- All exported records carry explicit locale tags
- Manual Checks Required
- Yes – for fallbacks, approvals, and export verification
