Xcode 10 Localization in iOS 12 – What’s new from Apple from WWDC 2018

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:

$ xcodebuild -exportLocalizations -project  -localizationPath  [[-exportLanguage ] ...] 

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:

guard let font = UIFont(name: "SignPainter-HouseScript", size: UIFont.labelFontSize) else {
}

// Create Cascade List
let cascadeList = [UIFontDescriptor(fontAttributes: [.name: "HanziPenTC-W5"])]
let cascadedFontDescriptor = font.fontDescriptor.addingAttributes([.cascadeList: cascadeList])
let cascadedFont = UIFont(descriptor: cascadedFontDescriptor, size: font.pointSize)

// Handle Text Size (Dynamic Type)
label.font = UIFontMetrics.default.scaledFont(for: cascadedFont)
label.adjustsFontForContentSizeCategory = true

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!

What’s new in localization in Xcode 9 and iOS 11 – The developer and translator guide

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.

  1. 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.
  2. 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 template new create in Xcode 9

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.

Stringsdict in Xcode 9More 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:

Why use Auto Layout in Xcode for your localized apps

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
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

  1. 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.
  2. 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.
  3. 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
  4. No minimums or maximums. Allow each content view to adjust in size as the language changes.
  5. 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.

Localized screenshots upload at Babble-on

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

What’s new in Xcode 6 Localization for iOS 8 and Yosemite

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.

Update Our new iOS localization tutorial for Xcode 6 is ready. Check it out!

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 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:

xcodebuild -exportLocalizations -localizationPath <dirpath> -project <projectname> [[-exportLanguage <targetlanguage>]]
xcodebuild -importLocalizations -localizationPath <dirpath> -project <projectname> [-forceImport] Import CLI removed from Xcode golden master

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

  1. Click the target in the Run destination menu and choose Edit Scheme.
  2. On the right, select Options.
  3. Choose a pseudolocalization from the Application Language pop-up menu. Then hit the Close button.
  4. 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.

Free Pseudolocalization

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, SlovenianThat 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!

How to Track and Improve the Rank of Localized Keywords for Your iOS App

Guest post by: Hugh Kimura
Sensor Tower – Power Tools For App Store Optimization

Two closely related issues that we hear app publishers having is that they do not know how their app ranks for their localized keywords and they do not know how to improve their search visibility in other countries. Since app localization is such a large part of expanding the user base of an app, we think that this is a critical issue that needs to be addressed. After all, the more international users you have, the more money your app makes!

In this post, we are going to show you the fastest way to test out how your app ranks for all of your localized keywords, and how to improve your keyword rank in the countries you are targeting.

Track Your Rank In Other Countries

Let’s start by going through the process of using Sensor Tower to track how your app ranks for its localized keywords. As an example, we’ll use the popular game Kingdoms of Camelot: Battle for the North on the Apple App Store in Italy. After you log into Sensor Tower, make sure that your app is selected at the top of the screen. If you need to add it, click on the green Add New App button.

Add new app for localized keywords

Then in the upper right corner of the screen, click on the flag to access the country drop down menu and select the country you want to track.

02-change-country

Now click on the Search Rankings Tool icon on the left side of the screen.

02-search-rankings

Start entering the localized keywords that you are currently using for your app. Here is a partial list of the keywords that Kingdoms of Camelot uses, and how it ranks for each of those localized keywords.

02-keyword-list

Tracking your localized keywords in this way makes it easy for you to see exactly which are helping and which are hurting your app. The iOS app is doing quite well with some of the keywords, ranking in the top 5 for translated keywords like medioevo and even untranslated ones like north. (Since north is part of the game’s title, it is an important keyword in every country.) But there are other keywords like geme that are not really doing the app much good.

When analyzing the localized keywords for your own app, the goal should be to rank in the top 10 for all of your international keywords. That is not always possible, but if you have a translated keyword like geme that is ranking in the hundreds, then you should take it out and find another to replace it in your next update.

As you can see, setting up keyword tracking is very easy and you can set up a different keyword list for every country’s App Store that you are in. Sensor Tower will remember all of your settings in your account.

