Localization in iOS 10 is Even Easier: Here’s What We Learned at WWDC
For the latest updates, read our coverage of iOS 11 and XCode 9 at WWDC 2017.
Introduction: The Worldwide Developers Conference
Get a bunch of iOS developers in a room, and there’s a lot that can happen. Amazing apps. Crazy hacks. Tip trading. But, when it comes to Apple’s annual Worldwide Developers Conference (WWDC), you’re also going to get silence. Because that’s when Apple rolls out their major updates, and everyone is listening carefully.
You’ve most likely heard some of the news already. The big buzz this year is that developers will now be able to place ads in the app store. But you might have overlooked how the internationalization process has been updated in iOS 10.
Luckily, your friendly neighborhood localization company has got you covered. In this blog post, we’ll catch you up on what we learned at the localization-focused talk presented by Karan Misra, an internationalization software engineer at Apple. We’ll just go over the high points; if you want to know more about a particular topic, you can find the full video and transcript here.
If you’re new to localization and having trouble understanding why these updates are exciting (and they are!), check out our localization academy to learn the basics of iOS localization. But for now, without further ado, here are four major updates for localization in iOS 10:
1. Multilingual keyboards and a new number pad
Now, you can set up your keyboard to choose from a combination of any two languages. No more toggling with that globe key—the same layout will allow you to type either of your selected languages, and you’ll get the relevant autocorrect suggestions and predictions for both.
The number pads will be localized too. When you only want ASCII digits—for things like credit card numbers, phone numbers, and IP addresses—use UIKeyboardTypeASCIICapableNumberPad as the keyboard type, and you’ll be all set.
2. Loading the right language for the user
The world has a lot of languages, and they have to be organized in one way or another during localization. The hierarchies can get pretty complex: for example, “Spanish, United States” actually inherits from “Latin American Spanish,” which in turn inherits from “base Spanish.” And then there are the spellings. Hongkongers are used to the British spellings for English, while most Japanese expect American English….and so on.
If only there were something that could automatically recognize these relationships between languages. Cue the Bundle “preferredLocalizations,” which helps ensure you’re delivering the best possible localization. How does it work? Let’s say you’re getting strings from a remote service, like a server or another process. And you’re dealing with a specific user (we’ll call her Anna). The bundle recognizes that Anna prefers American English. If the app isn’t localized for that, it will then move to the next best thing—say, a more general “English” localization. Or if Anna prefers Indian English, it could deliver British English instead of American English (assuming those are the only two choices). The bundle automatically figures out the closest fit.
3. Updates in Xcode 8
There are two new static analyzer settings in Xcode 8. Switch on “Missing Localizability,” and you don’t have to worry about forgetting to use the NSLocalizedString; the compiler will catch you with a warning. And the “Missing Localization Context Comment” will alert you if you’ve omitted the comments (as the name implies).
4. Formatters: Dates, Names, and Measurements
“I’ll be there at p.m. 9.”
Wait, what? It looks wrong in English, but in Chinese, the number goes last. So if a fixed format has been used in one language, you risk ending up with some pretty weird-looking times in the other.
Luckily, there are formatters, which enable automatic adjustments for different languages and cultures—this way, localization won’t mess up your UI. For times and dates, you can use formatters with the setLocalizedDate FormatFrom Template method. It will take your existing format, interpret it in the context of the language you’re converting to, and then use the correct localized format for that language.
And that’s not the only one. In Chinese, the surname goes before the last name. Use PersonNameComponentsFormatters to ensure that your app displays names correctly in each language. The formatter can handle a variety of styles, running from “long” (full names) all the way to “abbreviated” (initials) in multiple languages.
Another new formatter is the NSMeasurementFormatter, which takes care of unit conversions based on which measurements are common in the user’s language and region. This isn’t just the basic miles to kilometers either: the formatter supports more than 20 different types of units, including temperature, energy, pressure, etc.
Build an app for global audience
These localizing updates only matter if, well, you’re localizing. Karan listed some best practices for internationalization and localization in iOS app development, starting with the big one: localize your app (including the name and screenshots) to reach a wider audience. It just makes sense.
His other main tips include:
- Use bundle and formatter APIs to help you do the best possible job.
- Make sure you create a flexible layout, so you can accommodate taller and wider languages.
- Design world-ready iconography.
If you want to learn more about the technical side of iOS localization, we encourage you again to check out our localization academy. And if you want to take a more comprehensive look at localization as a whole process—from choosing the languages to marketing the finished product—download our eBook, The Essential Guide to App Localization. Thank you for reading, and happy coding!