Localization with Zach Brass

Localization with Zach Brass

In this episode, Leo talks with Zach Brass about localization, internationalization and making sure your app reaches a global audience. We also talk about all the new additions to localization from WWDC 2021 like AttributedString.

Welcome to another episode of Empower Apps. I'm your host Leo Dion.

Today I am joined by Zach Brass. Hey, Zach, nice to meet you.

Nice to meet you too.

I'm really glad to have you on.

I'm really looking forward to your talk at 360iDev.

The topic for today is localization.

Before we get started, I'll let you go ahead and introduce yourself.

Thanks for the cheap plug.

Hi! I'm Zach Brass.

I've been an iOS developer professionally since 2011, non-professionally since 2009.

I’m starting a new job on Monday at Facebook.


Thank you very much.

Standard disclaimer. Everything I say here is my own viewpoints. End of disclaimer

Thank you for that.

I’m a big localization nut. I love it.

It's really, really fun to learn about other cultures, other countries.

First of all, what is localization for those who don't know?

Localization and its slightly related term ‘internationalization’.

Localization is making a thing usable and good for other languages, countries, regions, locales.

And internationalization is prepping something for localization basically.

A lot of people use the terms interchangeably localization internationalization.

It's a little bit easier to say localization and so that's what I usually do even if I mean internationalization.

Yeah, that makes sense.

For me I'm a big video game player and I remember as a kid playing a lot of Nintendo.

Unfortunately, experiencing localization at its worst.

Yeah. I mean, one of the first internet memes...

Right, exactly. Go ahead.

Yeah, was a result of poor localization.

It was ‘All your base are belong to us’.

I don't know if some of the younger iOS developers remember ‘All your base are belong to us’.

But at the time when there were little to no memes in the world that was the thing, right?

And it was a result of poor localization.

It's funny because now I play on the Switch.

Obviously, they've picked up their game now.

Their game budgets have come up a little bit more and they understand localization a lot better.

I think it's a great example of why it's so important.

You can't just run things through Google translate and expect that to do everything for you.

Yeah, absolutely.

I mean, I have a sort of shorthand that localization really boils down to

reducing the assumptions that you make about your users.

But, yeah, it’s super important.

Right off the bat, just ballpark estimate.

What percentage of people do you think speak English at all in the world?


That's really close. It's actually about 20%. It's about 20% of the world’s population.

And you are including first language and second.

Any language.

Yeah, 20%. Okay.

20% of the world.

Now, what percent do you think of the world speaks English as a native language?

Oh geez! 8%?

It’s about 4.8%.

Wow! Okay.

Right off the bat just getting other languages really opens up your app to

a giant plethora of users that could not consume your app.

That's sort of the minimum bar and then you

go into things like culturalization which is

which is not just translating your app but really making it awesome for them.

It’s not just, oh, I have to switch my mental model to like American English culture.

And people feel seen when they don't have to

perform some cultural or language translation matrix in their head.

Right, yeah.

I think the culturalization thing is something I was thinking about too.

We talked about native English speakers but like

is that UK, is that US, is that Canada, is that New Zealand, is that Australia?

There's different cultural terms we use as anybody who's familiar with any international TV shows.

There's terms that we use that are different across different cultures even though we all speak English.


We see this all the time in not just software but like the media that we consume.

For example, I think it was Zootopia or something,

one of the newscasters was

I want to say an elephant,

I'm not sure, in the American version.

But in the Chinese version it was a panda.

Oh funny.

In the movie Inside Out there's a kid that is forced to eat her veggies.

I think it was changed from I want to say like Brussel sprouts to like green peppers or something

because of the cultural tenet of what's a disgusting food for kids to eat in some other culture.

Interesting. I didn't know that.

Yeah. So little things you can do to sort of make other folks feel seen.

What I've been hearing a lot is and we talked about this in the last episode with Steve was like

all the stuff with accessibility they came out.

What do you think is the relationship between localization and accessibility?

I think it's a similar mindset implemented in a slightly different way.

Localization boiling down to reducing your assumptions about the user.

That's also true with accessibility.

Apple in WWDC this year, 2021, really, really went in on

on diversity, equity, and inclusion.

And localization and accessibility are a really big part of that.

I forget what talk it was but they had this really fantastic graphic of diversity axis.

And it included culture, ethnicity, and language.

Things that are localization topics.

But also things like abilities, disabilities, age, handedness, body measurements, etc.

And all of those are accessibility tenets.

Applying that mindset to a different domain will get you far in both localization and accessibility.

And luckily, Apple makes it really, really easy to do both out of the box

