When Apple Transcreates Headlines, and When it Doesn’t

As a translator and localization specialist, my candy is a well-translated headline. While most people will find that geeky or crazy, the few of you reading this likely know exactly what I mean. Headlines, by their nature, should not be literally translated. Instead, they require transcreation, the process of translating a text creatively for its expression and tone, rather than its literal meaning.

Last week I came across this clever headline for Apple Pay coming to Mexico in 2021:

No alt text provided for this image

Literally, it says “The most effective form of payment is cashless.” But this simple reading omits the transcreation play-on-words the Spanish translator employed with the words “efectiva” — effective, and “efectivo” — cash. It’s brilliant. Immediately, I wondered what the original English was, so I checked it out:

No alt text provided for this image

Cashless made effortless. I don’t know about you, but I like the Spanish transcreation better. A lot better. I further looked at the British, Canadian, and Australian versions of this Apple Pay headline and they were all identical. If I were the Head of Localization at Apple, I would push for the English to be changed to something more along the lines of the Spanish. Maybe “More bang. Less bucks.“? I don’t know, but the whole English-speaking world was given this uninteresting headline and heads should definitely roll. (I don’t blame the copywriter, by the way, as having been there myself, I know the copywriter definitely didn’t have the final word on this choice and likely provided various more edgy options.)

Imagine my surprise, though, when I checked the Spanish (Spain) version of the headline, where Apple Pay has been available for some time.

No alt text provided for this image

Pagar te costará menos. Paying will cost you less. Am I missing an idiomatic phrase in Spain here? Either way, I still really like the Mexican advertisement’s transcreation better. Isn’t it interesting how Apple marketing chose separate translations/transcreations for Spain and Mexico, but not for the US, UK, Canada, and Australia? All French-speaking countries also used identical headlines (see below). I wonder what the reasoning for this is. Swiss German got its own translation, but Swiss French and Italian did not. Go figure!

Now, my interest piqued, I had to check out a few more languages where Apple Pay is available. In Russia you have a rather mundane translation:

No alt text provided for this image

Бесконтактные платежи. Без усилий. That is, Contactless payment. Effortless. Now compare that to the more considered Polish translation:

No alt text provided for this image

Bezgotówk­owo, bezproblem­owo. Literally: Cashless, Problem-less. Wow! Warsaw did much better than their Slavic transcreation brethren in Moscow for this round. I’m even a fan of the comma between the words rather than the harsher full-stop in the Russian. Again, kudos to the transcreationist here.

Transcreation lessons

At Babble-on, our translators are always putting in the effort to make the language sound natural in their own languages. Literal translations are not what we specialize in because software has to be concise, and that doesn’t always leave enough room for literal even if we wanted it. I’m always amazed and heartened by the headlines they come up with as well. Studying these headline transcreations for Apple Pay, it’s clear that some of the translators given this assignment had more time or inspiration than others. Or, perhaps, they benefited from more relaxed project managers that allowed them to go with their creativity.

You’re probably wondering about a lot of other languages so here is what I could find, along with my best interpretation of the literal translation. (Please feel free to offer corrections if you speak the language and disagree, or notice any language-specific play-on-words!):

French (all countries): Le paiement dématérialisé. Encore simplifié.

Contactless payment. Even simpler.

Portuguese: Pagar nunca foi tão fácil.

Paying was never this easy.

Brazilian Portuguese: Pague sem esforço.

Pay effortlessly.

Italian: La semplicità paga.

Simplicity pays.

German: Einfach. Sicher. Bezahlen.

Easy. Secure. Pay.

Swiss German: Mühelos bargeldlos.

Cashless effortlessly.

Dutch: Betaal zonder cash. Betaal met gemak.

Pay without cash. Pay with ease.

Flemish: Geen cash. Geen moeite.

Cashless. Effortless, or No cash. No effort.

Norwegian: Betal fort. Uten kort.

Pay fast, cardless. (It rhymes in Norwegian)

Swedish: Kontantlöst. Bekymmers­löst.

Cashless. Carefree. (Rhymes)

Danish: Så nemt som et bip.