Improve the Rank of Localized Keywords

Knowing how your app ranks for all of its keywords is great, but how do you improve your rank? There are three primary criteria for choosing keywords and this is how you prioritize them to pick the right keywords.

The first, and most important, is relevance. You want to be sure that your keywords are closely related to your app so users will be more likely to download it after a search in the App Store. This seems obvious, but we still see publishers prioritizing traffic over relevance. Judging keyword relevance is much more difficult in foreign languages, so talk with your translator to come up with the right options. Often, what works in one language does not in another. Try asking the translator which words he or she would use to search for and find an app like yours.

Sensor Tower offers additional tools to help you spy on the localized keywords that other apps are using, track your competitors, optimize your keyword list, and get keyword suggestions.

02-keyword-tools

Consult your translator about keywords that you find with these tools if you have any doubts as to their relevance to your app.

Luckily, the other two criteria for choosing localized keywords are objective and you can find out that information by using our Keyword Research Tool. When you are logged into Sensor Tower, click on the Keyword Research Tool icon on the left.

02-keyword-research-tool

Now enter any keyword that you want to research and you will be able to see the Difficulty and Traffic scores for that keyword. For this example, here is what the data looks like for castello, the localized Italian word for castle.

02-castello

Sensor Tower gives each keyword a separate Difficulty Score on the iPad and the iPhone. The higher the score, the harder it is to rank in the top 10 for that keyword.

But there is a catch. Your ability to rank is also going to depend on the relative strength of your app. If your app has been around a while and has a thousands of downloads, then you are going to be able to rank higher for keywords that have a higher difficulty rank.

If you are just starting out, we recommend testing keywords with lower Difficulty Scores first. Once you get an idea of the average Difficulty Score you can rank in the top 10 for, then you can adjust your strategy accordingly. As you get more downloads, you can start to target higher difficulty keywords.

If you have an existing app, then look at the keywords that you are already ranking in the top 10 for. What is the average Difficulty Score of those keywords? When you choose new keywords, look for ones that have that score or lower.

Finally, the last factor you should look at is traffic. Relevance and Difficulty being equal, choose the keyword with a higher Traffic Score. Similar to the Difficulty Score, the higher the Traffic Score, the more traffic (or searches) a keyword is getting.

As long as your translated keyword is getting more than zero traffic, it is fair game. The only exception is if a zero-traffic keyword is part of an important keyword phrase. Here are the Traffic and Difficulty Scores of the international keywords we showed you for the Kingdoms of Camelot: Battle for the North game.

02-traffic-difficulty

Final Thoughts

If you remember the acronym RDT (Relevance, Difficulty, Traffic), it will help you prioritize the three main keyword characteristics. Again, ideally you want to rank in the top 10 for all of your keywords, even localized keywords. If you are ranking #402 for a keyword, it is wasting space in your keyword list. Throw it out and test another. However, if you are ranking #20, then that is still respectable and you probably want to keep that keyword until you can find a better replacement.

Although researching and tracking your keywords is a simple process, the key to success lies in continually tracking, testing and updating your keywords. International and localized keywords follow the same logic, but you will need the help of a reliable localization company to help you parse and recommend the right ones. You cannot just set your keywords once and forget about it.

We hope that this post has given you the information you need to track and rank well for your localized keywords. If you have any questions, let us know in the comments below.

About the Author: Hugh Kimura does Marketing for Sensor Tower, an easy-to-use online App Store Optimization tool that helps your app get more downloads by providing fast and accurate data to improve the visibility of your app on the App Store. For a free 14-day trial of the tools mentioned in this post, or to learn more, visit Sensor Tower.

iOS Language Codes: What do you name your .lproj folder?

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

We always pass this information on to developers who contact us about localizing their apps into all the languages of the App Store. But we also think Apple should make this information a bit more plain to see. Here is the only page we found documenting it.

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.

Not sure what a en.lproj folder is? Well check out our iPhone Localization Tutorial first! And we’ve got a tutorial for adding localized app descriptions and keywords too.