but also make really fantastic experiences tailored to

folks with various accessibility needs,

and also tailored to folks in languages and cultures that you as a developer might not be aware of.

Okay. Yeah, that makes total sense.

How would you make the case to a manager that they should invest time and money in basically localization?

This is a fantastic question.

I love it and I have encountered it so many times.

The “We will never go into blah…blah…”, “We will never do this”, or “We need speed.”

I hear that a lot both in my own experience and in other people I talked to experienced.

And there's a couple of

There's a couple of framings that you can do to convince non-technical folks

or people that don't actively think about localization and/or accessibility.

For localization, if you do it right, all of your localized assets will be separated out from code, right?

So you'll have your asset catalog, you'll have your localizable.strings file, your .stringsdict.

and you’ll be able to take those and send them not just to translators but also to marketing folks.

Having all of your strings in one place is very, very good for non-technical people

and documentation folks to know what's in the app, right?

You don't have to go hunting for all of those individual strings.

If you make a language change, like a terminology change,

it is super easy to just come through one file - your localizable.strings - and change stuff.

Thing number two is that the investment to undo an app with poor localization is massive.

It will set you back.

It will basically be one big showstopper bug comprised of n number of little itty bitty bugs,

where n is the number of individual strings that you have in your app.

That doesn’t sound something fun.

Yeah. And finding them is not fun because they don't just exist in your code.

Some of them exist in maybe strings that you get from your server.

Maybe it is nibs and storyboards that you haven't localized yet.

And something that you might change the detail, text label of

a table view cell, but you don't change the text label.

And now you're screwed.

It just holds up development for a really, really long time.

I've been in projects where this happens.

For accessibility… I know the main focus is localization but really quick for accessibility.

If you want to do any sort of testing, most tests, most automated testing programs,

or suites, or whatever use the accessibility features.

And then the other thing that you can do is just do it.

It’s non-technical people that are reviewing your code, right?

It takes seconds longer to add something to a localized string file

rather than put it as a string literal. So they won't know.

You're in charge of the architecture. Aren't you?

Or you contribute to the architectural decisions as a software engineer.

They won't know the difference.

Yeah, so let's talk about like getting started with localization.

Is the first thing starting off with like a strings file I guess?

Is that the way you'd go or what would you recommend is the first place to start in your iOS project?

Yeah, absolutely.

I mean, one of the first things that I do is,

Command+Shift+N, new Xcode project, add a localizable.strings file.


It is at its base, at its core like add it now

so you won't have to think about, “Oh shoot! Where do I put it? Oh shoot! Do I have a strings file?

Yeah, yeah, yeah.

So it's there. It's a thing that you

just don't even have to think about. You just go do it.

Great. Right.

That's thing number one.

Thing number two is let the system do the work for you when it can.

Don't reinvent the wheel when Apple has done the job for you.

This is like formatters.

If there's a formatter for it, don't do it yourself – dates, numbers, measurements.

Yeah. There’s a ton of stuff in measurements right now.

It's massive. It's massive.

And not only that but like Apple is really, really good at localization.

For example, I was messing around with the measurement formatter yesterday.

The new formatter improvements in iOS 15

where you don't have to initialize an NS Formatter or a formatter in Swift.

And you can just do .formatted and then put in the format.

There are cultures that don't use unilateral measurement styles for a given measurement.

For example, if you're in Canada, right.

if someone were to estimate my height. If a Canadian who is really good at estimating my height,

they'd be like, “Alright, you're 6’1”.

But how fast is the speed limit once you cross over the Vermont border into Canada?

It's 100 kilometers per hour.

So they use imperial in some ways and metric in some ways.

And these formatters are smart enough to be like, alright, this is a measurement

and you're measuring person height, what's the output for my locale.

It's super powerful.
- Got you.

Yeah, it’s really powerful.
- Let Apple do the work for you.

Yeah, absolutely.

Let's talk about some of the new stuff that's come out this year.

We've got AttributedStrings. That's new, right?

The AttributedString struct is brand new.

Right. Because there used to be NSAtrributedString, right?

But that's different, correct?
- NSAtrributedString, yeah.

It is. There's interoperability between NSAttributedString and AttributedString in Swift.

But the power of AttributedString is so much bigger.

First of all, NSAttributedString is not…

I believe it's not a part of foundation. It's actually part of UIkit.

Oh really?

I realize it now. I've now said this on audio so someone's going to be like,

“I don't know maybe…”, “No, it’s not.”

They could look it up. Go ahead.

Yeah, go ahead and look it up.

