After meself and himself of Smartling met at the Websummit, I wanted to look at a forthcoming Smartling self-service offering suitable for software developers. When Jack Welde (@jwelde) (i.e., himself) gave me the nod, I got to it, taking the opportunity to reflect on the developer experience and enterprise translation, generally.
Offering translation “as a service” for developers faces two related issues: how to make it easy for busy developers to get stuff translated without disrupting their core activity, and how to build a business model out of all that. My main concern is the developer experience, but it’s obvious the Smartling startup puck is heading towards the enterprise.
Exploring Smartling
Smartling is a rising star, with 65 million USD in funding; regarded as the industry disruptor to watch in 2015.
Smartling packs a REST-like API to integrate with, and connect to, development environments for software resources of all sorts, web-based content, documentation, and so on. From a developer perspective, a PaaS ability to use APIs to hook up translation to IDEs, dev environments and source control systems, is a must-have feature. Eliminating on-premise hardware and consulting set up time offers more ROI and productivity.
It was easy for me to get going in the Smartling browser-based UI, uploading a Java properties file, and exploring the features.
Smartling uses a very cool Context Capture API to associate visual context to HTML content for translation. Connecting a rendered UI to translatable resource string IDs (offering a preview of the translation into the bargain) makes for a better final deliverable. Behind-the-firewall HTML content can be similarly contextualized using the Chrome Context Capture extension.
Previewable source and target strings shown in context during translation
Externalization of content from code is key to having developers on your side. Most IDE and file formats have i18n/L10n support to abstract away translation risk, so Smartling has a great baseline to enable quality translation and development productivity alike, the translator UI protecting valuable coding goodness from damage during the source-to-target language change.
Smartling provides automatic extraction of a glossary for review, a way to include style guidance, and offers features in the translator UI to define and move about patternized placeables, dashboard reporting, and so on. Mucho flexibility, if you need it.
Extracted glossary entries
Smartling also enables customization of the translation workflow to suit business needs. For example, different translation workflow steps might be tailored to involve particular stakeholders before the translation is finalized (enterprise stakeholders, beyond end users, are that “political third rail”; forgotten with disastrous results).
Easy customization of translation workflow steps
I conjured up my own translations, but Smarting integrates with human and machine translation for a quality result.
What developers care about is a productivity solution in the cloud that resonates with their world of work, and that worked for me. I liked the Smartling approach. It was easy to set up, to integrate into processes, to see stuff translated in context, and to get valid translated files back for the build or deployment stage.
Understanding Developers
The “translation as a service” model is not new. GitHub, APIs, Python, Ruby, Node.Js, PaaS, and so on, are now standard parts of the developer lexicon. Yet, the localization industry continues to play catch up with developer community happenings, whether they be FOSS-based or corporate.
Developers are not translators, and don’t want to be. Empathizing with the developers’ world is the foundation for ideating together on smart solutions. Smartling has already done some awesome developer outreach such as the LinguaHack event in Kiev (others, please take note).
Smartling LinguaHack Hackathon in Kiev, 2014
So, Smartling looks like a fine solution from the developer perspective; one for builders to get apps, websites and documentation translated easily and out there into the global market. It is, of course, an on-going story.
Smartling nails the notion that “one size does not fit all” when it comes to translation for developers, and from my explorations the solution hits the mark with cloud-based developer productivity and usability.
To use all Smartling features optimally is really an enterprise-level undertaking. Developers will never rush to attach contextual images or add descriptive notes to strings. Reviewing glossary extractions, creating translated terminology, and so on, are not developer competencies. Such things require a team: localization managers, translation coordinators, terminologists, information professionals, and others working further upstream in the software development lifecycle.
Enterprising Solutions
Enterprise translation requirements now go far beyond app resources, HTML sites, and documentation. It’s a complex business, and comes with critical performance, scalability and security prerequisites. Sure, it’s unglamorous, but as Oscar Wilde says, it’s better to have a permanent income than to be fascinating.
Enterprises need to see real ROI and have incentives to move from current solutions. This is true of on-premise to SaaS adoption generally; there are other constraints too. Like user experience generally, making that decision “depends”.
So, I’ll be watching where that enterprise translation puck goes in 2015 for Smartling, and for others.
Tags:
API,
Cloud,
Context,
Developers,
GitHub,
Jack Welde,
linguahack,
PaaS,
Smartling,
Startups,
translation,
WebsummitUltan Ó Broin (@localization), is an independent UX consultant. With three decades of UX and L10n experience and outreach, he specializes in helping people ensure their global digital transformation makes sense culturally and also reflects how users behave locally.
Any views expressed are his own. Especially the ones you agree with.
