13 November 2008

The Watchmaker Localizes Mobile Applications

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?

Labels: , ,