The Localizer’s Best Friend: t()

I’m always on the lookout for software development solutions that are smart, disruptive, novel, and that challenge assumptions to solve a business problem. I recently attended an SF Globalization meetup event in San Francisco hosted by Airbnb. There, I saw localization (and UX) convention stood on its head by something anyone working in developer relations would be proud to evangelize about. It was a great event, dinner was provided for free, and I learned how Airbnb built international product. It was a  story told with honest and candid insight by a multi-skilled team. Very refreshing views were heard, far too many to go into now.

The Airbnb engineering team used Rails, instrumenting a t() (translate) helper method as the foundation of an infrastructure to deliver quality translations. The responses to audience questions, especially to the one if Airbnb used a translation memory, “We use a normal SQL database….”, made me smile. I was immediately reading up more about the Rails i18n module.

The t() solution was built to meet a need and to suit the Airbnb business model. It handles plurals, context, locale changes, and so on.

Here’s the t() method process overview:

t() method used to build the Airbnb translation tool

t() method used to build the Airbnb translation tool

Here’s how the tool provides context for translators, using screen shots:

Screen shot capture in tool for translator context

Screen shot capture in tool for translator context

It’s good for handling singular and plural and other language semantics, too:

Singular and plurals in t()

Singular and plurals in t()

And of course, where would user experience be without enabling locale specifics:

t() handles locale variants, such as terminology changes

t() handles locale differences, such as terminology differences.

The event also revealed that Airbnb relied on community translation and Google Translate as a bootstrap translation tool, that’s another day’s blog. I am indebted to the Airbnb team for the use of these images here. I cannot share all the slides shown in the meetup, but you can read more about the t() method and how it took Airbnb into the Japanese market.

If you see Airbnb on the agenda at localization or UX industry events, check it out. Inspiring stuff. And, they must be doing something right, as they’re poised to become the world’s biggest hotelier

 

 

Localization Unconference – Canadian Edition

Oleksandr Pysaryuk (@alexpysaryuk) shares the insights on the organization, takeaways, and people from the Localization Unconference in Toronto. And what might be next…

On a chilly Ontario morning of January 23, Achievers office in Liberty Village in Toronto welcomed 43 localization enthusiasts to the first ever Localization Unconference in Canada.

Those other ICE (In Context Exact) Matches: Tweet about Strings Freezing

Those other ICE (In Context Exact) Matches

The rules were no prepared presentations, no selling and “there is no spoon”. We brought ideas and brainstormed, voted and discussed the usual suspects (machine translation, crowdsourcing, translation quality, localization and Agile), as well as new arrivals (developer tools for localization, distributed translation memories, identity theft in translation industry).

Localization UnConference topics

Localization UnConference topics

Localization Unconference topics reflect the energy and enthusiasm for inquiry in the industry

Some takeaways:

Translators need context, just a different kind.
Some translators don’t like to read long instructions but prefer to just translate, with screenshots. However you also need to provide detailed description of functionality and purpose, use cases, style guides, and be there for support. Enhance it all by giving translators your game to play or software to use while they localize it.

Developers like to be world-class.
Developers love and cherish their code. If you tell them that following i18n practices will only make their code world class, they salute i18n.

Learn to speak developer language.
Engineers talk system performance and security. Prove how exporting translatable text into XLIFF will strain the system less than CSV export, and your developers love you forever.

Measure translation quality differently.
Ask you customer directly how they feel about language quality. Or ask you sales team in the target region to evaluate quality, or even to localize your content. They will start feeling like they own the quality.

Your localization and your Agile are unique to you.
Reverberations of Agile are true for everyone: how to identify changes, when to start translating, how to manage small projects, how to deal with changing terminology, how to manage testing when things iterate, how to price small projects, do you need a localization stakeholder at every sprint meeting. You do? But what if your company has dozens of products with hundreds of features? Know your unique context: what the product development cycle is and how releases are planned in your organization, and then figure where localization fits best.

The unconference is keeping it pink and multilingual! I hear there might be the first unconference at the next OTTIAQ event in Montreal, in French. And one at Translation Forum Russia 2014, in Russian.

Special thanks to Teresa Marshall (@pschesi) for supporting the Localization Unconference in Canada and consulting the organizers.

Get to know the Localization Unconference Toronto faces here: https://www.dropbox.com/sc/f6zmbo6yixbufp9/nn0O7N-Qo3

Transifex: A Language Developers Understand

I’m hearing great things from software professionals about Transifex, a SaaS translation solution based in Silicon Valley.  As I work in user experience developer relations, I Skyped in Dimitris Glezos (@glezos), Transifex founder and Chief Ninja, in Greece to find out more.

Dimitris’s background is in software development, Transifex originating as an open source project. The passions and principles of the FOSS development community, collaborating on a cloud-based platform, remain true today. Transifex knows how developers work in the cloud, and provides a user experience that makes sense to a world of GitHub, PaaS, Python gettext, RESTful APIs, Ruby, SaaS, and so on. Transifex has even been referred to as “the GitHub of software translation“, which is some accolade in the development community!

Transifex API enables integration of software development workflows and tools in the cloud.

Transifex API enables integration of software development workflows and tools in the cloud.

The Transifex user community now has more than 100,000 developers and translators, working together on over 10,000 projects. Transifex users range from well-known enterprises to tech startups and the open-source community. Transifex can quietly boast of a diverse portfolio of successful translation projects ranging from hundreds millions of words of online courseware to strings for wearables and apps. A testament that Transifex is not a “one size fits all” model, what is really staggering about such a breadth of achievements is that it happened without Transifex having a single sales person, or offering those LSP-style “services”.