But NSAttributedString, you have to do everything with NSAttributedString on the main thread.

And that was super not fun.

Foundation by the way.

It is in foundation. Damn. Alright.

We can just cut this up.

No, no, no. That's fine.

No, that’s fine.

But AttributedString, you can do it on whatever thread you want.

It now has markdown support which is massive, right?

That is massive.

And it allows easy localized attributed strings.

Previously, doing localized attributed strings with NSAttributedString

you either had to put in really complex HTML and render it as like.

Yeah, it’s a mess.

Render it all weird and stuff and it was really heavy.

The times that I sent HTML strings off to, like raw HTML,

in my localizable.stringsdict off to a translator,

they'd be like, "I don’t know HTML. What is going on here?"

Markdown is so much better. It's so much more concise

and it allows you to do less.

So the system knows what system Bold looks like.

The system knows what system Italic looks like, code voice, etc.

But it also adds a cool feature that I've been playing around with recently which is inflection.

Are you multilingual?

No, no.


Go ahead. I want you to explain inflection. I don't think I know what it means.


In English,

we don't generally change a lot of our language beyond just pronouns for someone's gender.

In languages like Spanish and French you do. You change adjectives.

You change nouns. You change verbs in some cases.

I know what you’re talking about.

In English, we just don't have a way of…

We don't have gender. We don't have word endings to refer for genders

like other romance languages especially [unclear]

Yeah, exactly.

And new in iOS 15 and the new version of Mac OS, and tvOS,

you can add inflection markers to your localizable.strings.

And using AttributedString it will change the term of address. It will inflect the string

based on your term of address which you provide to the system.

And that makes people feel seen, right?


And it's not just system provided stuff. But you can also in code represent someone's pronouns

which is very, very cool. Like it has the subject, object, reflexive.

I am totally blanking on all the different forms. But if you look up

I think it is morphology.custompronoun in Apple's documentation it has a complete description.

Of which kind of pronoun you want to use.

Of your pronouns. It’s really, really cool.

I've been trying to mess around with it. Go ahead.

Before we did the recording this week...

My wife studied linguistics, and I showed her what's new in foundation video

just the part where like you said they know what gender you are and how to address you.

Especially in Spanish. I think it's Spanish. That's the big one where they support that.


And then, like, she was really fascinated by that having studied linguistics.

And also dealing with plurals, like we’ve all,

every developer has had to deal with this in multiple languages.

And I mean programming languages,

and having to be able to automatically add the plural form of the noun

automatically depending on quantity. That stuff is really cool.

Yeah, absolutely. I mean, previously, you had to use a .stringsdict.

And if you want super specific behavior you still have to use a .stringsdict file.

There are a bunch of different things that you can search for on Stack Overflow

for how to set up a .stringsdict file.

Even in English prior to this version of iOS,

you had to go in every single plural that you

Right, right.

that you needed, you put in a .stringsdict file.

But the on-device machine learning to

to adjust it will make life so much easier for developers.

Right now it’s in English and Spanish only.

I’m really, really looking forward to how it is in Russian.

I don't speak Russian. But Russian is a really, really interesting case

where it has a different word ending for 1, 21, 31, etc., but not 11.

I think it has like a one, a few, a many, and an other.

So if it ends in 2 through 4, the word changes.

and like a 5 through 9, the number or the quantity.

- Yeah.
- Yeah.

But the nice thing is as an English speaker you don't have to know

all the stuff.
- Which one to use.


Yeah, which one to use. You just say English has a one case and an other case.

Or in some cases, one case, an other case, and a zero case so like

one apple, four apples, and then if you want to have a special zero case you can say no apples.

But with the new iOS 15 inflection,

in many cases you might not have to worry about that at all and just have one string.

- That's awesome.
- That's fantastic.

- That's awesome.
- So cool.

I think with... Yeah, go ahead.

Well, I was just going to say we've been talking a lot about strings.

But how about stuff like image assets that you can't really just automate that part.

And I'm trying to think what other pieces of media

you might want to like have dynamic depending on language.

Is there a built-in mechanism to deal with that?

Yeah. I mean, you can use asset catalogs.

And you can change an image based on a locale, a language.

I think it is locale and language.

Alright. Okay.

I’m going to double check.

But you're talking about the basic code, ISO code.

Because it could be en at US for English in the US

- Exaclty. Exactly.
- Okay.

But more importantly, asset catalogs are one of the ways

that iOS makes it easy for you to support language direction changes.

English is a left to right language, right.

There are many languages that are right to left languages.


