RONY ROZEN: As you probably know by now
because you watched our previous episode, adding support
for localization to your app right from the start
is important.
Not sure why?
Need a refresher on the basic use of NSLocalizedString?
Check out the previous episode.
I'll wait.
[MUSIC PLAYING]
So at this point, your app supports
one or more localizations.
As you're testing your app in one of the new languages
it now supports, you see that a word
you used in several different places
in the English version of your app
needs to be translated in different ways
in Portuguese, for example.
Maybe your combination poker telephone
app uses the word "call" in two different ways--
placing a telephone call and matching a bet.
This is how it's going to look like in the localization file.
One translation, since these are two uses of the same key,
with both comments so that the translator will
know where and when it's used.
If you want to separate this into two
different translations, this is what it's going to look like.
But wait-- we now have two translations for the same key.
That's obviously problematic.
How will the app know which key to use when?
Well one way to resolve this is to create two different keys
with the same translation in the English version.
This of course means that we'll also
need to change the code accordingly and use
"CallPhone" and "CallBet" instead of just "Call."
It also means that unless we provide the translation files
for the English version of the app where
the vast majority of translations are simply
wrote with identical texts on both
the left and the right side of the equation,
the user will actually see "CallPhone" and "CallBet"
and not "Call," but it will at least allow
us to provide each language with the most
appropriate translation for it.
We won't usually need to use this technique
but it's good to know it's an option.
And it also helps demonstrate how important the comment
parameter actually is.
There are several other elements of your app
that you should localize when launching to new locales--
images, for example.
Let's say you're working on a stock market app
and want to use an image symbolizing a successful market
so that your users will be happy, optimistic, and eager
to continue using your app.
You'll probably choose an image that
looks roughly like this, right?
The problem is that if you show this image
to a person in China, for example,
they are likely to look at your app in a negative way.
There, they have reverse connotations
for the red and green colors, so your image should actually
look like this instead.
The way you do this is quite simple
and requires no core-level changes.
Similar to what we did before with the localization files,
all you need to do is use two different images
with the same name--
one in the en.lproj folder, the other in the zh folder.
This way, the English version of your app
will use the green image, the Chinese version of your app
will use the red image, and all of your users will be happy,
which is all we really want, right?
We used images for this example, but you
can do the same thing with audio files
and pretty much any file type you can think of.
Xcode also supports the standard XML Localization Interchange
File Format, or XLIFF.
This is especially useful when you
have texts that are set via Interface Builder--
whether zip files or storyboards.
Instead of using the script we used in the previous episode,
you can select a project or a target
in the Xcode project editor, and then
choose Editor, Export For Localization.
This will generate an en.xliff file,
assuming you're using English as your base language.
This file will include the strings
from all [INAUDIBLE] Storyboard files
in addition to ones we specified with NSLocalizeString.
You can send this XLIFF file to the translator
and get a translated version.
For Spanish, for example, it will be es.xliff.
You'll import the translated files back into Xcode
by selecting the project or target in the Xcode project
editor and choosing Editor, Import Localizations.
The nice thing about using this method,
in addition to it being a format that
is well-known by translation companies,
is that it allows you to only worry about new translations
because each time you import localization,
the string files are merged with your existing project files.
And if you have strings that are set in Interface Builder
and not via code, you only need to worry about one localization
file per language instead of having one .strings file
for each [INAUDIBLE] Storyboard file and an additional
localizable .strings file for the strings set via code.
The last point I want to make about localization
is that it's important to remember
that words in different languages
have different length, so it's important to test
your UI in all supported locales and see that none of the words
get truncated, drops a line, et cetera.
English tends to be a compact language,
so words may end up being translated
to something with twice as many letters or words.
If you want to display the number of views
in a post on your new social media app, for example,
you'll need 15 characters in Italian instead
of just five in English.
And don't forget to consider the opposite case.
Shorter words can be just as problematic as longer ones
if your UI was designed for a specific word length.
My main point is basically be aware of the changing word
sizes in different translations and account for it
right from the start, already at the design stage.
I want to leave you with the concept
of internationalization.
In addition to having users who speak and read
different languages, being a word-friendly app
also means that you need to internationalize your app.
What does that mean?
Well, it may mean supporting right-to-left displays
for RTL languages such as Hebrew and Arabic.
It may mean supporting reverse uses of decimal points
and commas, as is customary in many European countries.
It basically means knowing your target audience
and what they care about so that you can design the best
app for their needs, and happy users lead to happy developers.
I hope you find this helpful and will
use this new knowledge to build more global-friendly apps.
I encourage you to look into additional IOS localization
topics we didn't get to discuss, such as locking
your views while waiting for translations,
testing the translations directly in Xcode,
or handling different units of measurement.
Until next time, I'm Rony Rozen for Route 85.
Thanks for watching.
[MUSIC PLAYING]