Interesting to see that Facebook has announced the launch of a multilingual composer tool that enables users to post their status updates in different languages so that their friends and followers can see the update in only their preferred language.
This notion of composers is not new, of course. They’ve been around for a while and often encountered in the e-commerce and SaaS space. Amazon lets sellers create, customize, and brand their own online stores for example. What is interesting from a user experience perspective is that composers are part of the emergence of a global citizen developer role, a role that now finds itself responsible for tailoring the language in the UI of cloud applications.
Oracle SaaS Release 10 in Dutch. Language changes can be made with a visual composer tool.
Oracle SaaS Release 10 in Dutch. Language changes can be made with composer tools.
The term citizen developer itself presents some difficulty and in many ways is a contradiction in terms. Nobody seriously expects governments, multinational corporations, and bodies of that nature to hand over their implementation or SaaS customization to “citizens” with basic “Hello, World” programming chops.
Instead, think of citizen developers as more about the empowerment of software owners themselves to make their own modifications, be they branding, extensions, localisation, or translation changes. It’s all about enabling customers to take real ownership of their cloud software, without resorting to making source code changes or needing any real software development skills. It’s a low-code or no-code approach, if you like. In other words, citizen development abstracts away the complexity of programming and integration so that user experience can be tailored to your heart’s desire as if by magic. The tool du jour for the job of making your own digital world? Composers. The very word has an element of artistry to it.
Composers are more vital tools than ever now with the advent of SaaS, be they in the hands of the customers, implementation partners, user experience specialists, or design consultancies who don’t usually have, or need, deep-drive software development skills yet know what the desired result should be.
Sandbox-based composers enable Oracle partners, for example, to make SaaS user experience changes quickly and safely for customers, freeing up their own development resources for more critical tasks. Given that 80% of enterprise software applications require customization of some sort, composers are a key part of the partner world’s implementation and maintenance toolkit.
In the multilingual enterprise space, for example, a partner might be asked by a customer to make language changes across their suite of applications quickly and securely, ensuring that the changes are made in just the right places. That’s what’s happened in one case where Oracle PartnerNetwork member and UX champ central Certus Solutions was asked to change the out of the box German translation for performance to another word shown in Oracle’s simplified UI for SaaS. The customer wanted to use the English word instead. Language is a critical part of the UX; like everything else it must be designed.
German Simplified UI customization done using a visual cloud composer
If you need the word Performance for your user experience; then so be it! German simplified UI SaaS customization by Certus Solutions (now Accenture) using a visual composer tool.
Other examples might be the desire to change all those U.S. English spellings to the U.K. variant; or to make changes in language that reflect how customers actually structure and run their business. For example, employee might be changed to partner. The label My Team is often changed to My Department, a language change that doesn’t even require a composer right away but can be done at the personalization level with just a click and overtype if you have the right security settings! Some previous translations for the word worker have proven problematic in Arabic, Brazilian Portuguese, and French, requiring modification for certain customers (let’s not go there). There are lots of examples where composers could be used to change the language of an application or service.
Autumn? Fall? Who cares! Change the language in the SaaS simplified UI easily with a sandbox-safe visual composer.
What is of interest is that very few of these composer tools use localization industry standard procedures or formats and yet seem the better for it. For example, although language changes are made directly into resource bundles or XLIFF files, they are done so at run-time, eliminating context problems. Composer tools rarely have any complex terminology look-up capability, offer TBX support, have language QA features other than spell checkers, and nor do they use translation memory or support TMX. Why not? Well, these things aren’t needed by customers or partners right now and probably would just complicate things.
Perhaps as composers evolve this kind of “traditional translation” functionality might appear. But only if the customers and partners demand it.
Allowing business users to make a language change themselves is more cost-effective, faster, and more secure solution than doing a retranslation or taking a UX hit by deciding to leave the language as is. The result is a better customer experience, faster.
Will translators find themselves out of a job as a result?