Transcript
[ Music ]
>> Good morning.
Wow.
Thank you.
[ Applause ]
Thank you, very much.
And once again, welcome to your
first session at WWDC.
My name is Joaquim.
I don't think I have to
reintroduce myself.
Karan, Dongyuan, and I are
really excited to talk to you
about internationalization, at
long last.
So, what are we going to talk
about?
I'm going to do a brief
introduction, like I started
doing.
And we're also going to do some
deep dives on making your app's
layout adaptive.
And also, cover some really fun
discussions on text, as well.
So, why is this important?
This applies to every single
app.
Internationalization is a
crucial concept and we're going
to go over some of the details
as to why it applies to every
single app, regardless of the
set of languages that you
support.
And once again, this is all
about reaching out to more
people.
It's enabling everybody to learn
about and use your app.
Regardless of the language they
speak or the country that they
live in, or the country that
they grew up in.
And it's important to note that
those last two might be
different, as well.
And that's something that's
worth keeping in mind.
So, internationalization covers
a wide range of topics, and
potentially, every single aspect
of your app.
And if you're new to the topic,
probably, the best way to think
about it is that
internationalization is best
applied as a constant process.
It's a discussion that belongs
in every single stage of your
app.
Whether it's the initial
inception, its design, to its
implementation, and even
distributing it on the App
Store.
Things like your App Store
screenshots and even your app's
name should be open for
discussion in an international
context.
And like I said before, this
covers a wide variety of topics.
At Apple, we have a lot of
firsthand experience about this.
So, we estimate that over 70% of
our customers are outside of the
United States.
And this means that when
somebody downloads your app they
expect that app to match your
language preferences.
And not only that, but also, be
aware of any details that might
be related to their region
settings, as well.
We support exactly 38 different
written languages and many, many
more keyboards and input methods
for people to type and text.
And what this means for you, is
you have a rock solid foundation
to get started with.
Every single one of our API's
supports these languages and
input methods.
And this means that you can get
started right away by using
these and you're off to a great
start in providing really great
international support to your
app.
So, for example, this might
entail presenting dates and
times.
This wouldn't be an
international talk if I didn't
talk about dates and times.
But it's important to think
about, right?
Because people have different
expectations around the world.
This is the [inaudible] Sao
Bento in Portugal.
It's a lovely train station.
But my focus today isn't so much
the train station as much as the
way the times are presented in
the train station.
And if you go there, you might
notice that everything is in
24-hour time.
And this is true, not just in
train stations, but it's
commonplace everywhere in many
countries.
And so, your app should know
about these and present time
accordingly, depending on the
region.
And you can do this using date
formatter.
It's a set of APIs we provide
that lets you do this.
And it really does all the heavy
lifting for you.
Another example is calendars.
There are many different
calendrical systems around the
world.
And it's also important to note
that many people use more than
one on a daily basis.
They might use one for religious
or festive events and another
for business.
And these all have different
properties like leap months and
leap years and different numbers
of days and different numbers of
months.
And so, being precise about
these and knowing how to present
these appropriately means being
internationally aware.
This is an example of the iOS
Calendar app showing the Chinese
Lunar calendar on top of the
Gregorian calendar.
And we have a set of API's in
Calendar and alongside Date
Formatter that help you do this.
Could also talk about units and
measurements.
Whether it's presenting things
in the metric versus the
imperial system, or even
temperatures like Celsius or
Fahrenheit.
Your app should be aware of the
appropriate regional defaults
for these, and also, respond to
changes in the user's
preference.
And not only that, whether
they're units or not, even
numbers themselves.
There are so many things to
cover there from the decimal
separator to the thousand
separator.
And even, the entire class of
digits used to represent and
talk about numbers.
These can change between
regions.
And if you use number
formatters, your app gets this
behavior for free.
And this is important not only
for consistency, but also,
understandability.
Text is, also, another great
topic with many different areas.
And depending on the language or
languages that you grew up
learning and writing, and the
scripts that those language are
written in.
You might have thought that
there are some properties that
are completely immutable across
other scripts and other
languages.
And that might not, necessarily,
hold.
One example, probably the
biggest example, is script
directionality.
So, some languages, like Arabic
and Hebrew, and in this case
Urdu, are written and read from
right to left.
Which, is completely the other
way from English, from what you
might be used to.
And taking this further, many
books, most books published in
traditional Chinese and Japanese
are presented in vertical and
right to left.
And so, knowing about these
formats and knowing about the
context in which it's
appropriate to present these and
adapting your layout for these
could be an important aspect of
your app.
And are why frameworks alongside
our text frameworks like TextKit
and CoreText can help you make
sure you're doing the right
thing in every single one of
these cases.
Going a little bit higher level,
even things like names.
Depending on where you grew up,
you might have a first, middle,
and last name.
Or a family name that comes
before your given name.
And again, knowing how to
present these, and even asking
your user about these could be a
crucial part of your app.
And this is something that users
expect that you get right and
know about the details and
intricacies of formatting names.
And we have
PersonNameComponentsFormatter
API that help you do this.
Okay.
So, throughout all of these
concepts it's also important to
note that many of the users
might interact with and speak
more than one language on a
daily basis.
Whether it's because they moved
countries, or simply because
that region, in and of itself,
uses more than one language.
And taking this example further,
even if your app only supports
one language it's very likely
that your customers are using
your app to publish and consume
content in their own native
language.
And so, regardless of the set of
languages that your app
supports, these are all still
very important topics to
consider and talk about
throughout the design and
implementation of your app.
So, if all of this is new to
you, worry not.
Like I said before, we have a
great set of APIs that really do
all the heavy lifting for you
and take care of all these
different aspects.
And are aware of all the
different details between
languages and regions.
These are some examples of the
Formatter APIs that I talked
about.
And we've, also, got some great
sessions that go into great
detail on how to further tailor
these for your app, as well.
So, let's start our first deep
dive in to layout and some of
the goals related to
internationalization when it
comes to adaptive layouts.
Because, really, the core goal
of an adaptive layout is to
present all kinds of different
information.
And when you're adapting your
application for other languages,
probably, the biggest guarantee
that you'll get is that these
translation lengths are going to
be different.
They're going to be much shorter
or much longer, depending on the
language.
And this is something that your
design and layout should adapt
for.
On top of this, there's also
directionality, like I mentioned
before.
Because some languages are
written in right to left this
has some design considerations,
not just in the text that you
have in your app, but also, the
way you present information.
Especially, horizontally flowing
information and how that general
flow should adapt for both
script and writing directions.
So, a great starting point to
help you do all of this is Auto
Layout.
You might have heard of Auto
Layout, before.
This is a powerful technology
that is at the core of our
layout engine.
And Auto Layout, instead of
describing explicit frames or
positions of your controls and
labels, describes constraints or
relationships between these
views.
And therefore, how they're
positioned relative to each
other and how they're allowed to
grow relative to each other.
On top of this constraint-based
system we have the idea of
leading and trailing
constraints.
And what this means is that
this, essentially, describes
properties that are left and
right in a language like English
that automatically evaluate to
right and left, respectively, in
a language like Arabic and
Hebrew.
And this means that with Auto
Layout you can create these
adaptive layouts that flow
depending on the writing
direction without having to
write special code for either
one of the writing directions.
Another great starting point is
to use high level components and
containers that we provide in
our UI frameworks.
Because these use all of these
concepts and are aware of how to
be adaptive.
Some examples are collection
views and stack views that we
provide, both in UIKit and
AppKit.
And you can create really
complex layouts and even embed
these within each other to,
potentially, even just create
the whole layout of your app
just using these.
Just as an example for Stack
View itself, I could arrange
these horizontally in a Stack
View.
So, I have the city name on the
left and the time on the right.
And this is, this could just be
put into a horizontal stack
view.
And because this flows left to
right in English and because I'm
using a StackView if I run my
app in Hebrew, this is the
result I would get.
Because that information would
adapt automatically.
Because StackView is aware of
these concepts and uses Auto
Layout
under the hood.
If you'd like to learn more
about Auto Layout and details on
how to adapt your application
for different writing
directions, these are some great
starting points to check out, as
well.
So, when it comes to the text in
your app and the content in your
app the key goal here and,
obviously, the number one
recommendation is to simply not
assume fixed widths.
If you don't do that you're off
to a great starting point in
terms of allowing your app to
adapt to, not only different
changes in length horizontally.
But even, potentially, allow
your labels to grow vertically
and adapt to multiple lines if
necessary.
And this is something you'll
have to decide in your app and
your app's design on what you
want to prioritize in terms of
what is allowed to grow and use
up the real estate of your app.
If your labels and your controls
are either in stack views in
these high-level components that
I mentioned before, or
positioned using Auto Layout
itself, this work is pretty much
done for you.
You're already allowing your
labels to grow and your controls
to take up the content that they
need to take up.
And then, it just becomes a
matter of prioritizing how you
want to let them grow relative
to each other.
So, this is great.
Let's say you've done all this.
And how, exactly, do you make
sure that your app is checking
off all the right boxes in terms
of adaptive layout and
responding to all of these
things?
Well, the good news is that
Xcode provides a number of
features for you to test.
And not only that, it allows you
to test early and find these out
quickly in the development, and
early on in the development of
your app.
One example is pseudolanguages.
Pseudolanguages are great,
especially, when you haven't yet
added language support to your
app.
So, what you can do from within
Xcode is run your application in
a pseudolanguage and this
changes a few details of the
layout and text of your app.
One example is the bounded
string pseudolanguage.
This adds a few characters at
the beginning and end of every
single UI string that you
display.
And then, you can see, make sure
that there aren't truncations or
unexpected clippings in the
content of your app.
So, this is a really useful one.
And we have many more
pseudolanguages that can help
you out, as well.
Specifically, for Auto Layout we
have Auto Layout warnings built
into Xcode.
So, Xcode can tell you about
common antipatterns right within
an interface builder.
And this can be things like
fixed width constraints or too
few constraints on a control or
label that might, potentially,
introduce issues at runtime,
especially, in other languages.
So, with that, I'd like to hand
it over to Dongyuan, who's going
to give you a demo of all of
this in action.
Thank you, so much.
And hope you have a great week.
Thank you, [inaudible].
[ Applause ]
>> Thank you, Joaquim.
Hi, I'm Dongyuan.
Let me show you some techniques
to [inaudible] and some common
pitfalls to avoid in real world.
Here's an app called Vacation
Planet, which is the first
interplanetary travel agent that
allows you to book travel for
not only other countries, but
also, as you can see in this
table view, other planets.
So, I wanted to go to the moon
for quite a few times.
So, I can do that, this time.
And here are all the locations
available on the moon and their
distance from Earth.
Let me choose the location like
the Clavius Base.
And here is our Travel Details
page.
It seems pretty cheap for one
trip.
So, I'm going to buy more
tickets.
Let's buy three of them.
And there we go.
As you can see, because we
design and developed the app in
English our layout works great
in English.
However, we still want to make
sure it can adapt for other
languages.
Because we are still early in
the development cycle and we
haven't localized the app, yet,
we can use the pseudolanguages
in Xcode.
To do that, I'm going to go
through the Current Scheme,
click Edit Scheme.
And in the scheme editor I have
an Application Language
selector.
I can select one of the
pseudolanguages like the Bounded
String Pseudolanguage.
It's very useful for exposing
potential clipping or truncation
issues.
Let's run the app in this
configuration.
As you can see, this
pseudolanguage adds a few
special characters at the
beginning and end of every UI
strings.
Our tag line here is still good.
But the Browse button is
truncated.
Let's try to fix that.
When I select the Browse button
I can see that there's a wording
in Xcode.
The wording shows that we have a
fixed width constraint and that
may cause clipping.
If I want to know more
information, I can click on the
I button.
I'm going to fix the issue by
click the growth, sorry.
By click the Warning sign.
Here are three options.
I'm going to select the first
one, which is simply remove the
constraint to allow the button
to be wider when there's more
content.
Let's do that.
Okay.
No other layout issues.
And then, I'm going to show you
a very simple way to verify the
change that was made.
I'm going to go to the Assistant
Editor at the top right corner,
the middle button here.
Here I can select Preview and
Main tell Storyboard.
The Preview pane allows you to
view your layout in multiple
screen sizes and different
languages without running the
app.
On the bottom right corner, I'm
going to select the first, the
same Bounded String
Pseudolanguage we just used.
Great.
Because we don't have the fixed
width constraint, anymore, our
Browse button can now
accommodate a slightly longer
string.
Another very useful
pseudolanguage is the Double
Length Pseudolanguage.
It's for verifying your layout
against potential languages that
have longer string length, like
German, Finnish, or Russian.
They can sometimes be two times
longer than English.
Let's see if that works.
Now, the Browse button is still
okay.
But our tag line is clipped by
the screen boundaries.
When I select the label, I can
see that we only have a center X
constraint.
We don't have any leading or
trailing space constraint, so
that the label can overflow.
Let's add a leading space
constraint to fix that.
Again, I'm holding down the
Control key, drag from the label
to [inaudible] view, and select
Leading Space to Safe Area.
I can select the constraint to
adapt at just its value.
Let's put something reasonable,
like 20, for the margin.
And here, I can see instantly
that my label is no longer
clipped.
However, it's still truncated
and it's a very important
message we want to show to all
of our customers.
That's not ideal.
Instead of truncation, I can
allow the label to wrap into
multiple lines when necessary.
Here, when I select the label I
can see that we have Lines
property set to one, which means
we only allow one single line
for the label.
If I change the value to zero I
can allow the label to wrap into
any number of lines, when
necessary.
I can see that my label is now
three lines in this Double
Length Pseudolanguage.
If I switch language back to
English my label is still one
line, which is exactly what we
expected.
I, also, encourage you to check
the app down here, where you can
select different screen sizes.
I encourage you to check your
layout in the smallest device,
like iPhone SE, because clipping
and truncation are more likely
to happen in the smaller
devices.
Now, I wonder if our layout can
adapt for right to left
languages, like Arabic or
Hebrew.
As I said earlier, we don't have
localizations for those
languages yet.
We can run another
pseudolanguage.
Let's open the Scheme Editor,
again, this time in application
language.
And I'm going to select the
Right to Left Pseudolanguage and
run the app in the simulator.
Okay.
Browse.
As you can here, our table will,
now flows from right to left
without us making any changes.
That's because we used
UITableView and other standard
UIKit components.
The system had done the hard
work for us.
All the section titles are now
at the right side, which is the
leading side for right to left.
The chevrons here are at the
left side, which is the trailing
side.
I'm going to go to Jupiter, this
time.
And you may notice that the Back
button is now at the top right
corner, instead of top left.
That is, actually, very natural
for right to left languages.
Let's select a location on
Jupiter.
So, here's our Travel Details
page.
Everything seems to be okay,
except the stepper and the
Traveler label.
The first issue is that the
stepper should be at the
trailing side, which is the left
side for right to left.
The Traveler label should be at
the leading side, which is the
right side, here.
And also, there's an unnecessary
spacing for the Traveler label.
Let's fix that in that Interface
Builder.
Let me locate our trouble zone
cell, is here.
Okay.
Zooming in a little bit.
When I select the Traveler label
and the stepper I can see that
there's no constraint on them.
That's not good.
And of course, Xcode has a
warning for that.
So, one way to resolve the issue
is to add a leading space
constraint for the Travelers and
a trailing space constraint for
the stepper.
Leading and Trailing will
translate to right and left for
right to left languages.
However, here I'm going to show
you an even simpler way, which
is to use UIStackView, a
high-level container view that
uses Auto Layout under the hood.
By using Stack View I can get
right to left support for free.
Let me select the two views.
And click the Embed down here at
the bottom right corner.
Select Stack View.
Now, my two views are inside
this UIStackView.
The only thing left is to add
constraints to the Stack View
itself.
I'm going to select Stack View,
click the Add Constraints
button.
I'm entering four zeros, here,
because I want the Stack View to
fill the table view cell as much
as possible.
And I like to select the
Constrain to margins here,
because I want some default
margins for the Stack View.
And I want the leading edge to
align with the cell separators.
And add four constraints.
There you go.
And I'm going to verify my
change.
Yep.
Browse.
This time, I'd like to visit
Earth.
And I'd like to go through
Lisbon, Portugal, to visit
[inaudible].
Do that. Now, as you can see,
because our Traveler label and
the stepper is now inside a
UIStackView, we get right to
left support for free.
Let's book this travel.
Great.
Now, let me summarize what we
talked about.
So, to make our app layout great
for our global audience, there
are a few simple steps.
First, is to use high level
containers like StackView
whenever possible, as they
provide a lot of heavy lifting
for you.
And believe me, they are just
simpler to use.
For finer control, remember to
use Auto Layout and make sure to
use leading and trailing
constraint so that you can adapt
for right to left languages.
For early testing without even
localizing your app, you can use
the pseudolanguages in Xcode
Scheme Editor.
And please, don't ignore the
Auto Layout warnings in the
Interface Builder.
They are very useful for
avoiding clipping, truncation,
and overlapping issues.
Now, over to Karan to talk about
text.
[ Applause ]
>> Thank you, Dongyuan.
Good morning, everyone.
Let's talk about text.
At Apple, a high quality
typographical experience is a
key part of our design process.
And it's very important to us
how text looks on screen and how
it's designed.
And also, the way that it
translates to other languages.
So, let me walk you through some
key aspects that we keep in mind
when we localize our own apps
into other languages.
And how you can take advantage
of these things to make your
apps look great in other
languages.
Now, I'm going to talk about
three main topics, set up some
fundamentals with languages and
scripts.
And then, dive into typefaces
and styles.
Let's talk about languages and
scripts.
What is a script?
So, when I'm talking about
script, I don't mean a Bash
script or a Python script.
I'm talking about the way that a
language is written.
So, the writing system.
The letters that you use to
write a language.
These are some of the scripts
that we support that are written
from left to right.
We, also, have scripts that are
written from right to left.
The key thing to note about all
of these scripts is that they're
multilingual.
So, each script supports a huge
variety of languages that are
written in it.
And as you can see, the Latin
script here supports everything
from English to Vietnamese.
And this is true for other
scripts, as well.
For example, the Cyrillic script
supports a variety of different
languages.
And if you look at right to left
scripts, we see that the Arabic
script, not the Arabic language,
but the Arabic script supports a
variety of different languages,
such as Arabic and Persian,
Urdu, etcetera.
So, what you're seeing on
screen, yes, there's a lot of
visual variety.
But this is not just for show.
There's, actually, a lot of
implications when you develop
your apps and different scripts
because some concepts don't map
across scripts as easily as
others.
So, let me show you a few
examples of this.
Let's talk about typefaces.
So, here you see the Health app
in English.
So, you see a lot of labels.
Now, you see the same app in
Catalan.
And lastly, you see the same app
in Vietnamese.
Now, the thing that I'd like to
call your attention to is that
all the text here on screen is
rendered using our system font,
San Francisco.
And the other thing I'd like for
you to notice is that everything
is rendered beautifully.
That's because San Francisco has
support for a huge variety of
different languages.
And when you use the system font
in your apps, you're guaranteed
to get that support for free.
Now, any text label that you
create in Xcode will get
San Francisco by default.
But if you want to go one step
further, use a text style.
We support a variety of
different styles in our OS that
are meticulously implemented to
support a variety of different
use cases.
And also, to map across
different languages, really
well.
So, when you use a text style
you guarantee a consistent high
quality experience to your
users.
You can also go one step
further.
If you set your label to
automatically adjust its font
size, it will do so with respect
to the user's text size setting.
And this is really handy for
people who use smaller or large
sizes for their text.
Like myself.
So, I highly encourage you to
use that and this will ensure
that your text styles scale
appropriately.
But let's say, that like us,
we're making this Vacation
Planet app to go to Jupiter, to
go to Mars.
And we wanted to have this fun
vacation look to it, which it
doesn't right now, because
everything is in the system
font.
So, we decided that the title of
the font should evoke the
personality of the app.
And so, we looked at a few
different fun fonts to choose
from.
We looked at this one, for
starters.
But as Joaquim mentioned from
the start, we like to keep
localization as a central part
of our development and design
process.
So, the first thing we did was
to check does this work for all
the languages we need to
support?
Well, we already had a French
localization.
So, we tried it out.
As it turns out, it doesn't.
So, we kept looking at our short
list of options.
And we looked at this other
typeface.
And when we tried it out in
French, voila!
It works because it supports all
the characters needed for
French.
So, that's great news.
So, the next step for our app
was to expand to Vietnamese.
But we didn't have a Vietnamese
localization, yet.
So, one great tool that you can
use is FontBook, which comes
installed on every Mac, even if
you're not a developer.
It comes installed on every Mac.
And in FontBook you can easily
search for the name of a
language, like Vietnamese, here.
And we see here, that in the
font that we chose Vietnamese is
in the set of supported
languages.
In fact, this font also supports
Cyrillic and Greek script.
So, we are somewhat sure that if
we expand to Russian and
Ukrainian and Greek later that
this font will work for us.
Now, I should advise some
caution here.
Just because FontBook says that
a font supports a given language
doesn't mean that you don't have
to, actually, test your app in
that language.
You still need to make sure that
the font really works for that
language, by trying it out.
So, we've got our beautiful fun
font for our Vacation Planet
app.
And now, we're going to expand
even further.
So, we want to do more
languages.
Specifically, we want to
localize into Chinese.
Okay.
So, we sent off all our strings
for translation and they've come
back.
And our app is now perfectly
localized into simplified
Chinese.
Cool.
But it's not really, though.
Because look at what happened to
the title.
So, in English, we have this fun
font, but in Chinese we are
using the system font.
That's because our font only
supports the Cyrillic, Greek,
and Latin scripts.
So, of course, the way to fix
this is to repeat the same
process for Chinese.
And here now, we have out fun
font in Chinese.
It's as simple as that.
And unfortunately, I can't
really help you with that.
That's a stylistic thing and you
have to choose your own fonts.
But I can show you how this is
done in code.
So, this is really
straightforward.
First of all, you start with
your font for your development
language, normally.
Such as, in our case, it's
English.
So, we choose our Latin script
font and get our font here.
And the key concept that I want
to introduce you to, here, is
called a Cascade List.
So, a Cascade List says if I'm
looking to render this Chinese
character and this first font
doesn't have it, what font
should I use after this to look
for this character?
Now, if you don't specify a
Cascade List you're going to get
the system font.
But if you do have a Cascade
List, then you can specify other
fonts to try before falling back
to the system font.
So, in this case, we create a
Cascade List with a font
descriptor for our font for
Chinese that we hand-picked.
Now, if your app supports
multiple scripts you add
multiple things here and that's
as simple as it works.
And once you've got a Cascade
List you create a new font
descriptor.
And then, you create a new font.
Pretty straightforward.
And also, make sure that if your
app used dynamic type, which it
really should, then your font
should adjust to that, as well.
And again, that's as simple as
an API call.
Let's see some examples.
So, this is the new Word of the
Day screensaver in macOS Mojave.
And as you can see, for this new
design we've chosen a rounded
style.
And of course, it wouldn't make
sense if we didn't, also, choose
equivalent rounded styles for
all the languages that the
screensaver supported, which
includes Japanese.
And also, new in macOS Mojave,
simplified and traditional
Chinese.
Another example is the Messages
app, in which you can respond to
a message using a tap back
reaction.
Now, here you'll see that the
ha-ha in English has been not
only translated to other
languages.
But has, also, been matched in
style, so you get the same
bubbly fun look in all the
languages that we support.
That's it for typefaces.
Let's talk about styles.
Again, I should start with the
definition.
What do I mean by a style?
So, broadly speaking, I'm
referring to aspects of your
text that you choose once you've
chosen a typeface.
So, let's say the font weight,
like how bold it is, or whether
it's italicized, and what the
size of the font may be.
So, the key thing to keep in
mind is that some aspects
translate better to other
languages and others don't.
So, let's take a look at an
example of where something might
not translate.
So, here we have a simple string
in English.
We've italicized Mars and 2
Travelers to indicate that
they're variables, so they can
change.
And this is how it translates
into traditional Chinese.
There are a couple of issues
here.
Mars is italicized in English.
It's not italicized in Chinese.
Why?
Because italicization is not a
concept in Chinese.
And it's not a concept in,
actually, most scripts outside
of Latin, Cyrillic, and Greek.
So, a design that uses italics,
probably, won't work.
The other thing to note is that
in Chinese there are no spaces
between words, and also, there
is no concept of uppercase and
lowercase letters.
So, you kind of lose a natural
distinction that you get in
English when you translate it
into Chinese.
A couple of small things to
note, also, is that the word
order is different.
And also, because the 2 still
comes from the Latin script and
is still italicized, it doesn't
look great.
So, how can you fix this?
Well, the keys to realizing that
you're doing emphasis, not
necessarily italics.
And emphasis can be done in
multiple different ways.
This is a great way to do
emphasis that works across
several different languages.
In fact, it works for all the
languages that we support, which
is to bold a given word.
Lastly, let's talk about
emphasis at a character level or
sub-word level.
Let's say we have an app with a
Search feature and we want to
highlight the part of the
results that matched to make it
clear to the user what's
happening.
Now, this works really well for
English, by using a bolder
weight for the matched segment.
It works really badly for Hindi.
So, what you're seeing here, so
anybody who can read Hindi will
tell you that everything on the
right-hand side looks completely
broken.
Any time you see a dotted circle
inside a Hindi word, something
has gone very, very wrong.
And the reason this is happening
is because even though it's the
same font family, different
weights within that font are,
actually, a different font.
And you can't have the
appropriate joining behavior for
languages like Hindi if you have
two different fonts.
So, one easy way to solve this
problem is use a different kind
of emphasis at a character
level.
So, at a character level you can
use something like using a
different color.
For example, here we use black
color for the math segment and
gray for the remainder of the
word.
This works really well.
Now, you'll see some dotted
circles on the keyboard.
That's perfectly fine.
They're dependent marks.
And here's the same example in
Arabic.
Again, the same approach is used
all over iOS and macOS, and it
works really well for many
purposes.
And I should also mention that
this is really easy to do with
attributed strings.
Finally, let's go over
everything that we've talked
about.
First off, it's important to
start planning early in your
apps, not only the development,
but also, the design phase.
Once you know the languages
you're going to localize into
and plan to extend to in the
future, internationalize as you
go.
Technologies like Auto Layout,
StackViews, and dynamic type are
very simple to adopt while
you're in the process of
building your feature.
But if you finish your project
and try to come back and use
them, then you may have to
completely rearchitect your app.
And that will be a lot of work.
If you're doing something for
which you feel, oh, yeah, there
should be an API for this,
right?
There probably is an API for it.
So, make sure that when you're
doing something like formatting
any kind of data, to make sure
to look to see if there's a
formatter class.
And also, make sure to look to
see if there is an API for
anything you're doing with text
before trying to ruin your own
implementation.
And lastly, ensure that nothing
is lost in translation.
So, the key thing to realize
here is that every localization
of your app is a unique
experience.
And you need to make sure that
your intent that you specified
in your development language
actually makes it over to all
the other languages that you
support.
And that nothing is lost along
the way.
Thank you, very much.
[ Applause ]