A lot of languages used in the Middle East - Hebrew, Arabic, Farsi,

I think Urdu is written right to left as well.

And when you have your language set to one of these RTL languages a lot of the UI flips.

And for many image assets you might not want your asset flipped.

For example, if it's a logo. You probably don't want that flipped.

However, if it's something like a directional asset,

Or like a wordmark.

Yeah, something like that.

You might want to specify that hey in right to left languages

this asset should be flipped.

So you don't have to put in specific things in code to say alright

I want right to left or left or right.

You can. But asset catalogs makes it so much easier.

Also SF symbols will have different symbols based on your locale.

Oh wow! Cool. Is this new or this has been there for a while?

I'm not sure. But I know it's definitely

highlighted in the new releases with...

Yeah, number three.

with WWDC. Yeah, 2021.

So like just the signature, right, the signature symbol looks different in English

in Arabic
- That's crazy.

because the x is in a different location.

Even the script of the gibberish signature looks different in different languages.

It's really, really fascinating.

It’s those little tweaks that make people sort of feel seen.

Right. Exactly.

And make people sort of understand, ah yes, this software is designed with me in mind.

And I think that's really, really fantastic.

Apple is really good at making new technologies seem magic at first, right.

When there's a new technology,

oftentimes the first however long, the first bit where everyone's adopting it

it seems like magic and then it starts to get normalized.

We just sort of see it as a given, right.

Like internet connectivity.

When we first got the internet, oh my gosh it was fantastic.

But now we're like, "Okay. Of course, it’s the internet", right.

When the internet, when our connectivity goes down, or it’s slow, or whatever

like, "Oh my god, oh this is terrible..." and stuff,

not realizing that this thing is magic, right?

Yeah, right.

I think with some of these localization changes we've skipped the magic part.

Like the users don’t know that this is magic

and how cool the ML and attention to detail is.

Yeah, it just becomes commonplace and we forget about how much work was put in.

Was there anything else you wanted to talk about?

Let's see.

I want to talk about SwiftUI I guess in particular.


How does that work differently than UIkit?

Is it easier or more difficult to work with localization?

I think it’s a little bit different.

So things like RTL LTR switching - right to left, left to right

drive locale switching happens automatically.

I'm assuming that under the hood it uses the same sort of leading and trailing

stuff that auto layout in UIkit does.

I would say the big difference is that oftentimes you're not calling NSLocalizedString.

You know, the text in SwiftUI takes a localized string key

and automatically localizes it.

Actually, going way back to localizable.strings and localizable.stringsdict,

the way that it basically works is that think of it as one big dictionary, right.

And you're looking up the localized string key

and it's getting the value for that locale.

It's slightly more complicated than that. But like,

if you're just getting started think of it as a big dictionary.

And with NSLocalizedString you're explicitly saying all right fetch me

the value for this localized string key.

For SwiftUI text, it's sort of implied where anything passed into text

gets treated as a localized string key and the value gets pulled out.

Now, if you want to specify a literal you can. But by default it looks it up.

How do I feel about this?

I think it's a little bit of a trap, a little bit of a gotcha.

Because oftentimes when we see sample code or WWDC videos

that aren't explicitly about localization people just put the text in English

that you're going to see and it doesn't sort of become top of mind.

I almost like a little bit more verbosity around

around localization.

And the way that I get it is through LocalizedString key naming.

So a lot of the times when we see sample code

like this is how to do localization right, this is localization basics,

a lot of the keys are just the English values

of the string because ‘hello’ is hello.

This is a big pet peeve of mine.

Yeah, it drives me nuts too. I totally agree.

If it's going to be some sort of like common greeting,

my key will be common.label.greeting.

And it will just say hello.

The reason why this is a big gotcha, say, we're doing...

Our first language is Hebrew, right.

And we say shalom. Shalom is the word for hello in Hebrew.

Unfortunately or fortunately, it's also the word for goodbye and peace

so when the translator goes to look at it they're like

which one is it?

Are you are you saying hello? Are you saying goodbye?

This happens in English, right, like the word chat.

Is the chat a noun? Is it a chat or to chat?

And depending on whether it's

on a button like a menu item or the title of a view,

it might change.

So saying alright I'm just going to use the word chat, the LocalizedString key chat

For multiple different... in multiple different places

without understanding that the meaning is slightly different.

That's a gotcha, you know.

And just like accessibility, localization is a process.

You won't get it perfect every time.

And the important thing to do is test, test, test, test, and test.

You don't just send your strings off to the translator

and get your strings back or I should say your assets.

Send your assets off to the translators,

