On FierceDeveloper, David Marino, the CFO and co-founder of Hidden Variable Studios, has written an article on localizing mobile apps.
It’s not the same kettle of fish as localizing a console game, let alone a software package, as David describes:
Coming from a console background, localizing games was the norm, but even a cursory glance at the App Store and Android Markets will tell you that this isn’t the case on mobile platforms. Only the giant companies of the world– Disney, Electronic Arts and Zynga–bother to localize their games significantly.
Still, there are good reasons for localizing any app, and David would be a lousy CFO if he hadn’t researched them:
According to the U.S. State Department, [localization] does [lead to increased sales]. They estimate that U.S. firms alone lose $50 billion in potential sales each year because of problems with translation and localization. If you want your game or company to move beyond being a local product, you need to think global, and if you want your product to compete successfully with other native products, you need to localize it.
We certainly are pleased when people in the C-suite – especially in the CF-suite – think and write things like that.
Have a look at the rest of David’s article on localizing mobile apps, and use it to bolster that localization business case you’re making.
John White of venTAJA Marketing is a localization project manager and consultant. He is also a marketing communications writer for technology and language companies.
From the mobile application development world itself comes a report by Vision Mobile, sponsored by Blue Via, including a section on the topic of localizing mobile apps.
You’re read a jillion times on this blog and elsewhere that you need to keep the strings short because the screens are small. Vision Mobile’s insight goes deeper than that, mentioning two issues in particular:
- localization is completely manual on mobile devices
- mobile app localization has the potential – as it did on the desktop, only now on steroids – to be superficial (occasional strings only) or pervasive (deeply region-specific)
Download the PDF of the full report, “Developer Economics 2011,” from Vision Mobile and search on “localisation.”
John White of venTAJA Marketing is a localization project manager and consultant. He is also a marketing communications writer for technology and language companies.
Have you had to localize mobile applications yet? What’s your favorite part?
They’re a breed apart, these mobile app developers. The familiar model of handing off pure resource files, localizing them, then building them back into the executable doesn’t appeal to them somehow, at least not in my experience.
They are fond of pulling the strings out of resource files, placing them in a spreadsheet with copious comments, and asking us to put the translations in Column B. It doesn’t matter much to the localizers, but I think it results in more work for the developers.
These projects put the translators at something of a disadvantage in other ways:
- In the ancient days of static, 80-character line lengths, translators often had to ensure that their strings contained no more characters than the original text. Mobile applications are similarly starved for UI real estate, but this time, length is measured more often in pixels than in characters, a metric difficult for most translators to work with.
- There is still no context for a translator working on a batch of UI strings. What’s worse now is that the text in many mobile apps is sparse to begin with, and it’s rare that the translator can run the app to get the context for strings like “Up” and “Done”. We pester our clients to provide screenshots, functionality descriptions, requirements documents, and anything else to help the translators.
- The studio isn’t easy to work with yet. With PC-based applications, localizers figured out how to build and test resource DLLs themselves to shorten the L10n QA cycle, instead of bugging clients’ engineering teams all the time. It will be a while before localizers adopt the studios and toolkits used by mobile app developers, because there are lots of them.
- Phones and mobile devices are in scant supply, and the localization process is at the bottom of the food chain. How can the localizer perform proper L10n testing on the device, when the client only has one phone – or none at all – and everybody else needs to use it? (Shameless plug: Our client NSTL performs L10n testing for situations like these.)
We’ve done several mobile app projects for a couple of clients since 2002. They’re rather labor-intensive – especially before and after the localizer gets involved – and it always feels like making a watch: lots of small parts, small tolerances and high demands.
How do you get along with mobile app localization?