The Transifex platform is development friendly and flexible, tooling up small pockets of remote developers to build iterative, dynamic content using 24/7 workflows and lean software methodologies.  Exceling with the detection of string changes and merging, Transifex is easily integrated into development environments through an API and command line interface.  Transifex works upstream too, a string pseudo-translation capability enables developers to test their internationalization chops before starting translation.

Transifex translators use a browser-based online editor. This user experience packs CAT capabilities, support for glossaries, collaborative tools, screenshot preview for context, and other cool features. Translation projects are overseen in a contemporary online dashboard experience (it’s translated, too).

Transifex user dashboard view.

Transifex user dashboard view.

The  editor supports the major file types (including XLIFF and “TMX), has built-in QA for code variables in strings, enables character limits to be set, handles singular and plural variants, and makes it easy for developers and translators to work together.

Transifex online translation editor.

Transifex online translation editor user interface.

“It’s translation the way developers want it, or the way they would have built it themselves”, says Dimitris. Most large companies have figured out a translation process, but many now innovate rapidly with small teams using agile frameworks and don’t want to build their own translation infrastructure. Developers are busy people who like to be productive,  solving code problems using smart reusable solutions, and don’t need extra work. “It isn’t easy to build a translation process”, says Dimitris, “Instead, Transifex is integrated into existing development tools and workflows”.

The Transifex success is based on an understanding of developers and translators and how they work, keeping both these users at the center of the user experience. An easy to use solution that seamlessly matches development processes and work styles with a community of online translators generates a powerful networking effect of kudos from satisfied users, who share their positive experiences with others.

“If developers love it, they talk about it!” says Dimitris. That’s the sort of organically-generated  customer experience that most can only aspire to, and money alone cannot buy. There are powerful lessons from Transifex  about how software development teams and translators can work well together, not least of which is “know your users”.

The Transifex story continues to unfold, and you can find out more about building international products using a SaaS platform in the case studies on the Transifex website.

If you have other examples of cloud-based integrations of translation and software development teams, please  share them in the comments.

Working Out Context in the Enterprise: Localize That!

I just came across an interesting terminology issue for enterprise applications’ user experience and localization, generally. What should we call the people in an organization who do the work of the business and rely on software to help them do so?

Honest labor. But honestly, what to call the person doing it! Image sourced from Ikipedia Commons and in public domain.

Honest labor. But honestly, what to call the person doing it! Image sourced from WIkiPedia Commons and also in public domain.

Take the English language term worker appearing in a software application’s user interface (UI). That term doesn’t work well for every organization’s set up or localized well into every language either. In some contexts, worker might mean someone who is involved in manual labor and is an individual contributor. It others it doesn’t. Consider how that term worker be perceived by the manager of a team of people, or someone who performs “knowledge-based” work (actually, all workers use knowledge, so I always found that qualifier to be somewhat snotty)? Then, there are organizations that have corporate requirements  about how they refer to, and manage, their workers, referring to them as employees, partners, or something else.

So, how could worker be easily localized into other languages given the challenges with the English term in the first place! I have seen localization bugs being logged for the “wrong”  term appearing in a localized UI. In some cases, that may be the case, but the cause, of course, could also be traced back to choice of English language source term and a lack of context or understanding about how it is used.

Should we even bother with such a generic terms as worker, employee, partner, and so on, anyway? In a role-based access world of enterprise applications, perhaps job titles might be more suitable? But then, how would such an approach scale? And, how could it account for an increasingly consumer-driven user experience of enterprise technology where notions of identifying and labelling different types of users doesn’t apply. Then again, if it’s a role-based access implementation, then why bother mentioning someone by title in the UI and not just their profile‘s real name?

Then, there’s that term user; a term in wide use in the drug and software industry, but not elsewhere. What could user be replaced with? Customer? Oh, let’s not go there. I’m confused enough!

Ultimately, of course, this conundrum is really a question of context. Coming up with a common, generic term that suits every organization, with operations in many languages, and that spans all kinds of domains and expertise really is not possible.

Mistranslations of course, can happen, and superior, generated context for translators to localize the source terms accurately will help alleviate problem that for sure. But, coming up with a source term that is broadly acceptable, applied sparsely in the UI, and easily adapted in context is the way to go. Enabling er, users, to change simply one term to another that suits individual (through a personalization option) or organizational requirements (using a customization tool feature) seems a reasonable, consumer-driven approach that doesn’t require an IT project or a translator to be on 24-hour standby either.

One size doesn’t fit all.

Comments welcome. What do you call your workers or users?

Correct Youse of English: Your Personal Dialect Map is Here

Thought I was done with regional English? No chance.

The Irish Times recently predicted that the phrase you guys” will soon be accepted as the new second-person plural pronoun in English. As a native Dubliner, I am very familiar with such evolution, the locals already having adopted “youse” and “yiz” as replacements for the pronoun. As pointed out by Frank McNally in the Irish Times article, you can also hear the use of “ye” in south and the west of Ireland, and “yousuns” in the north of the country.

Now, the New York Times has gone one further and used such dialect variants as “y’all”, “youse”,  ”you guys” and more, and lots of other regional phrases too, as a way to gives a clue as to where you might be from based on how you speak.

Ultan's personal dialect map (Visualization copyright of New York Times)

Ultan’s personal dialect map (Visualization generation copyright of The New York Times)

The newspaper has created an interactive visualization tool using heatmaps overlaid on a map of the United States of America generated from your answers to some dialect-driven questions. You, too, can now create your own personal dialect map. It’s fun!

Although it’s a U.S.-based map, I was amazed to see how many phrases I was using regularly, even from places I had never been to (sorry Newark / Paterson and Yonkers).

That’s language evolution for youse.

Try it yourself.