Localization Lessons Learned

kshep · 11-21-2008, 03:17 PM

Hello everyone!

We just released Imangi 2.0.2 which is our first big international update. This includes full localization of the app, the App Store description, and the screenshots into English, Spanish, German, French, Italian, and Russian. The update went live yesterday. I'm looking forward to seeing how this affects sales in regions outside of the US. We are now one of a few word games to fully support most common languages.

Here are some lessons learned so far about localization:

1) Design your applications to support localization from the get go. I had designed the iPhone App with this in mind, but not our web services. I was able to retrofit the web services component without too much trouble, but it was a repetitive boring task. Much easier to start with this in mind.

2) Beta test your localizations. Since I don't speak any of the languages that we translated into, it was hard to know if we got good or bad translations. Having native speaking beta testers really helped us verify that our translations were good, and they helped correct any awkward sentences or misspellings.

3) Localization affects layout. The same phrase in different languages may require different amounts of space to display on the screen in the same font size. This can cause layout problems. Try to design your screens and layouts with this in mind. Don't pack things in too tight. Fortunately, we didn't have too many issues with this, but do expect this to happen and be prepared to make necessary fixes.

4) Have all of your text ready to translate. Make sure that your app is in a stable place without major plans to add significant features anytime soon. Typically you provide a large chunk of text to a translator and they will do it all at once. They will likely charge you every time you come back with more text. It's easiest and cheapest just to do it all at once instead of in multiple passes.

5) Internationalization is HARD. It takes a very long time and there is a lot to test and verify. We spent about 2 months time from when we first decided we wanted to translate to having something ready. You effectively multiple the time you need to spend testing and marketing by the number of languages you want to support. It also makes it harder to add new features in the future because you will always need to translate any new text.

Overall, it's been a great learning experience, and I'm glad that we decided to do this. I hope it will help our sales and engage more of the international community. If all goes well, I will plan to internationalize all of our current and future apps. I'm sure some of what I've learned will help make it go faster the next time around. I also hope that these lessons learned will be helpful to everyone else out there considering localization.

Please feel free to ask if you have any questions, and please share any of your lessons learned.

Take care,

-Keith

brendand · 11-22-2008, 02:49 AM

Please let us know how it affects your sales. I built my app with localization in mind right from the beginning, but I have not yet had time to localize it. I did get my App Store descriptions localized into French, German, and Japanese apart from English of course. I don't know if it has really helped my sales though. I didn't notice any spikes, but I may have made sales that I wouldn't have made if the descriptions were only in English.

Thanks,

kshep · 11-22-2008, 09:04 AM

Hi Brendand,

I'll keep everyone posted on how it affects sales. It definitely was a lot of work, hopefully I won't regret the decision when I want to add more features.

I thought about just translating the App Store description, but I was worried that people would be upset if they purchased the game expecting it to be translated too. Have you gotten any negative feedback about that? Did you put anything in your description warning people that the application is in English only, or was the App Store description supported languages list enough?

Thanks!

-Keith

**wuf810** · 11-22-2008, 09:09 AM

Interested to know as well.

I made the mistake of localising one of my apps - problem was that a lot of the info that it sources is in English only.

So although my French speaking users get the interface (controls, buttons, help et.c) in French, they complained that some data was not.

With this particular app I think it is easier to remove the localisation.

So anyway be careful as someone will always complain.

brendand · 11-22-2008, 10:48 AM

The second line of my description says in each of the localizations I had descriptions written for that the application is in English, but this description is in [insert language here] and that full localization will be coming soon. Nobody has complained about that.

kshep · 11-22-2008, 10:56 AM

Thanks Brendan. Good to know that you didn't get any complaints about that.

-Keith

bhearn · 11-22-2008, 03:19 PM

I localized Subway Shuffle, and it has made a large difference to my sales. Especially since the Lite version was also localized.

There have been days I've had more sales in Germany and Italy than in the US.

Yes, it was a pain. And the pain keeps on giving... you have to address each localization every time you update.

PhoneyDeveloper · 11-22-2008, 04:34 PM

@BrendanD, Can you give an overview of your localization strategy? Nibs, no Nibs? Was everythiing based around NSLocalizedString? Did you just send strings files to the translators or something else also?

brendand · 11-22-2008, 05:31 PM

Every string within my code uses NSLocalizedString(). I keep going back and forth whether or not I should do one xib for all languages or a xib for each language. I had played around with creating a xib for each language, but then I reverted back to the single xib because I had too many changes to make to the layouts. You really have to have a solid grip on your layout and not to change it too much between releases.

