Posted 23 June 2016

Learn more about SilverStripe Fluent

Written By : Marco Rosano Visit Marco's LinkedIn Profile

Stuart Gonsal founded Wolf in 2014. He presents extensively to industry groups and is on the Advisory Committee for Swinburne University’s Masters of Commerce (International Business).

The SilverStripe Fluent module allows websites to manage localisation of content, and navigation between localizations, in a similar fashion to Translatable or Multilingual.

A URL prefix distinguishes locales, that of the selected locale, at the start of all page links. E.g. would be the NZ English version of a page. This could be localised into Maori at

Fluent also integrates nicely with Google Sitemaps module, linking localizations for each page as per Google’s internationalisation guidelines.

Fluent also supports the use of multiple domains to assist in locale filtering (e.g. a .com for English, and a .cn for Chinese). A simple CMS filter provides the back-end control.

How the SilverStripe Fluent module works

As opposed to Translatable, which manages separate Site Tree objects for multiple localizations, Fluent stores all localizations for properties on the same table row.

This method has the following benefits:

Seamless integration with other modules and extensions (such as Versioned)

Allows for installation easily on existing websites

Minimises the amount of special case code to handle localizations; A page has the same ID no matter the current locale!

The simplicity of the single-table method means that any object can be easily and transparently localised, even non-Site Tree Data Objects.

There is only ever one sitemap, so the page hierarchy doesn’t need to be duplicated for each additional locale.

Fluent has a couple of built-in rules for determining which fields to localise, but these can be easily customised on per-object bases (or even by customising the global ruleset).

When querying data, the SQL is augmented to replace all SELECT fragments for those fields with conditionals; It will detect if a value for the localised field (such as Title_en_NZ) exists, and use this if it does, otherwise using the base field (Title) as the default. When a Data Object is written, the inverse is performed, ensuring that the field related to the current locale is correctly written to.

Unfortunately, there’s currently no localisation mechanism for Site Tree URLs (for the sake of simplicity). 

Creating translations

When creating a translation for a page in the CMS, it helps to know how the current and default locale relates to each other, both when creating, editing, and publishing a record.

It’s ideal, but not always necessary, to create a record in the default locale. By default, all translations of that object will inherit the value entered in and saved in the default locale.

If a record is NOT created in the default locale, then the default value of that record will be the value last stored in any locale. This behaviour may appear confusing unless this fact is understood.

Saving a record in any locale will create a saved state for that locale, meaning it will no longer inherit the default value, but it’s always easier to set a good single default than to edit the record in each locale individually.

This article was originally published article by Damian Mooyman at

Share this article
  • Share on twitter
  • Share on  facebook
  • Share on linkedin
  • Share on google-plus