A couple of weeks ago, the TYPO3 Neos core team met in Rosenheim, Germany for a code sprint leading up to the Inspiring Conference. A major feature we wanted to work on (again-again-again) was localization.
The technical concept for how to build in localization for TYPO3 Neos has been underway—and basically done—for a really long time. We only started thinking about the UI concepts about a year ago. Turned out it was a much bigger UX challenge than I had imagined. Quite a lot of research also went into these efforts. A tiny bit of that was blogged about.
So why is localization not about localization in TYPO3 Neos? I’ll get back to that—yet let me first give you a bit of background info and tell some of the stories about why dealing with languages and regional variants in a CMS can make developer heads implode and turn an experienced UX’er into a whining monster baby.
Only care to see the end result? Scroll down!
Getting it right from the start
Localization is now finally getting into to the youngest of the two CMS’s that the TYPO3 community is developing. How could we wait so long with such a crucial feature for an enterprise-aimed CMS, you might ask. The first, simple reason is that we wanted to get it right from the outset.
Releasing a flawed localization UX concept would be entirely unacceptable as agencies and clients would have to struggle with its first iterations and adapt after we’d have gotten it on track. In this case, failure is just not an option when releasing it. Will it be perfect when we release it? No—but the fundamental concept has to be strong.
Many of the guys on the Neos team are from German-speaking countries. This fact gives us a huge advantage since so many of the devs are highly experienced in dealing with content management in places like Switzerland, Belgium and other countries in the region where multiple languages co-exist. What those solutions often have in common are the dreaded cases of fallback.
When a website translated from Deutsch to Schweizerdeutsch is launched in Switzerland, the common approach is to copy the German content and then translate and/or correct stuff for regional differences. But if you have a huge collection of content, you would normally be okay with launching the Swiss version with some of the German content “shining through” to the Swiss audience.
That’s a simple fallback chain (that even I can understand.) But it goes even further. In some cases you can have a 3 or 4 step fallback chain. It’s quite simply a usability nightmare providing the content author an overview of what’s going on with their content. What’s translated and what’s not? How do you test the fallback versions? Many tricky questions turn up.
In many localization scenarios, you would typically use an external translation agency to translate the content and feed that into the CMS. The localization UIs in Neos can then function as a staging environment where editors can tweek the translated content. The importing of translated content into Neos is done using the built-in XML format—or one of the standardized translation file formats using a 3rd party package.
The UX goal:
Make it all about content variants
This is the second reason why the localization project in Neos has taken it’s time. We wanted localization to introduce a user interface that handles all kinds of content variants—or dimensions as we call it internally on the team—in a similar, consistent way. Languages and regionalized content is essentially just that—content in multiple variants. This concept of content variants can be bridged “easily” to a lot of other variants of content.
To name just a few examples of dimensions we regard as variants that can be handled by one, all-embracing user interface pattern:
- Language-versioned content (everything from just Danish—to UK English, US English, Pirate Dutch and the mysterious non-existing language hidden in Neos)
- Personalized content (any kind of personalized content you can think of—there are many variants—including persona-based content variants, allowing you to differentiate content based on personas)
- Device-variants of content (one version for a faculty website, another for its on-campus screens etc)
- Channel-variants (one version of a content chunk for your website, another for an iTunes abstract and another for an aggregated version on another website)
- Regional variants
- Location-based variants (responding to your exact location)
- Time-zone variants (say you’re launching a product at 9:00 AM in all time zones with differentiated messages)
So, your obvious next question is OF COURSE:
Will Neos even be able to let you combine such dimensions? Naturally. And we’ve even designed an interface that makes it fairly easy for an author to see what’s going on in the more complex setups. It’s not going to be as easy as opening your fridge to find the champagne—but it sure as hell is going to be simpler than many other systems I’ve seen.
Why a generic concept?
When it comes down to planning user experiences and actual interaction design for localization—the first obvious choice is to go for a pretty specific interface solution that covers the most important use cases (the 80% basically - and let me assure you, the 20% edge cases of localization could make most interface designers cry and dream of simpler days of having to design a print brochure in high school). A specialized interaction design would let you tailor the interface for “just” localization.
However, one of the most important design guidelines I adhere to in Neos is that I always choose generic solutions over the specialized. Whenever, I can apply framework thinking (all greatly inspired by the devs on the team), I do just that—instead of falling into the trap over doing one, specific UI at a time (think about the mess that would grow into over time!).
Enough talk, show me pictures!
Start building variants—in this case language variants—by clicking the corresponding edit mode (Translation):
Below the editing modes (in the formatting bar just above the view of the website), the user will be able to configure the source version view, enabling you to preview languages, device-versions etc. directly from the Neos interface. This interface provides editors with a way to configure what variant of the content is worked on. Whether you use In-Place editing or Raw Content, the editor can switch languages from here without thinking about translation.
Split-screen is enabled, using our Raw Content editor on both sides:
On the right hand side, you can have multiple variants all connected to one source on the left. The 2 arrows at the bottom will let you collapse the split-screen both left and right, enabling the author to focus on either the source or the variants. The split-screen view is based on our Raw Content editing mode to let editors easily compare content to keep it in sync. For quality assurance tasks (think legal), this will also provide an easy way to spot regional differences etc.
Configure the view—could be just language selection or a combination of device, language and persona-based personalization. This can be expanded in many ways, enabling you to do content variants for different time zones or whatever parameter you can dream up:
This shows the interface for starting the variant for a whole page. Might want to rework the help texts a bit:
Interface for showing the content author that there’s a fallback variant. This gray box on the right hand-side will then let the author decide whether to just edit the fallback (in the fallback language) or make a new variant that matches the current target language:
The plan is to release the localization / content variants UI in TYPO3 Neos version 1.2. A lot of it is already implemented and “just” needs tweeks, QA and finalization—but there are also things that can still be altered. Please do give us feedback on this.Comments