get your assets back, then just submit to the app store, right?

You integrate it and then you send it back.

You send it back to your translators or you find people to do a limited beta

in your language because

it might be embarrassing

from, “Hahaha! This is not fantastic grammar or not fantastic syntax”

or you might get in a lot of trouble culturally.

For example,

the Disney film Moana.

I believe in Italy she has a different name

because Moana is the name of an Italian porn star.

And so you can't just say, "Alright, I got the translations and now I'm done."

- Right.
- You have to test.


Yeah. That’s really good point.

What kind of resources are out there?

Let's say you have an app or you're building an app.

What resources are out there to get your strings translated into various...?

Are there services you'd recommend for something like that?

I don't have any specific companies.

I have never been in charge of selecting a localizer.

The sort of biggest localization project that I've been a part of

was at iRobot when I was working at iRobot.


And I was...

I was a little bit far away from selecting the translator.

That makes sense.

I was... Yeah, but iRobot to their incredible credit has second to none testing.

That's awesome.

They test software like they test hardware.

They are of the mentality of like

you ship it once

or act like you're only shipping once.

because that's what happens with hardware, right?

You can have firmware updates and stuff. But if there's a problem with the hardware

Like, it's already shipped.

Right. Yeah, exactly.

And so iRobot does a lot of testing

when there's a new locale, when there's a new language.

You have to send it to a bunch of different testers.

Do you have any recommended tools or libraries you use

to help you with localization in your project?

I’m a really big fan of the built-in Apple tools to be honest.


I know a lot of people really like BonMot

from Raizlabs/Rightpoint.

But I think now with the changes in

marketing. Sorry, the changes in markdown

in an AttributedString I think that may or may not have gotten sherlocked.

But I really think Apple is

pouring a whole lot of really good resources into localization.

And I would just say read the documentation. Read the Dub-Dub sessions.

Read the Dub-Dub sessions? Watch the Dub-Dub sessions

and learn.

Allow yourself to get it wrong and fix it.

If you have a formatting problem, that's okay.

This is why we have the app store and we have app updates.

Perfect is the enemy of done.

I totally agree with that phrase.

Yeah. iOS really has a lot of

features to help us get pretty darn close to perfect

and not think about this stuff, right.

Like date formatting,

just put in a date, describe the format that you want,

and iOS will handle it.

DateFormatter, all the formatters are really, really smart.

They know the locale better than you

chances are.

Yeah. I totally agree about the Dub-Dub sessions especially this year.

We'll post some links in the show notes to those.

They've been like,

They are phenomenal when it comes to localization

and some of the new stuff that's come out this year.

So definitely check that out.

Anything else you wanted to mention before we close out?


Let's see.

I sort of mentioned it earlier in the recording.


Command+Shift+N, new Xcode project, add the localizable.strings file,


and make sure to have a good naming system for your LocalizableString key.

It will save your skin so much.


That's really my...

Because once you get it started it's easy to change it, fix it,

and do whatever you need to do later as opposed to doing it

trying to get it in at a later point without that file.

- Thank you so much, Zach.
- Yeah, it is easy to do.

- Yeah, totally.
- That's okay.

No. that's okay.

But thank you so much for coming on. This has been fantastic.

I'm really glad we had you on to talk about this topic.

And I'm super excited about your talk at 360iDev.

I think it's going to be awesome.

Yeah, thanks so much. It’s super, super fun. Thank you so much for having me.

Hope you’d plug my Twitter handle and stuff.

Yeah, so where could people find you online?

Find me on Twitter @zhbrass.

That's mostly the only public-facing social media that I have.

If you have localization questions, my DMs are open.


I love geeking out about this stuff.

Yeah, this is awesome topic. I’m so glad we covered it this time.

Thank you again for coming on.

Thank you for having me. This was really fun.


People can find me on Twitter @leogdion. My company is BrightDigit.

Take some time to subscribe and like on YouTube if you're watching this on YouTube.

And post a review to Apple podcast or Google podcast wherever you're listening.

And I look forward to talking to you again.

Bye bye.

Creators and Guests

Leo Dion
Leo Dion
Swift developer for Apple devices and more; Founder of BrightDigit; husband and father of 6 adorable kids
Zach Brass
Zach Brass
Part swing dancer. Part iOS developer. 100% enthusiasm. Mentor @UnderdogDevs. Human to the world’s best cat. DM me cat pics if you think yours is better. he/him

Join our newsletter

checkmark Got it. You're on the list!
image of podcast supporter
Join 1 supporters
Mastodon © Bright Digit, LLC 2018