Internationalization and the Homebrew CMS

ShareShare on Facebook8Share on LinkedIn0Tweet about this on TwitterShare on Google+0

Over the years, I’ve worked with a lot of companies that have built their own content management systems (CMS) in-house. There’s always one thing you can count on: these systems are monolingual. No in-house CMS effort that I’ve ever seen has incorporated multiple languages from the beginning.

Fact is, these projects often don’t have defined and planned beginnings. More likely, they start as smaller projects to provide some ancillary functionality to a website, and they grow over time until they become the de facto CMS powering the entire website. There, growth is less planned, and more organic.

These systems never seem to progress into internationalization. Either the organization decides to go without, or they simply abandon it for a third-party (commercial or open-source) CMS in order to internationalize.

CMS internationalization can be complex

I’ve become more and more convinced that this is because the changes required of a CMS to become multilingual are foundational—they deal with the core, base aspects of a CMS, which are hard to change. Multiple languages essentially constitute another dimension of content, and if this wasn’t planned for at the architecture phase, it’s exceedingly difficult to retrofit.

Instead of content types having simple properties, every single content property must have “depth”—each property must exist in multiple languages at one time… Or not, since internationalizing a certain property might not be required. (For example, a checkbox for “Show Sidebar” is simply not language-dependent.)

Consider multilingual capabilities from the start

Additionally, multilingual websites are rarely binary—they are not simply 100% English and 100% Spanish, for example. Rather, perhaps only selected content is translated. It could be that an organization only translates 30% of its content. (As was the case with a Canadian regulatory agency we worked with—they had strict guidelines on what type of content had to exist in both English and French.)

When this happens, selection rules come into play. Pull Quote Barker Article-01When rendering the site in another language (a language other than the default), what do we do with content that doesn’t exist in that language? Display it in the default language? Hide it? Or do we fall back—if the user requests Canadian French, but we have it in French, is that good enough? Can we specify a language selection list to “fall back” through, in order to find the content in the language we want?

Clearly, these changes are not trivial. They involve almost every part of a CMS—content modeling, content aggregation, templating, editorial workflow, etc. And grafting these into an existing CMS is not a small undertaking. These momentous changes are waiting in the wings to pounce on any hapless developer who overlooks or minimizes them.

If you’re determined to build your own CMS inside your organization, be very, very specific about multilingual capabilities from the start. Will you ever need them? If there’s any chance you will, put them in from the beginning and suffer through the complexity they bring in expectation of the future benefit.

If you’re sure you’ll never need them, skip the work and commit to switching platforms in the future if you ever change your mind.

About the author

LB-Definitive Guide to Website Translation-06102015-FPODeane Barker is a founding partner and chief strategy officer at Blend Interactive. He has been working in web content management since the mid-90s—before the discipline even had a name.

Barker is a veteran of hundreds of implementations, ranging from small marketing sites to massive publishing operations—across nearly every programming architecture and dozens of CMS platforms. He writes about various web technologies, including content management, at and speaks frequently on the content management conference circuit.

ShareShare on Facebook8Share on LinkedIn0Tweet about this on TwitterShare on Google+0