Published by Mijingo
movie icon image

EE Insider Blog

Spend your time learning and developing sites with ExpressionEngine and we'll use this blog to keep you informed of all the news related to ExpressionEngine and CodeIgniter.

» Read more in the Archives.

» Have a tip? Send us your EE news.

Learn ExpressionEngine Today

Over a series of 8 videos, watch and learn as Ryan builds an entire ExpressionEngine website from beginning to end. Get started now.

A Comparison of Localization Solutions for ExpressionEngine

This is a guest post by Tim FitzGerald and is being published along with his detailed chart of localization add-ons for ExpressionEngine. Bookmark both pieces so you can refer to them during your next project. –Ryan

A recurring use case for an ExpressionEngine site is to provide content in two or more languages. EE’s framework includes the ability to translate its own control panel interface, but it doesn’t offer much help when it comes to the site itself.

This article explores the third-party add-ons that exist and compares their features. It may also help you ask important questions as you plan the development of your site.

Full disclosure: I’m not an entirely disinterested party here. I’ve started writing my own open-source add-on, listed my objectives, and wanted to see how it stacked up. I decided to share this list because I thought it could also help others evaluate the different options and find the tool that best meets their need. My goal was not to compete but complement the marketplace; you can find out more on my add-on’s wiki.

Specifically, I looked at:

  • How they decide what language to serve (taking into consideration Google’s recommendations, among others);
  • How they handle URLs (important for SEO in your target language overall);
  • How they translate strings (i.e. form labels, banners, tag lines, and other content that isn’t served from entries); and
  • How they manage translated content.

My results (see my comparison table) are based on documentation found online, personal experience when I have some, and in the case of open-source add-ons, inspection of the code. I invite add-on developers and users to report any inaccuracies to @tfitzgee and I will correct.

Remember that there is no one solution; it’s all a question of how important each of these factors are to you, how you like to resolve them, and the time and money you (or your client) are willing to invest.

We’re All Getting it Wrong to Some Degree

One thought that occurred to me while finishing up this census, and was reinforced by a recent article by John Faulds, is that we’re all talking about multilingual (actually most EE developers write “multi-lingual” with a hyphen)… Should we not instead be talking about localization (L10N)?

This is more than a semantic argument. Multi-language assumes that the only variation you need to address is language. But ask a New Zealander if American content is appropriate for him? Maybe yes, if you’re reading reviews on technology products; maybe not, if you’re looking to buy. Currency, store locations, timezones, units of measure (metric vs US/Imperial), legal framework, cultural reference, even spelling… these are all facets beyond just language that may lead you to having different content for different contexts. That is localization. (Or localisation with an s, if you’re a Kiwi.)

Faulds demonstrates these multilingual tools can serve the purpose of L10N, to some extent, but it’s not fully there.

The assumption may be that if you are so concerned about localizing your content to that degree, you should be running multiple sites with different templates altogether. Perhaps so. But I contend that there are scenarios where it makes sense to have it in a single site, and we should be designing our tools with that expanded goal in mind.

Two Real Turnkey Solutions; You Get Your Money’s Worth

There are, to the best of my knowledge, two add-ons that come close to delivering the whole package: Transcribe and Publisher. Both have their shortcomings, but none of those are so great as to rule them out. Both, it should also be said, are paid add-ons. I think that’s fair for the value of the polishing they provide.

I can personally recommend Transcribe, having used it for two sites now. I have not used Publisher as of yet, but it looks promising, and if it’s as complete and if the workflow aspect works as well as advertised, it offers you more than Transcribe for your dollar.

Both of these solutions are database-centric. That is to say any new strings or variables are not in config files. Not that’s a bad thing per se, but a design consideration as your sites development goes through its workflow.

The only gap is that neither of these cover the other localization needs beyond translating strings and entries. You’ll need something else to convert numbers and dates.

Other Add-ons Can Fill the Gaps Left in Native

When it comes to freeware, there’s a hodgepodge of solutions out there. I’ve covered the main ones in this table, but there are other add-ons that can help, like Low Variables and Republic Variables.

To use most of these add-ons, you’ll need a way to tell what language to serve, and you’ll need to structure your entries. The more notable approaches:

All of these approaches you creating subdirectories for each language at your site’s root folder with duplicates of EE’s index.php, setting a language global variable. With EE 2.8’s template routing you may have a way around this.

More Reading

Posted on Jun 08, 2014 by Tim FitzGerald

Filed Under: EE Add-ons

GDmac — 04:07 on 06.12.2014

I like Carl’s approach, having a field where you set the language. You can even add another relationship kind of field to connect the entries for the different languages.
2.8 template routes might be a first step, i rather look at resource router by Rob Sanchez, as it allows a more fine grained control on the segments at a lower system level. It’s interesting to see more solid routes (pun intended) to translation and multilingual solutions.

Tim FitzGerald — 06:06 on 06.13.2014

Thanks for sharing your thoughts.
I’ve used Playa in the past to link alternate-language entries before. It’s a technique that works well when you have only two languages to toggle between; more than that and you need either more fields or perhaps a grid. It also generally means you have to link both ways, whereas using an out-of-the-box solution like Transcribe or Preview will take care of that for you.
Since writing this article I haven’t made a site in 2.8, so I can’t speak to template routes but it looks promising. Resource Router is a good tool and I don’t discourage using it; I simply chose not to go into it because I had to set a scope to my article and so kept myself to add-ons designed specifically for multilingual/localization.

Tim FitzGerald — 06:14 on 06.13.2014

Thanks to Ryan Irelan, not only for agreeing to host this in the first place, but for making some quick updates to the table following BoldMinded’s feedback on features for Publisher. There was a lot of research involved off and on in my spare time over the past few months putting this together, so I was bound to get a couple of things wrong. What’s important is that we identify and correct them.
We know that things change. Ryan and I have talked about wanting to keep this table updated as a living document, so if you’re an add-on developer and you have changes to highlight for us, please do so either by Twitter (@tfitzgee) or on this comment thread. Thanks.