NewChoose the column in your CSV or Excel file to pseudolocalize
Pseudolocalization offers developers a way to test an app before translating anything. After all, internationalizing your app can be some work if the app wasn’t designed that way from the start. You need to:
1) Make sure all user-facing texts are tagged or exported for localization
2) Update number and date formats to use regional settings
3) Expand the UI for flexibility, since most languages take up more space than English, and a few take up less
4) Ensure right-to-left text works if you plan on Arabic or Hebrew localizations
Just writing that list makes me want to ask for help! Luckily, Babble-on has provided a free pseudolocalization service to help developers with issue #1 for many years now. It works with a whole bunch of formats, from iOS .xliff and .strings, to Android .xml and Windows .resx. For game developers in particular, it also works with CSV and Excel XLSX documents. However, it’s always been a little tricky with those because the ‘source language’ column can be different from document to document.
Our latest enhancement helps with just that.
Before we had defaulted to Column B, since most developers user a ‘key’,’source’ type format. Now, the choice is yours!
After uploading a CSV or Excel document to our pseudolocalization cost estimator, you’ll be able to specify which column your source text is located in. And of course, you’ll also get a free estimate of what it would cost to translate that text into any language. Although our pricing is straightforward — pay only by the word — we happily translate all duplicate lines for free. This cost estimator will let you know exactly how much you save there for those countless ‘Done’ and ‘Cancel’ buttons you’ve got!
Try it out, and if you have any questions, ask us for help at Babble-on.
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:
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.)
For developers that use Babble-on to update their app localizations often, we’ve always made it easy to keep track of a single monthly invoice. Now we’re making that process even simpler. Whenever you add new translations for us to do, your project manager will send you a quick link to look over the updated invoice and give your approval. And of course, for developers who pay on a project-basis, you can pay directly from your phone too, using any payment method you like.
Approve or pay invoices with a tap
That’s right. Invoice links no longer require you to log in. Just tap the link from your phone and click “Approve invoice”. Your project manager will begin work right away and you can continue about your day. Something not right? Tap “Request changes” and a handy email box will pop up for you to tell us which items you want to add or remove.
New payment method: e-Check
In addition to credit cards, PayPal, and Bitcoin, we’ve also added payment by electronic check. That means you can pay instantly just by securely logging into your bank. The whole thing is handled by Stripe, the easiest and most secure payment provider around. The e-Check option works with the largest US banks (sorry, no foreign banks or credit unions at the moment).
Export your invoice data
Finally, we’ve added the ability to download all of your invoice data. From the billing page, look for the Export as CSV option. This is a comma-separated-values (CSV) file, which opens in Excel or any spreadsheet app, as well as in a simple text editor. It’s helpful for those year-end calculations you want to make about how much money you are spending on localization. Just don’t forget to calculate how much money you made from international users! We’re quite sure you’ll be pleased with the results.
Is there something else we can do? Let us know how to make invoicing easier for you.
Let’s face it: when users browse the App Store they do not always read your well-written app description, even if it is localized into their own language. But they almost always look at screenshots. These adver-images can and should be localized, too.
The limited amount of text above (or below) each screenshot is valuable real estate for persuading users to download your app.
Most of the developers we work with end up localizing their screenshots into dozens of languages. They send us a text file with those 5 to 10 phrases written out, and we translate them into each language. In the past, creating the graphic assets to go along with the translations has been a pain. But no more!
Launchkit.io Davinci makes localizing screenshots easy
Update: August 2017: Launchkit was bought by Google and shutdown. A similar service, Davinci, which still has a free tier, can be used instead.
We recently came across an amazing, free Web site called Screenshot Builder that makes it fast and simple to create screenshots for the iTunes App Store, both iPhone and iPad versions. With a little copy and paste, it functions equally well for localized screenshots. Say we start with a typical screenshot for a wonderful app we translated like JotNot Scanner+
It’s not a localized screenshot but it sure looks pretty.
Since we just finished localizing this app, we translated the screenshot texts too. And using the service, it’s as easy as this:
Screenshot Builder makes localizing screenshots as easy as copying and pasting the text from the translators.
We even got that pretty white iPhone in the background! A shout-out to Brendan Mulligan for making this happen and for continued improvements still to come.
Tips for localized screenshots in the App Store
First, use a reputable app localization company. It’s just a few (very important) words and it won’t cost much!
The other critical tip we can give you is to have the translators review your localized screenshots before you publish them. Each language has particular rules about how text flows between lines. In English it wouldn’t be acceptable to divide a long sentence like this:
JotNot puts a scanne– r in your pocket
While you may think that you can just flow the lines after any word, what would you do in cases like Chinese where there are no spaces to indicate the end of a word?
JotNot 將掃描器放進口袋
That’s a bit harder, eh? German has überlongishwords which are also hard to hyphenate without knowledge of the language.
We solved this problem for our developer friends a couple of years ago by introducing a “sanity check” right into the localization process. It looks something like this:
Developers can upload the localized screenshots based on the translations we’ve given them, separated out by language. We have each translator review the screenshots for their own language and flag them as “OK to publish”. If something is wrong or the new context causes a change of mind, we make revisions to the translations and export them again. Sometimes we discover something out of our control, like a text that was never in the strings file to begin with, or cut-off text that didn’t fit the UI. We report those issues so that developers can have them fixed, or work together to shorten the text, add new translations, or whatever is necessary. This screenshot review service is free for developers that localize with us.
It’s that final polish that separates Babble-on from other app localization companies out there. But you’ll have to see for yourself!
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.
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.
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!
You’ve got a great app and and great name. Should you localize that too? It’s one of those common localization issues and what comes next is that unavoidable:
“It depends…”
Does your app name have a trademark or proper name in the title?
If it does, case closed, you will probably want to leave that app name in English. Any trademarked app name that you plan to aggressively market internationally is best left untouched. Apple, for example, doesn’t translate Safari in any language. It’s not that “Safari” is an untranslatable word, it’s just that Apple has spent a lot of money making people associated the word Safari with web browsing.
In other words, ifyou expect your audience to learn and value the app name despite it being in a different language, and want it to be consistent across countries, then you can leave it.
Japplenese: Notice that Apple itself doesn’t translate Safari and App Store in Japanese, but basics like Settings, Mail, and Messages are localized.
Is your app name impossible to translate?
If your app name is a clever play on words like “Luv N Haight” you may also want to leave it. We could of course translate “Love and Hate” for you, but would that be the same thing? Another problematic type of app name to localize is concatenated titles like InstaQuote. We did not translate this app name because, well, it just doesn’t make sense to.
App Name Localization for Discoverability/SEO and Usability
If you answered “No” to the two questions above, I would strongly consider translating your app’s name. There are two main reasons for that: discoverability and usability.
Your international users are not searching the App Store for “puzzles” they are searching for rompecabezas, quebra-cabeça, головоломка, 益智遊戲, or パズル.
App titles are often more than just a word or two. Many developers will use a very long extended app title, which appears only in iTunes. This allows you to include more keywords in the title, which are all indexed to improve your search rankings.
Another reason to translate an app name is usability. Most developers do not have huge marketing budgets or trademarked feature names. After all, just because you call a feature EasyCheckPay doesn’t mean that it is going to catch on in every language. It’s better just to translate the feature name so your users understand its function. In fact, sometimes that same EasyCheckPay feature appears elsewhere in the app as Easy Check Pay. That’s an indication to us that the meaning is more important than the name and should be translated.
Say my name
When we localize software, in each case we ask the developer directly whether they want the app name translated. In fact, we’ve found a handy way of asking without having to explain much of the above:
We always ask developers how they want their app name translated.
You may also want to change the display name of your app as it appears to users on their iPhone home screen. This name must be short (just 12 characters) or it will end of like “My Great A…ame. To change the name of your app on the iPhone home screen (Springboard), create a file called InfoPlist.strings and add it to each language-specific project directory where you store other resources for the same localization. Localize the name on this line:
“CFBundleDisplayName” = “Appli FRANCE”;
What’s in a name?
Even when you have decided to translate your app name, the real work goes to the translator. App name localization isn’t always as straightforward as you might think, even when it’s a good idea. It is important for the app’s name to sound natural in the localized language, and requires translators who understand the app, and thoughtfully consider the app title in order to create a natural translation.
For example, we recently localized the new puzzle game Lost Toys. In the game, players must restore “lost” toys by rotating puzzle pieces back to their original form. (It’s fun, check it out!)
After discussion with the game’s creators, we agreed Lost Toys was a good candidate for translation—it’s a new game with a clear title and no trademarks or proper names. That’s when it got difficult.
What is a “lost” toy? Is it missing, abandoned, forgotten, or rather some runaway toy looking to escape a child’s hands? Okay, perhaps we’ve gone too far. The point is that “lost” in English actually conveys several meanings at once, and for a game title like this, we wanted every language to be equally vivid.
Some languages, such as Spanish, sounded great in a fairly literal translation of the word “lost”. The French and German translators, however, both felt that a translation closer to “forgotten” would better convey the meaning of the original. All the variations conveyed the meaning of the original, while also sounding natural in translation.
The name of the game
Every language has its own conventions regarding the translation of app names and titles from foreign sources. Sometimes when we translate an app, certain titles will be left in English purposefully for some languages, while they are translated in others. It’s important to consult a professional translator for advice when making these decisions.
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 
