Category: internationalization

Xcode 10 bring a couple of new localization and internationalization features to help iOS and Mac developers reach global audiences.

Here’s a wrap-up straight from WWDC 2018’s sessions:

Localize Siri intents

The biggest developer news from WWDC was undoubtedly improvements to SiriKit allowing developers to create Siri Shortcuts. Now, your users can take advantage of personalized voice commands to execute repetitive tasks within your app using Siri. For apps with a global audience, it turns out that Siri intents, as these shortcuts are known in Xcode, are fully localizable. Just select your Intents.intentdefinition file in Xcode, and press the Localize… button in the right-side panel.Localize Siri Intents files in Xcode 10

Xcode will create an Intents.strings file with all your English texts related to your Siri shortcut. This file will be included automatically in the traditional Xcode export you send your translators.

Localize content with Xcode catalogs

Apple is trying to help developers localize their entire app more efficiently by expanding Xcode’s localization export capabilities. This new localization export is called an Xcode Catalog, and carries the extension .xcloc. Basically, it’s a folder full of stuff rather than just the single xliff from before. The idea is to send the translator everything they need, and for you to receive it back in the same way. The .xcloc includes:

Source: Apple.com — A look inside an xcloc package

Now, instead of exporting only text strings, like the Siri Intent strings we just talked about, Xcode will actually export any content you choose. This includes images that you may want to localize. Before you had to send such non-text content to the translators separately, but now you can have Xcode export and import these assets each time, following your precise directory hierarchy. Another feature of the .xcloc file is including storyboards for context, as well as a general Notes folder. The Notes folder is initially empty, but this is where you can include your own ReadMe file and Screenshots. Apple highly recommends automating your screenshot creation using Tests introduced last year in Xcode 9. It’s a bit of work to set up, but it pays off in the long-run. You’ll be able to send your translators the latest screenshots each time.

The new .xcloc format is supported by the existing Terminal commands for Xcode localization export:

If you’re using Terminal for localization builds currently, you’ll notice this is the same command as before. The only difference is that you are now exporting .xcloc folders instead of just the .xliff files.

Xcode Internationalization Best Practices

Although not much is new in the talk from Apple at WWDC 2018 “Creating Apps for a Global Audience”, it is a great introduction (or review). As always, the key takeaways for “easy” internationalization are:

Use Containers — UIStackView and others are already internationalized

Use Auto Layout — it does the rest of the layout work for you

Use Formatters — it formats numbers, dates, currencies, and even names for you

Use color for emphasis — Uppercase and italics don’t work in many scripts outside of Latin, but bold text and different colors usually do the same trick

Check your work — Xcode includes pseudolanguages to test all your assumptions

Use International Fonts — the built-in app Font Book can tell you which languages your font will work in!

On this last point, Apple reiterates some excellent code to choose appropriate fonts for different alphabets:

Xcode 10 Localization Wrap-up

The more things change, the more they stay the same. Xcode localization and internationalization still requires good, honest translators. Ready to localize your app? Contact Benjamin at Babble-on. I’ll help you from start to finish!

Xcode 9 brings a surprising amount of localization updates that make it easy for developers to internationalize their apps. These changes are also helpful for the translators and localization companies like us. We want you to implement these localization features in Xcode, so let me tell you about them!

Test your app in any language/region in Xcode 9

The Test scheme editor has a couple of excellent new localization features in Xcode 9. It used to be time-consuming to see what your app looks like in each language. Now all you have to do is set the language and region in your automated Test.

Notice another nice addition: Show non-localized strings. This should help you find those hard-coded strings you forgot to internationalize in the first place!

Grab localized screenshots too

Tests can capture screenshots as well. There are two great reasons capturing screenshots with Tests for localization.

Use the localized photos to send to translators. Did you know Babble-on has a whole developer portal just for testing your localized screenshots? It’s the BEST way to ensure your localized iOS or Mac app is ready to ship worldwide.

Remember the App Store? Love it or hate it, users are much more attracted to localized screenshots of your app than seeing the English.

You can now write a single Test to capture screenshots in all your localized languages. That is a huge timesaver!

XCTAttachment(screenshot:app.screenshot())

There are a couple of new pseudolocalization languages to try out in Xcode 9 as well, including better right-to-left support to test Arabic and Hebrew. The new right-to-left pseudolanguage actually writes your English “backwards” so you know how it feels:

Lorem ipsum -> muspi meroL

Plurals with Stringsdict gets full support in Xcode 9

In Xcode 9, export and import of localizations via XLIFF now supports stringsdict files. Next question: what’s a stringsdict? Stringsdict is a dictionary file that helps your app handle the many plural rules in foreign languages without a single line of code. You may not know this, but many languages have more than one plural form. Your sly code (if num >1) to add an ‘s’ to each word never actually worked for Russian… or Arabic… or dozens of other languages. Now you have an easy way to implement the right solution. Note that this can only work when you have a formatted string — a ‘%d’ type number of items for Xcode to parse.

