How do you translate a Silverstripe CMS website with Fluent without confusing localized fields, published values, domain routes and international search engines? This Silverstripe multilingual localization guide explains Fluent’s locale model, DataObjects, fallback and inheritance, versioned publishing, template i18n messages, localized links, accessible forms and SEO release checks. Its purpose is to help editors and developers create dependable public language editions that remain accurate as the source website evolves.
Silverstripe CMS separates authored content localization from the translation of software messages. Fluent can localize the content fields of pages and configured data models while Silverstripe i18n handles messages from templates, modules and code. Fluent preserves a logical record identity across locales, but the published field values and fallback rules do not always behave as an editor expects. A reliable translation workflow has to test the actual public version, not merely the editor screen.
Start by defining a genuine reader task, configuring one language route, classifying the fields that need translation, and checking an entire journey from homepage to confirmation. This guide develops that workflow for internationally accessible websites, with practical examples about shared identifiers, localized documents, source corrections, navigation and search metadata. The goal is clear and truthful communication rather than a large number of nominally multilingual URLs.
Quick summary
- Fluent localizes content; Silverstripe i18n handles template and code messages.
- Shared record identity and published localized values require separate checks.
- Test fallback after changes to the original published page.
- Audit DataObjects, related records, domains, forms, documents and accessibility.
- Publish only complete reviewed journeys with accurate SEO and a source-change workflow.
Consider a fictional conservation centre offering educational workshops in English, French and German. Its scientific facts and identifiers are shared, but schedules, travel guidance and registration conditions may vary. This guide uses that example to show why international publishing is an editorial responsibility supported by correct software configuration.
1. Begin with an audience, not a dropdown
Identify the people who need the new language, their location and the exact service they want. Language alone does not prove that a visitor is eligible for a region-specific programme. A complete translation must cover the information needed to make a decision.
Document a source owner, target-language reviewer and factual approver for each important journey. Choose a pilot such as workshop registration with an information page, form and confirmation. Mark claims that differ by market before creating locale variants.
A French headline cannot make an English-only registration process a French service. Test the real action and note what must be fixed before the new language can be advertised as available.
2. Separate Fluent and interface i18n
Fluent concerns localized content values, while Silverstripe’s internationalisation features support translated messages in code and templates. A visitor may see both systems on the same page, and reviewers should not assume a page translation changes every button.
List titles, descriptions, menu labels, validation errors, notification emails and third-party text. Assign each string to content editors, template maintainers or an outside integration. Keep source identifiers and placeholders intact.
If a page body is German but its search error is English, the correction belongs to the search component or message catalogue. Moving the English error into page content is not a sustainable fix.
3. Confirm installed releases
Fluent documentation and integration details vary across CMS and module releases. Before applying tutorial instructions, identify the actual Silverstripe version, the Fluent module, related extensions and any custom publishing behaviours.
Use staging to test one ordinary page and one custom DataObject. Record what works before touching domain routing or public pages. Check official compatibility notes and installation requirements for the deployed stack.
A successful installation is not evidence that all custom content types have become translatable. The developer must still verify field selection, relations and public output.
4. Set up a locale register
Choose language and regional codes because they represent real audiences and maintainable editorial distinctions. A generic French edition may not be suitable for a locally regulated service in Canada or Belgium.
Record each locale’s code, display name, default source, target reviewer, URL, scope and readiness. Decide whether multiple regional variants need distinct content or can share a language edition with clearly qualified operational facts.
Avoid publishing empty language pages to make the site appear internationally complete. A supported locale is a technical possibility, not proof that its public content is available.
5. Explain shared logical record identity
Fluent’s documented model keeps one logical object while storing localized values against that identity. A page does not need an unrelated new record ID merely because its heading or description is translated.
Teach editors which properties identify the underlying event, person or resource, and which properties are language renderings. Review related records and external IDs before cloning anything. Use supported editor tools for inspection.
Duplicating a course record to create a Spanish title could create two courses in an integration. The content should normally remain attached to its intended source record where the application’s model supports that approach.
6. Understand localized storage
Fluent stores localization data for eligible models in associated structures, including arrangements for versioned records. Editors do not need to modify those tables; they need to understand that an object’s current locale selects the relevant values.
Compare the same pilot object in two locales using supported CMS or developer views. Record the stable ID, localized fields and fields deliberately shared. Check that each version presents the correct fact to its audience.
Do not fix a misleading localization by making unreviewed direct database changes. Trace the configuration and publishing workflow to preserve reliable history and data relationships.
7. Classify fields before bulk translation
A model may contain human-language prose, persistent identifiers, measurements, prices, dates and links. Translating every field is wrong, but assuming every field should remain shared can also hide essential information from visitors.
Create a field matrix: localized text, shared identity, regional facts and derived values. Include an example and responsible approver for each type. Review high-risk legal or safety fields separately.
Changing a reference code can break integration. Leaving public instructions in the source language can undermine accessibility. Good configuration protects both technical meaning and reader comprehension.
8. Localize custom DataObjects
Events, venues, biographies and service records may live in custom DataObjects instead of ordinary page text. Their localization requirements must be confirmed individually, including any related values shown in shared templates.
Inventory the high-traffic types and test a sample object in each active locale. Developers should confirm where Fluent extensions apply and how relations resolve. Editors should review the actual rendered record.
A French event page may still display an English venue notice because the venue is a separate object. Fix the venue’s appropriate localization path rather than pasting duplicate text into every page.
9. Preserve linked data
Relationships to other records should continue to identify the same real-world resource after the visible name changes language. A local edition may show different words without creating a different event, item or person.
Test the destination of every related-card link in the pilot. Check IDs, displayed names and target URL. Mark records that genuinely differ by region and validate their correspondence rather than assuming identical labels.
An accurate translated link label that opens the wrong booking event is a serious failure. Verify the destination and action, not only its surrounding sentence.
10. Plan inheritance and fallback
Fluent can supply values from another locale where the requested translation is absent, depending on configuration. This can preserve useful content but may produce pages that mix languages without clearly announcing the limitation.
Define permissible fallback by field and consequence. Language-neutral images may be shared, while consent clauses and safety warnings should require full review. Test complete, partial and missing translations deliberately.
A French URL containing English contractual terms should not automatically be described as a finished French page. A functioning technical fallback can still be an editorial failure.
11. Test fallback after publishing
Fluent’s documentation describes important published-localization behaviour, including copied values in the locale’s live state. A later source edit may not appear in every published translation merely because fallback was previously used.
Publish a staging translation, change the default-language field and inspect the target public page before and after the documented update process. Record who must approve the new local value.
Opening hours and eligibility rules are especially vulnerable to stale copied data. A clear change register is safer than assuming every published language automatically inherits an updated source.
12. Learn draft versus live stages
Many Silverstripe sites use versioned publication. The localized value visible in the editor can differ from the live version served to visitors. Saving a draft and publishing an approved translation are separate acts.
Create a target-language edit, save it without publishing and compare backend and public output. Then publish through the site’s intended workflow and verify the exact public URL without administrator permissions.
If old English copy remains visible, check stage, locale context and cache before rewriting an already correct target draft.
13. Use localized copies deliberately
Starting a translation from copied source structure can save effort, but copied English text does not become French content by existing under a French locale. The project needs a clear unfinished status.
Choose which fields may be copied, which should inherit, and which must be verified independently. Let reviewers see source context without silently treating machine- or copy-generated text as approved publication.
A large collection of copied pages can inflate apparent language coverage while offering little practical comprehension. Release complete journeys rather than bulk placeholders.
14. Map domains and routes
Fluent can support locale-associated domain configuration. Routes must be designed with redirects, certificates, stable deep links and realistic visitor behaviour in mind, not just a language flag in the header.
Create a table of each locale’s domain, homepage, sample nested URL and expected redirect behaviour. Test direct access through different browsers and preferences. Coordinate with the site’s deployment and proxy setup.
A locale page that works only after entering through the default homepage may be inaccessible to external links and search crawlers. Public URLs should work directly.
15. Respect explicit language choice
A browser language preference can be a useful hint but is not proof of the language someone wants for a specific document. Explicit selection and direct URLs should remain understandable.
Test a German deep URL in an English-language browser, a returning visitor with a saved preference and a private session. Record the intended precedence of URL, cookie and browser headers.
Automatic redirects that override a deliberately selected language can trap bilingual users and hide public pages from inspection. Provide a visible way to change language.
16. Translate reusable template messages
Buttons, breadcrumbs, loading states and validation messages may come from templates and modules. Silverstripe i18n is the appropriate conceptual layer for those code-managed strings, separate from Fluent page fields.
Inventory recurring messages with screenshots or context. Preserve message identifiers, variables and intended plural forms while translating their visible words. Test the component where the string appears.
Hard-coding translated text into one shared template can accidentally replace language-specific behaviour across the site. A reusable message should remain connected to its proper locale.
17. Protect dynamic placeholders
Runtime text can contain prices, names, dates, quantities and destinations. Their placeholders and data types must remain intact even when the target-language word order changes.
Provide translators with realistic examples of the final rendered string, including long names, singular and plural counts, unusual figures and relevant time-zone rules. Verify each live message.
A fluent-looking text missing a price or deadline variable may mislead a visitor more seriously than an awkward expression. Test outputs with data, not just strings in isolation.
18. Include forms and emails
The reader journey often ends with a submission, payment or confirmation managed by a different part of the application. A translated landing page is insufficient if the action remains unreviewed.
Inventory labels, help text, consent notices, errors, success pages, transactional emails and attachments. Test both valid and invalid submissions with fictional data. Verify regional rules separately.
A French registration page that emails incorrect English cancellation conditions is not ready. Fix the responsible form or integration rather than placing an apology in an article.
19. Check assets and documents
Photos may be reusable, but diagrams, PDFs and videos can contain embedded language. A public page should describe a linked resource truthfully and not imply it has been translated when it has not.
Record actual file language, caption, alt text, revision date and owner. Review linked documents as part of the task. Provide target-language alternatives for essential instructions where possible.
A download labelled ‘Guide français’ but containing an English-only safety sheet is a concrete failure of communication, regardless of the page body’s translation quality.
20. Use accurate localized links
Menus, related records and internal links must lead to real destinations in the requested language. A translation may change a visible link label while leaving a source-language destination or a stale slug.
Test every important link from the pilot homepage through the final action. Use stable content relationships and documented routing rather than guessing target addresses by replacing URL prefixes.
A language switcher returning visitors to an unrelated homepage may be technically clickable but discards the subject they sought. Define an honest fallback for missing equivalents.
21. Localize metadata honestly
Page titles, descriptions, canonical URLs and hreflang relationships need to match the actual published language and topic. These outputs may be controlled by SEO modules or templates rather than Fluent alone.
Inspect the public document head, response code, sitemap and language alternate links. Only associate genuine, published equivalents; do not fill a complete language matrix using unrelated homepages.
An English fallback page behind a Spanish URL is not automatically a substantive Spanish translation. Search metadata should never imply a language edition contains content it does not provide.
22. Test readability and accessibility
Translated text can expand, wrap or require different script support. A visually attractive source-language design may develop clipped buttons, inaccessible labels or unreadable documents in another locale.
Inspect heading structure, keyboard focus, screen-reader language, alternative text, form errors, mobile layouts and zoom. Include translated strings longer than their English source when testing reusable components.
A truncated German submit label can hide the action from users. Repair the component rather than removing important meaning to fit a narrow box.
23. Establish an editorial change register
Source pages keep changing after launch. A price, opening hour, legal statement or scientific correction must reach each affected locale even when the CMS stores related language values under one logical record.
Record the source ID, revised field, importance, target languages, review owner and publication date. Give urgent factual corrections a clear pathway and separate them from lower-risk style edits.
A stale published translation can remain convincing but wrong. The register should let editors identify exactly which language versions need attention without recreating the whole translation.
24. Run a meaningful release gate
A multilingual release is ready when readers can understand accurate content, follow relevant navigation and complete the promised action. The number of translated fields is a poor substitute for demonstrated access.
Check the source revision, approved target, public locale URL, related objects, forms, documents, accessibility, redirects, search metadata and rollback plan. Re-run the test signed out after publishing.
The lasting measure of quality is what happens after the next source change. Assign an owner to monitor ongoing revisions instead of treating translation as a one-off export.
Worked example: a multilingual workshop
The centre begins with a reliable English journey: a programme overview, eligibility statement, equipment checklist, registration form and email confirmation. Editors list the authoritative facts and separate universal scientific information from local operational rules. They record what the French edition can honestly promise and appoint a fluent reviewer as well as a programme specialist. The development team checks CMS and Fluent compatibility and establishes the intended French locale route in a staging environment.
The programme page keeps its logical content identity while its public name and description receive French localized values. The registration record and venue DataObject are examined separately to verify that related text appears in French without creating a different underlying event. Editors translate buttons and validation messages using their owning software mechanisms; they do not expect Fluent page fields to replace template localization.
The team then tests a partial translation and the configured fallback. It publishes a reviewed target and updates the English source opening time. If the target continues displaying an earlier published value, the team follows the documented review-and-republication process. The source-change register records the correction and the French public version checked after release. This exercise matters more than assuming an inheritance feature will prevent stale factual guidance.
A signed-out French-speaking reviewer enters through the intended domain, follows navigation, opens the accessible checklist, submits an invalid test form and then completes a valid test registration. They inspect confirmation emails and links, canonical URLs, alternate-language metadata and mobile layout. When an attached resource is English-only, the page labels its limitation rather than claiming a translation. The finished release is a coherent service journey, not a set of copied page titles.
Diagnostic cases
A translated draft is not visible to visitors
Check locale context, versioned publication state and cache before rewriting the approved target text. Reproduce the problem using an exact public address and a testable reader action. Compare the backend’s current value with signed-out public output and determine which component owns the discrepancy. After repair, repeat the complete journey so that a corrected string does not conceal another broken step.
A source change does not reach the target page
Inspect Fluent’s live localized values and the documented published fallback behaviour. Assign an explicit target-language review and publication action. Reproduce the problem using an exact public address and a testable reader action. Compare the backend’s current value with signed-out public output and determine which component owns the discrepancy. After repair, repeat the complete journey so that a corrected string does not conceal another broken step.
A related event or venue remains in English
Verify the associated DataObject’s localization configuration and the public template’s locale-aware resolution. Reproduce the problem using an exact public address and a testable reader action. Compare the backend’s current value with signed-out public output and determine which component owns the discrepancy. After repair, repeat the complete journey so that a corrected string does not conceal another broken step.
A locale domain loads the wrong language
Inspect domain mapping, redirects, browser preferences, reverse proxy and direct deep URLs. Fix the routing layer rather than changing prose. Reproduce the problem using an exact public address and a testable reader action. Compare the backend’s current value with signed-out public output and determine which component owns the discrepancy. After repair, repeat the complete journey so that a corrected string does not conceal another broken step.
Forms show English errors after the page is translated
Trace the messages to code-level i18n, custom form templates or external integrations. Test both success and failure cases. Reproduce the problem using an exact public address and a testable reader action. Compare the backend’s current value with signed-out public output and determine which component owns the discrepancy. After repair, repeat the complete journey so that a corrected string does not conceal another broken step.
Four-week implementation plan
Week one: inventory audiences, existing locales, CMS versions, source ownership, custom DataObjects and public user tasks. Define the target-language scope, protected identifiers and region-specific factual claims. Choose one pilot that includes a linked record, form and document. Record its public source URLs before changing routing.
Week two: configure Fluent on staging and translate the first content and template fields. Test localized storage, versioned drafts, publication, missing-value fallback and source edits after target publication. Inspect custom records and domain routing. Do not scale until the behaviour is documented for the actual site.
Week three: complete fluent human review, including local factual conditions, asset labels, forms, errors, confirmation messages and accessibility. Check responsive layouts, internal links and target-language search. Record reproducible defects by URL and assign them to editorial or technical owners.
Week four: verify redirects, canonical URLs, alternate-language relationships, sitemaps, public indexability and source-change tracking. Publish only the approved complete journey, inspect signed-out production output and designate a reviewer for future changes. Expand to more pages when this release procedure is repeatable.
Frequently asked questions
Does Fluent automatically translate articles?
No. It provides localized content infrastructure. Human translation and review remain necessary.
Are locale versions entirely separate records?
Fluent uses shared logical identity with localized field data, subject to the installed model configuration.
Why does a saved target value not show publicly?
The target may remain a versioned draft or be affected by locale routing or cache. Verify the live state.
Does fallback always track future source changes?
Not necessarily. Published localized values can have distinctive copy and fallback behaviour. Test the actual installation.
Can Fluent use language-specific domains?
Yes, relevant configuration is documented. Test deep links, redirects and public addresses carefully.
Do custom DataObjects localize automatically?
Their model configuration and field choices must be checked and tested.
Who translates validation and email messages?
They may belong to Silverstripe i18n, forms or external services rather than Fluent page content.
What is the best final quality test?
Ask a target-language reader to complete an important real task from a public URL, including forms, documents and confirmation.
Advanced fieldwork and editorial case studies
Advanced case 1: translate a field without losing a shared identifier
A conservation centre stores its programmes with a stable booking code, public title, course description, price and language-specific instructions. The record’s booking code is not a sentence; it identifies one programme to downstream software. The title and description are human-language fields that should normally be localized. Prices and conditions need a separate decision, because converting the currency notation is different from deciding that the programme has a different price in another market. A sound field matrix makes these distinctions explicit before translation begins.
Test the model with one English event and one French representation. Confirm that the visible title, introductory explanation and action label are natural French, while the booking integration still receives the intended code. Check the published target, not only its editor fields. If a regional team needs a separate event with another time and booking code, document that as a distinct operational item rather than disguising it as a pure language translation.
Advanced case 2: investigate an inherited value
An editor opens a German page and sees a paragraph in English. The simplest reaction is to translate it manually, but a useful diagnosis asks whether the field is configured for localization, whether a German value exists, whether a fallback rule supplies the English value and whether the page is displaying a previously published copy. These cases lead to different lasting corrections. A missing translation is an editorial task; a misclassified field is a developer task; an unexpected published value is a workflow or configuration task.
Write down the target locale, source record, field name, current draft and live output. Repeat the request while signed out. Review the site’s documented fallback behaviour using a small control record before changing the page. If fallback is appropriate for low-risk description text, label its limitations in the editorial register. If the field communicates important eligibility, consent or safety guidance, require a reviewed target-language value before releasing the page.
Advanced case 3: make a source correction visible everywhere
A workshop organiser changes a departure time after all three language editions have been published. The source editor corrects the English page, but the published French and German values may not automatically change. An editorial team that relies on assumptions about inheritance can leave visitors with conflicting information for days. The important distinction is not between an original and a translation in the abstract; it is between the factual version each audience actually receives at a particular public URL.
Create a source-change notice with the record ID, old value, new value, reason, target locales, priority and responsible reviewers. Publish the corrected source through the normal process, then inspect every affected target’s live result. Approve any necessary localized amendment, publish and retest. Retain the source revision and public-check time. This small practice prevents a technical feature from becoming an excuse for unmanaged factual drift.
Advanced case 4: release a locale on a separate domain
An organisation decides to put French pages on a different hostname. This decision involves more than adding French text: certificates, redirects, canonical URLs, cookies, forms, analytics and external links can all change behaviour. A reader may arrive through a direct event link, not the homepage, so testing only the root address gives false confidence. A domain-based locale should be a stable public destination that can be bookmarked and reached independently.
Prepare a route matrix with a root URL, two nested pages, a form confirmation and an old bookmarked path. Test each address in a clean browser and compare the final URL with the intended locale. Then test with language preferences that conflict with the address. Review canonical and alternate-language markup and verify that no automatic redirect silently erases the reader’s explicit choice. Keep rollback instructions in case the new domain begins sending visitors to the wrong edition.
Advanced case 5: localize a related record without duplicating it
A programme page references a staff profile and a venue. Translating its page description does not guarantee that the related records will appear in the requested language. The staff member’s persistent identity may be shared, while their public biography needs translation. The venue’s map coordinates may remain universal, while accessibility instructions and arrival notes can require local wording. Treating the whole relation as one indivisible string prevents accurate configuration.
Inspect the record relationship and the localized fields of each referenced object. Verify the public view under the French locale and follow the link to the actual related record. If a component displays source-language data, determine whether the custom object was configured for localization or the template selected the wrong locale. Avoid creating duplicate people and venues simply to repair a presentation defect. A stable identity with correct localized display information is more maintainable.
Advanced case 6: separate a translation correction from a data correction
Suppose a published German workshop page says that registration closes on Friday, while the source page now says Thursday. The problem may be an outdated translation, a source error, a regional scheduling difference or a templating issue that formats the date incorrectly. Calling every discrepancy a mistranslation can send the team down the wrong path. Each category has a different owner and may require different evidence.
Compare the original data source, source-language public page, target-language stored value and target public output. Ask the programme owner to confirm the authoritative deadline. If the source is wrong, correct it before translating that mistake into other languages. If the target is stale, mark it for urgent editorial review. If the data is accurate but formatting changes its apparent day, repair the locale or time-zone logic and test representative boundary dates.
Advanced case 7: build a useful multilingual terminology list
A glossary is most valuable when it contains real concepts that readers repeatedly encounter. For a conservation centre, those might include ‘sampling point’, ‘fieldwork permit’, ‘habitat assessment’ and ‘accessible entrance’. Translators need definitions, context and examples as well as preferred words. A bilingual pair without explanation can become misleading when one English expression has multiple senses or several legitimate equivalents in the target language.
Build a short glossary from the pilot journey instead of exporting every noun from the CMS. For each term, record its meaning, approved target expression, context, source authority and whether it can vary by region. Ask a fluent reviewer to apply the terms naturally within full sentences. Preserve proper names and technical codes where required, but allow grammar to follow the target language. Review the glossary after users or editors reveal ambiguity.
Advanced case 8: check localized site search
An international edition may be technically available yet difficult to discover through the website’s own search function. A French reader may search for a commonly used term while the index still emphasises English page content or source-language metadata. Search implementation varies with modules and custom code, so translation editors should test the visitor-facing results rather than assuming that localized pages become easy to find automatically.
Prepare five realistic queries for each pilot language, including a technical term, a plain-language synonym, a proper name, a frequently misspelled phrase and a service action. Record the expected published pages and run the searches as an ordinary user. Inspect result titles, snippets and URLs, and make sure drafts or restricted records are not inadvertently exposed. Assign any ranking or filtering defect to the search owner, supported by the exact query and expected outcome.
Advanced case 9: review a translated document for accuracy and accessibility
A downloadable fieldwork guide can carry more risk than a short web paragraph. It may include measurements, tables, diagrams, emergency numbers, hyperlinks and revision dates. A translated title on the download card says very little about the real file. The document itself must be checked for language, factual accuracy, accessible reading order and the relationship between instructions and illustrations.
Open the complete target-language file and compare significant steps with the authoritative source. Check measurement units, numbers, legends, links, image descriptions and visible document revision information. Ask an appropriate reviewer to verify safety-related instructions and regional assumptions. Test the document with a keyboard and relevant assistive technology where practical. If the required translation does not exist, label the source-language download honestly; do not let a translated link disguise the limitation.
Advanced case 10: audit forms beyond the first page
Many websites look translated until a visitor submits a form. The visible form heading may be stored in Fluent, while the validation messages, consent text, third-party payment screen and email confirmation come from other mechanisms. A multilingual release therefore requires the team to follow the action through to its final state. A success message in the wrong language can be confusing; an incorrect consent or cancellation clause can have substantial consequences.
Test a valid submission and at least two errors in each target locale. Verify field labels, accessible error names, consent, the final redirect, confirmation wording and any attachments. Use fictional test data and avoid collecting real personal details. Record which system controls each message. If a downstream application cannot support the promised language, the public page should not overstate its availability while the organisation decides whether to translate or clearly qualify that part of the service.
Advanced case 11: verify the release after cache and deployment
A successful edit is not always a successful public release. A reverse proxy, application cache, old template bundle or misunderstood draft status can continue serving stale content. This can create especially confusing multilingual errors because a target-language editor may see current values in the CMS while visitors receive an earlier version. The correct response is to compare specific observable states rather than repeatedly editing the translated paragraph.
Record the intended target revision and a precise public URL. Inspect it signed out, ideally from more than one browser or network condition if practical. Check the language, key facts, page status and relevant cache behaviour. Ask the technical owner to correct the serving layer if necessary, then rerun the complete user journey. Keep a brief record of the mismatch and resolution so that future releases test the same failure mode.
Advanced case 12: judge whether a translation is ready
The final question is not whether every field has some text. It is whether a person who needs the target language can make an informed decision and complete the promised action without encountering hidden source-language dependencies or incorrect facts. An accurate but unpublished translation is not accessible. A fully published but misleading version is not useful. A robust release combines factual approval, language quality, coherent navigation, working services and a verifiable public URL.
Use a release checklist that names the source revision, target reviewer, domain approver where required, published locale, current data, major links, forms, documents, accessibility tests and SEO relationships. Fail the release if an essential action cannot be completed or a high-consequence claim is unverified. After publishing, ask a reviewer to complete the journey again. Assign ownership of source changes so the quality remains real next month, not only on launch day.
Official documentation and connected learning
Check the installed Silverstripe and Fluent versions against official documentation. In particular, verify localized storage, versioned publication, fallback and domain routing with a real pilot record. A reliable international edition needs accurate target-language content and repeatable public verification.
Silverstripe CMS 6 — Content localization with Fluent
Silverstripe CMS — How Fluent works