As easy as a beep.

Finnish: Vaivatonta valuuttaa.

Effortless currency.

Hungarian: Készpénz nélkül könnyedén.

Cashless effortlessly.

Japanese: キャッシュレスを、ここまで簡単に。

Cashless made easy.

Chinese: 免现支付，就该如此便捷。

Cashless payment should be so convenient.

Taiwanese: 無現金支付，無限輕鬆。

Cashless payment, unlimited ease.

Hong Kong: 零現金付款，零難度。

Zero cash payment, zero difficulty.

Bulgarian: Без кеш и без усилие.

Cashless and effortless.

Czech: Bezkontaktně. Bezstarostně.

Contactless. Carefree. (Rhymes in Czech!)

Slovak: Bez hotovosti. Bez starostí.

No cash. No worries. (Rhymes in Slovak!)

Greek: Πληρώνεις χωρίς μετρητά. Πληρώνεις με ευκολία.

Pay without cash. Pay with ease.

How to localize SwiftUI elements in Xcode

Update: See our complete SwiftUI localization tutorial here

SwiftUI localization is easy… right?

TL;DR Using NSLocalizedString() is still the best way to localize in SwiftUI.

Sometimes Apple gets localization so right that it “just works”. At first glance, SwiftUI localization in Xcode seems like that. For example, look at this simple SwiftUI localization example:

import SwiftUI

struct ContentView: View {
    var body: some View {
Text(“SwiftUI Localization Tutorial”)
}
}

Did you notice any special localization code for SwiftUI yet? There was none. Because in Xcode 12, SwiftUI automatically includes literal text inside of Text() labels in all localization files. Just select Editor -> Export for localization… and the text “SwiftUI Localization Tutorial” will be included for your translators.

You can even turn off this automatic localization in SwiftUI using the verbatim initializer:

Text(verbatim: “SwiftUI Localization Tutorial”)

This text will be displayed in English no matter which language the user chooses. (This is a good way of leaving untranslatable elements, like your app name, out of the Xcode localization export.)

SwiftUI localization is incomplete

That’s the end of “easy” though. Most developers get confused as soon as they pass a variable to the Text() label, however:

var label:String
Text(label)

This won’t get localized. Xcode assumes by default that variables should not be localized. This is explained in the SwiftUI documentation from Apple. One way around this is to explicitly convert the text to a localized string key:

Text(LocalizedStringKey(label))

If you use LocalizedStringKey, Xcode does look for a localized string to replace the variable. But—and it’s a big but—the text won’t get exported for localization automatically. You must add it manually to a Localizable.strings file at the top of your project hierarchy.

There are other types of hard-coded strings that must ALSO be localized into every language. For instance, text inside a Button() call or navigationTitle().

Button("Go to Localization Tutorial", action: goTutorial)

Text inside of Button() labels need to be localized, just like the text blocks in previous examples. But localizing buttons doesn’t come “for free” with SwiftUI Localization. Why? I have no idea, but hope it will be rectified in future Xcode and SwiftUI localization updates.

SwiftUI localization using NSLocalizedString

The easiest way to localize all hard-coded strings in SwiftUI is the same way we localize text in Swift generally. Use the NSLocalizedString() macro:

Button(NSLocalizedString("go.button", value:"Go to Localization Tutorial", comment:"Takes user to the tutorial page"), action: goTutorial)

The NSLocalizedString() macro lets you choose a unique key for the text, include the default (English) value, as well as add a comment for the translator. These texts inside NSLocalizedString will be exported into your localization files! For a full tutorial check out:

iOS Localization Tutorial

One last note about comments: Comments are important because your translator might not be able to “see” the text in context. Telling a translator the text is a button helps a lot. A headline, for example, might be translated differently in many languages.

Further reading:

SwiftUI Localization Tutorial

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!

Pseudolocalization update helps with Excel, CSV translations

New Choose 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.

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

Approve and pay for localization right from your phone

approve

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

Screen Shot 2016-02-02 at 4.19.51 PM

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).Screen Shot 2016-02-02 at 4.20.18 PM

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.