Stringsdict has actually been the way to do plurals in iOS and Mac for a couple of years now, but it’s finally getting much-needed support in Xcode 9. You can view stringsdict files in a format that makes them much easier to create and to read. Xcode 9 also has templates so you can add plurals with a couple of clicks.

More importantly, Xcode will export your plural lines in the XLIFF you give to translators. It even knows how many plural forms each language will need (though your translator should know this too, don’t you think?)

And in another “finally” moment, Xcode can view XLIFF files in a nice table format natively. Just double-click on your XLIFF to see. (Before you’d just get the raw XML, which was a mess to read or debug.)

Adaptive strings in Xcode 9

In that same Stringsdict format, Apple has allowed for another useful trick. They call it Adaptive strings. Essentially, this means you can have Xcode pick at runtime which text to use based on how much room is available in the UI. In English, that means you could have a long heading on an iPad screen like:

Worldwide Developer Conference 2017

but use a shorter one on iPhone:

WWDC 2017

It’s not based on screen size, as you might expect. It’s actually about the text length and what can fit. For internationalization that means you can add some abbreviations or alternate wording in languages that just don’t fit your UI (I’m looking at you, German). It’s done very similarly to plurals. You, or more likely your translator, adds in optional wording for each situation and the user’s device sees the correct text at runtime. Pretty cool, right? Of course there are other important ways to make sure there is room in your UI for internationalization: Auto Layout and variable constraints.

Under the radar localization changes in Xcode 9

One small but welcome change in Xcode 9 are warnings. Interface Builder now tells you if a view’s fixed constraint can cause localization problems, such as cutting off the text with the dreaded ellipses. If you can’t solve this on your own after battling with Auto Layout, talk to us and we’ll help you with shorter translations free of charge on anything we did for you!

According to the release notes, Xcode 9 now uses “\n” and “\t” instead of literal newlines and tabs in the strings files it creates. It does understand both the old and new forms, though. Xcode 9 can also export source files with encodings other than UTF-8. It used to fail in those situations, so that’s a good thing!

That’s the roundup! Be sure to check out these Xcode 9 localization resources for more information:

Auto Layout saves the día

As a developer, you may have some legitimate reasons not to use Auto Layout. You may even think that Auto Layout is Apple’s version of punching you in the gut. You may think it’s only about varying screen sizes. Mostly, maybe. But if the myriad screen sizes of iOS devices haven’t persuaded you, maybe internationalization will be the straw that broke the camel’s back. Auto Layout is downright essential for app localization and internationalization as well.

Turning on Auto Layout in Xcode

The best defense of this localization unpredictability is Auto Layout. Let Xcode help flow the text as it should, because you can’t expect to anticipate what the Russian or Arabic text is going to do. Auto Layout also makes it possible to have one set of .storyboard and .xib files for all the languages of your app. That’s a plus, right?

Don’t just take it from me. This is what Apple writes about Auto layout and internationalization in its Auto Layout guide. As a localizer myself, I will tell you it’s all true (except the part about Japanese, which is often way longer than the English):

Internationalization has three main effects on layout. First, when you translate your user interface into a different language, the labels require a different amount of space. German, for example, typically requires considerably more space than English. Japanese frequently requires much less. Second, the format used to represent dates and numbers can change from region to region, even if the language does not change. …Third, changing the language can affect not just the size of the text, but the organization of the layout as well. Different languages use different layout directions. English, for example, uses a left-to-right layout direction, and Arabic and Hebrew use a right-to-left layout direction.

In other words, localizing into other languages is going to change the layout of the text in your app in ways you haven’t considered. And ways you probably shouldn’t have to care about — that’s what Auto Layout does for you!

What’s a localized app look like without Auto Layout? It’s sort of like Apple introducing a new mini-iPhone screen size and your app suddenly looks terrible on it.

Tips for using Auto Layout when localizing apps

Remove all fixed-width constraints. If the German text is 30% longer, and you don’t provide room for it in your UI, this will at least let iOS change the font size to accommodate. Otherwise, your localized text will get cropped.

Text fields should fit to contents. Select Editor > Size To Fit Content so that text fields and labels resize automatically for longer or shorter text.

Pin views to adjacent views. This way, when one view resizes to fit your localized text, the other views will too. Otherwise, views may overlap in some languages

No minimums or maximums. Allow each content view to adjust in size as the language changes.

Use leading and trailing attributes instead of left and right. This tip will make right-to-left languages (Arabic, Hebrew) flow properly.

That’s it! With just a few tips you’re localized apps will look awesome.

What if my text is STILL too long?

I’m not going to lie. Auto Layout is not a panacea that solves all the world’s internationalization ills. But you’re working with Babble-on, the localization pros, right? When you’ve given as much room as you can in your UI and Auto Layout has tried its best, the only remaining option is to change the text itself. That’s why we offer a free QA service for our localization clients where you can upload your localized screenshots. Anything that doesn’t fit or doesn’t look right we’ll shorten or alter the text to make it work.

Check it out for yourself by entering out developer portal! (It’s free and has great tools for localization.)

Xcode 6 brings XLIFF file format and new localization languages

