We love getting feedback from our users. It helps us make them happy, and that makes us happy. Feedback and user engagement is also at the heart of our App Booster SDK for developers, to empower other developers to communicate directly with their users.

As a business, we also love saving money. Over the years we’ve spent a very substantial amount of money on localizing our app into 11 languages, and with every new verison of our app we experience the pain of getting new translations, inserting those strings in a string file, adjusting the text, getting those adjustments translated, QA’ing in each language, etc. It’s a costly process both in time and money.

In developing the latest version of our app, we honed in on a method that both saves us a lot of that time and money while increasing translation quality: We replaced expensive translators (who aren’t familiar with our app to begin with) with user volunteers. Those users took pleasure in contributing to an app they use on an everyday basis, so making these users happy is just the cherry on top.

Here’s how we do it.

It begins with having a feedback mechanism that opens a direct communication channel with users. Naturally we use our own App Booster product, as it enables us to:

• Broadcast in-app notifications to our users

• Target and localize those notifications by geography

• Collect direct responses from users to those notifications

• Message with them through our app or via email

The notification we sent out looked like this:

There are many ways to collect feedback from users, but without all of the above you’re not going to be as potent and efficient in CRM as you can be. That’s the case for using App Booster, and I’ll leave it at that. On to how we’ve solved the very painful and often expensive problem of translating your app by relying on our users.

(For the TL;DR crowd, you can skip to the bottom to get a rundown of our time/cost-saving process.)

▶ Pain point: Translation is expensive

As Apple now has an App Store in 155 countries, they encourage developers to localize their apps into as many languages as possible. Their page for internalization and localization of apps lists vendors for localization and provides guidance for the administrative and technical processes for localizing your app.

These vendors don’t come cheap, though. Another way to put it is that the localization vendors who are worth your while are expensive. Quality localization vendors will generally charge several hundred dollars per language, up to a thousand dollars if you’re also translating a lot of iTunes metadata. If you’re inclined to skimp, consider that using a cheap translation provider and nothing more will result in severe compromises in quality.

I’ll explain further below how we save money by using cheap translation providers yet still produce great quality translations by having our users review and improve the text.

▶ Pain point: Translation is difficult to time correctly

Unless your product development cycle includes wireframes and designs that map out every last word of the text that’s going to appear in the next version of your app, you’ll find that you rarely reach the point well in advance of your planned release where you can say, “Okay all the text is ready for translation.” QA might turn up issues that requires interface changes, or the text that you wrote just doesn’t look as good or appealing in your app once you’ve got a build.

Now it’s two days before your ship date and you’re making changes to the English (easy enough). Having to postpone the release a few days to wait for translation is a bummer; having to perform another round of QA to see if the newly translated text fits well is even worse.

Since translation of any kind is a creative process, it takes time. When it requires opening screenshots or navigating through an app to get better context, it takes even longer. Professional translation services can have a turnaround time of up to a week. AppLingua has a smart service called AppBack that puts the app back in the hands of translators once the translations have been done so that they can verify the quality and accuracy of their translations, but again that takes time.

▶ Pain point: Translation is a clunky process

For iOS developers, your translations might be stored in XIB or string files. We use strings. If you’re unfamiliar with “strings” (an odd name for a block of text that appears to derive from “a string of characters”), an individual line of text will look like this:

“_NUMBER_ITEMS_COUNT” = “There are %d items”

Getting this translated presents all kinds of problems:

• If you’re getting your translations from someone who’s not familiar with strings, they’re not going to know off-the-bat that they don’t need to translate ”_NUMBER_ITEMS_COUNT” (in fact, they can’t, or the system will break). This means you can’t just copy/paste your file into a web form and get translations for only the parts of the paste job you need translated. Tethras, for one, has a clever solution for this, whereby you upload your files and they extract the text that actually needs to be translated.

• In addition, the uninitiated won’t know what to do with “%d”, which here represents an integer variable. Presented in the app, this might display as “There are 2 items”. Not only must your translators be precise in not removing or (accidentally) manipulating “%d”, but they might actually need to move it. In Japanese, for example, correct grammar requires that %d appear at the beginning of the text. If “%d” seems relatively harmless to you, consider that you might end up with stranger things like “\n[0]%@[/0]“.

▶ Pain point: Translation requires context

▶ Pain point: It’s really difficult to judge the quality of the translations you receive.

For the latest version of our app, we received a Japanese translation for the phrase, “Awesome!” that looks like “スゴーイ！” Google Translate spits out “素晴らしい！”

Unless you speak Japanese, good luck figuring out which one is better.

▶ Pain point: Some languages require a lot more characters for a string than your interface can fit

Say your design includes a big welcome message somewhere that literally says “Welcome”. Now you’re translating to German and Russian. Hmm, here’s how “welcome” translates in those languages:

• Wilkommen
• добро пожаловать!

How our users help us solve these problems with the Appsfire app

Here’s a quick rundown of how we’ve dramatically cut down on the time and cost of translation without compromising quality:

1. We got traction around the world by translating our app into different languages using professional translation services. This cost a fair chunk of change, but it was necessary to bootstrap. Asking users to translate an entire app from scratch is asking a lot, probably too much.
2. We later recruited volunteers through an App Booster notification. We got at least four volunteers in every language, including smaller locales like Polish. We got dozens for Spanish and French. A handful already had translation experience!
3. With a week to go before we wrapped up our latest version, which includes 50 new blocks of text, I emailed the users we’ve worked with in the past. Some didn’t reply and some were busy, and in those cases I dipped into our pool of volunteers.
4. Meanwhile, I sent off our translations to a very fast, but mediocre-quality translation service. I included screenshots of almost every string to provide context. For 368 words, this cost us about $270 for 10 languages.
5. I copy/pasted the translation from the translation service into a spreadsheet, which I then shared with our user volunteers. Here’s the important part: Instead of burdening our volunteers with one or two hours of non-compensated work, I got decent-enough translations so that their only job was to improve them. And most importantly, these users know our app very intimately, so they’re better suited for the job than any professional translator.
6. I included a hidden column in the spreadsheet with a formula that constructs the string as it needs to be formatted in the app. This makes it user-friendly for our volunteer so he never has to see at anything code-y like “_COPY_CLIPBOARD_”
7. Optionally, you can add these users to your ad hoc build and enable them to try out the app before you ship it. Seeing the text in the app almost inevitably inspires some worthwhile tweaks.

The result? You can judge for yourself. Take a look at the screenshot below of the spreadsheet I sent to our Spanish volunteer. Bear in mind that the spreadsheet was not color-coded when I sent it to him; not only did the user color-code it according to his evaluation, but he added separate columns for his revisions and comments.

Not only does this make our lives easier, but it makes us super happy to know that the next version of our app was made possible by a very happy user. All in all it’s a huge win for us to simultaneously save money, increase quality, and satisfy users like the one below (our Italian translator):