If you're lucky enough to have a flexible layout that can deal with different font sizes without your app looking like crap, then the single xib approach seems more ideal to me. You can still type your text in IB, but then you have to have code to replace the text at runtime.

There are benefits to both techniques of course.

In the web applications my company makes, we use a single page with bindings for localized strings. That technique works well, but HTML has more flexible rendering of layouts than xibs do.

A friend of mine made a program for the Mac called Fuzzy Clock and he has it localized to about 72 languages. I even think Pig Latin is one of them!

He just has a different Localizable.strings file for each language, but uses a single nib file.

kshep · 11-22-2008, 06:28 PM

Imangi was built without Interface Builder, the interface is all created programatically, so no nibs there. Every string in the app is retrieved using NSLocalizedString() and I also put some of our icons, graphic, and static html resources that include text in the xx.lproj folders for each language. I simply supplied a translator with the .strings, images, and html (help) files. So at this point all I really have to do is add another xx.lproj folder for another language with additional translations if I want to add more.

@bhearn, glad to hear that localization has helped Subway Shuffle. Great game btw, my wife and I have had a lot of fun with it.

-Keith

bhearn · 11-22-2008, 07:31 PM

Quote:

Originally Posted by kshep

Imangi was built without Interface Builder, the interface is all created programatically, so no nibs there. Every string in the app is retrieved using NSLocalizedString()

Same with Subway Shuffle. The most troublesome issue I had is that my instruction screens (text bubbles on levels 1 and 2) were images in the non-localized version; I didn't want to load down the app with lots of images. So I had to write some code to wrap arbitrary text in a bubble with a pointer coming out, satisfying various location constraints.

Other issues:

* Some translated strings were too long for the interface; it took some back and forth with the translators to get strings that were meaningful and would fit.

* The original German translation I got turned out to be garbage, which I didn't realize until I started getting bad reviews in Germany. Turns out the (usually reliable) German translator my localization service used decided he was too busy, and had a friend do it. Caveat emptor!

Quote:

Originally Posted by kshep

@bhearn, glad to hear that localization has helped Subway Shuffle. Great game btw, my wife and I have had a lot of fun with it.

Thank you! And good luck with your international sales.

- Bob

PhoneyDeveloper · 11-22-2008, 09:25 PM

So do you guys have code that is language dependent or code that is dependent on the lengths of strings in the interface?

kshep · 11-22-2008, 09:28 PM

Everything I do for layout in the code takes into consideration only the length of the string to be displayed, not the language.

-Keith

BSDimwit · 11-22-2008, 09:48 PM

About how much did it cost to get the translation services. Can you give a rough idea about how they charge and what sort of services are offered.

**wuf810** · 11-23-2008, 01:52 AM

Quote:

Originally Posted by bhearn

* The original German translation I got turned out to be garbage, which I didn't realize until I started getting bad reviews in Germany. Turns out the (usually reliable) German translator my localization service used decided he was too busy, and had a friend do it. Caveat emptor!

So do you guys use professional translation services? Any recommendations.

Thanks, M

kshep · 11-23-2008, 08:30 AM

We used DYS Translations for the Italian and French translations. We use individuals for Spanish and German. DYS is very reasonably priced. We paid them less than $100 per language. I'm sure their costs depend on the amount of text in your App, but I thought it was very reasonable.

-Keith

bhearn · 11-23-2008, 12:11 PM

My translations were a mix of individuals who offered to do it for free and a paid service. I paid $50 / language for French, German, and Dutch, and $35 for Italian. PM me if you want contact information. (I've already trashed their German translator here (who has since been fired), but otherwise I'm happy with the company, so I'd prefer not to name them here publicly.)

thre3dee · 12-02-2008, 12:59 AM

I'm currently developing an application which is 90% user entered text content so I hope that localising my app won't be as much trouble as other applications.

The primary strings displayed are names of tabs and navigation bar titles (and prompts) and also some table view cell labels. My application is mostly a Calendar.app like application with a little bit of Contacts.app and some songs/lyrics entering thrown in for good measure which means that most of the text content is user-created (which takes the burden out of translating strings).

I actually just tried writing some Japanese characters into a new entry and while it displayed correctly, I think I'll have to have a look at how my SQLite database is storing it as when I reload the application they are messed up but thats because I haven't even touched localisation in my app so I expected it wouldn't work properly.

The only problem I'm forseeing is the "section index title" part of the contacts tab which is much the same (though with a different kind of contact) as the Contacts and after looking at the Japanese index titles it doesn't exactly look anything like "ABCDEFGHIJKLMNOPQRSTUVWXYZ#"!