While developers are poring over the Xcode 6 beta released at WWDC 2014, we’ve been getting questions about some of the big changes and improvements Apple made for localization in iOS 8 and Mac OS X Yosemite. We’ll go in depth in these topics as we update our iOS App Localization Tutorial, but for now here is a recap of the biggest changes.

XLIFF comes to Xcode with easy import and export

Apple touts that the new xliff file file format is an industry standard, which can be used by many localization tools. That’s true. Babble-on has been working with xliff for years, so we’re happy to see this change. (We can still work with your .strings files of course.) Essentially, xliff is just an xml file structured specifically for localization. Rather than having to go through the unintuitive process of using two, separate command-line functions to export your strings for localization, Apple now let’s you do it from the menu bar. Select Editor > Export For Localization

The localization editor in Xcode 6 makes it much simpler to export your strings.

The exported xliff file is actually a combination of ALL your .strings files. Those .strings still exist in Xcode — you just won’t need to deal with them any more! Once we’ve translated the en.xliff file for you, you’ll get back a new one for each language: fr.xliff for French, es.xliff for Spanish, and so on. Import those into Xcode using the menu Editor > Import Localizations. Easy! Having just 1 file per language is a great improvement.

In case you do love the command line, Apple also introduced new commands to accomplish the same thing:

Preview localizations and pseudolocalizations in Interface Builder

Another new feature in Xcode 6 is the ability to view your localizations “live” in Interface Builder. This is a good way of checking that your interface doesn’t break or look sloppy in other languages that are more verbose than English (I’m looking at you, German). We hope more developers will take advantage of this tool to improve the design layout for international audiences. In fact, Xcode 6 even lets you preview these issues BEFORE you localize. There is a new Pseudolocalization option for Interface builder offering right-to-left and DOUBLE-length options.

Testing your app using Apple’s pseudolanguages

Click the target in the Run destination menu and choose Edit Scheme.

On the right, select Options.

Choose a pseudolocalization from the Application Language pop-up menu. Then hit the Close button.

Click Run to relaunch your app in the pseudolanguage.

Apple’s method is nice because it is built in. However, our developers have told us they like the pseudolocalization files we provide because you can view your texts as

Seeing your texts in a different script makes it easier to spot strings you have overlooked. Apple’s method simply CAPITALIZES words to indicate you forgot to localize them. We still offer free pseudolocalization, including for the XLIFF format, from our Web site.

New localization languages, regions, and locales

The other big news for localization in Xcode 6 is the addition of new languages and locales. Specifically, Apple has added its own localizations for:

Hindi
Indian English
Canadian French
Hong Kong Chinese

In addition, Apple added keyboards for Bengali, Marathi, Urdu, Indian English, Filipino, Slovenian. That means that, even if iOS 8 is not translated into those languages yet, at least users in those countries can use their own alphabet or keyboard to type out messages.

For developers, the bigger news is the lifting of an old iOS restriction about languages and locales. You can now localize your app into ANY language (even Klingon) — not just those that Apple has done! This means that if you have a project for India, you can localize in Tamil and Bengali even though Apple doesn’t provide system-wide localizations for those languages. That puts iOS on par with Mac OS X in region capabilities. It also means Lord of the Rings fans can add Elvish to the list of languages they support, assuming they find an Elvish translator.

Babble-on can’t translate Elvish or Klingon, but we can help you with some of the other localizations you may want. Contact us!

Apple’s localization documentation is sometimes lacking. This is especially true for localization topics like language codes. We’ve put together a very handy chart to answer a surprisingly difficult question: Which languages do iOS and the App Store support?It is actually a trick question. Apple supports a different list of language codes and regions on iOS than the iTunes App Store.

UPDATED: 2017. It seems this page about iOS Language Codes is still a hit, but the information has changed since we first published it in 2013. Should be good now!

The difference between the App Store language list and the iOS language list has some real-world consequences. For instance, you can localize your iPhone app into Hindi, (language code: hi) but you will not be able to paste in the Hindi app description and keywords in iTunes Connect. Since this metadata is important for discovering your app, you may not be as inclined to localize your app into Hindi knowing this fact.

The other way around is also strange. Technically, since iOS 8, you can localize your app into ANY language by including the proper ISO language and region code. That means, technically, you could do Klingon if you wanted. However, Apple itself only localizes the system text into 40 languages, and the chance that your user has selected a language other than one of those is extremely small. In short:

iOS: Supports 40 languages and regional variants (Indian English is the most recent addition)
App Store: Supports 21 languages and 7 additional regions of those languages

iOS Language Codes – The Missing Manual

At the request of the developers we work with, we’ve put together a Knowledge Base article with a complete chart. At a glance you’ll be able to see if the language you want is supported by either/both iOS and the App Store. We’ve also included those handy ISO-639 language codes you always ask us about. You’ll need those to create your en.lproj and other folders to store the localizations of your app in Xcode.

Developers often ask which languages iPhone supports, but more critically, which languages should they support in their own iPhone apps? Obviously supporting all of Apple’s language choices above is costly and time-consuming, so you want to begin with the largest markets. An even more important consideration is that you’ll only be able to market your app effectively in the languages supported by App Store.