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 makes localizing screenshots easy
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 LaunchKit.io, 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.
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?
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:
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!
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:
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:
Windows 8 (Metro) .resw, .resjson, .resx, .rc
Ruby on Rails & YAML .yml
GNU GetText .po, .pot
XLIFF .xliff, .xml
Microsoft Office/Open Office .docx, .xlsx, .pptx, .odt, etc.
Plain Text .txt
DKLang .dklang, .lng
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.
Often I’m asked which languages an app should be localized into.That really depends on the type of app, and where the market is going to embrace it. But, speaking generally, if I had to pick the top app localization languages, I’d look no further than WWDC 2012 again. Take a look at the languages Apple has focused on for localizing Siri, its latest “app”.
Siri can tell you which are the top languages for app localization.
And there they are: French, Spanish, Japanese, Italian, Korean, Simplified Chinese, and Traditional Chinese. Siri has to listen to accents and dialects, so many languages are represented more than once here, for example French for France, French for Switzerland, and French for Canada. In my experience I’d add German and Portuguese to this list, and I wouldn’t doubt if those are next on Siri’s curriculum. But going forward the one to really focus on for app localization has to be Chinese.
Get your apps ready for China
“It’s going to be important. Get your apps ready for China.” Those are the words of Craig Federighi, Apple Senior Vice President of Software Engineering speaking to WWDC 2012 attendees during this year’s keynote. Make no mistake about it, localization into Chinese dialects is a critical part of global marketing and distributing apps in the booming (and expanding) iOS and Mac world. The App Store was recently updated to include support for Traditional as well as Simplified Chinese and a dozen other languages. But Chinese app localization, while a new focus at Apple, is already common amongst app developers.
App Localization Services Get Ready for China
App localization services (like us at app localization services at Babble-on) enjoy helping developers reach all the markets that iOS allows. Dozens of app localization languages are available for iPhone and it is clear from the data that users overwhelmingly download apps localized into their own languages. In fact, take a look at the App Store in countries outside the US and you’ll find that 9 out 10 of the Top Ranking apps are localized into the regional languages. It’s THAT important.
Now you know the top app localization languages. If you want to learn more, let me know in the comments.