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.

App Localization Costs Estimator Helps You Calculate Prices

App localization costs are usually hard for developers to quantify, unless they’re working with someone who knows how it works. That’s why at Babble-on we answer every request for localization costs fast—typically within 15 minutes!

But is that fast enough, or even the best way? We’ve noticed that developers are a shy bunch. They want to estimate localization costs but they often don’t want to email or call to find out. That’s why we created a free App Localization Costs Estimator widget right on our website:

Localization Costs Estimator

This easy localization cost estimation widget makes it possible to calculate costs down to the penny instantly. Try it for yourself by uploading your Strings file, app description, and keywords: App Localization Cost Estimator.

How the Localization Costs Estimator Works

It’s simple. Click “Add file” or just drag your files onto the button. The localization cost estimator can count the words and strings in a whole bunch of file formats. Next, choose the languages you are interested in. You’ll see the exact cost for everything, and you can add or subtract languages and files until you reach your budget. Remember, the prices include everything from expert handling of localization formats and encodings (like UTF-16 Localization.strings files), to real-live-human tech support by phone or email. Babble-on isn’t a factory, and that kind of attention means a lot once you get started localizing.

File types the cost estimator can count:

  • iOS .strings
  • Android .xml
  • Windows 8 (Metro) .resw, .resjson, .resx, .rc
  • Java/Flex .properties
  • Ruby on Rails & YAML .yml
  • BlackBerry .rrc
  • GNU GetText .po, .pot
  • XLIFF .xliff, .xml
  • Microsoft Office/Open Office .docx, .xlsx, .pptx, .odt, etc.
  • HTML
  • Plain Text .txt
  • Qt .ts
  • DKLang .dklang, .lng
  • XUL .dtd
  • Google Chrome Extension .json
  • Subtitles .sbv, .srt

Which languages should I localize my app into?

The most popular languages are Spanish, French, German, Italian, Portuguese, Japanese, Korean, and Simplified Chinese. Of course it depends on your target and your budget. My suggestion is always to start with one, preferably a language for the country you are already seeing some traction in. For example, if you see downloads outside the US usually come from Japan, then Japanese should be your first pick. Check iTunes Connect or the Google Play store to verify your download stats. If you aren’t sure, stick with the largest markets like Spanish. Contact us for personalized advice.

Read our press release: San Francisco iOS App Localization Service Says No to the Factory Model and Introduces Cost Estimation Widget