Locale is the representation of a specific region. In this video, learn how locale is used on Android to customize your users' experience, and why to be wary of APIs that use the default locale.
- [Instructor] Let's define another term, locale. Locale is the representation of a specific region. Here's the locale for the United States, E-N underscore U-S. En indicates English and US indicates that it's English specifically spoken in the United States. Locales are used on Android to tailor the app to that specific region. Not only is it used for language selection but also other region-specific things like currency, temperature, date formatting, et cetera.
Now when thinking of localization, you might only think the language is important, but the region is important, too. Here with a different locale we have the same language, English, but instead of the U.S., we have a different region, Great Britain. Each entry we looked at before is different in the E-N underscore G-B locale. The language is still English, but color is spelled with a u, the currency symbol uses pounds instead of dollars, and the temperature is given in Celsius instead of Fahrenheit.
Let's take a look at how locale is used in code. In our local news app, on the article page, the publication date of the article is displayed. To format that date, let's look at the code. We're using Java's date format class to get a predefined date formatter. We're specifying that we want the medium length date format and if we look back, then we can see that medium length format gives us the month and the day and then the year.
Because I'm in the United States, it's giving us this default format. If we go in the code, we can manually specify a new locale. Let's say we want to see the UK locale. Now if we go into that same article view, we'll see that the date format has changed to put the day before the month. In practice, you don't want to force the locale, you want to use the user's default locale, but you need to be aware of the fact that this is using the default locale.
If you're not aware of the default locale it can burn you. See this statement in the docs for locale. Be wary of the default locale. But why? There are a number of places in your app where you may be using the default locale, which works fine when that default locale is English. But when you run your app in a different locale, now the default is that user's language. Different locales can behave differently, so unexpected behavior can occur. Let me give you an example.
I was working on a project where one part of the app took a string that we got back from the server and converted it to lower case to use locally. At the time we didn't realize that the lower case conversion takes your default locale to convert your string. We found that out when we saw a bunch of users in Turkey were having the app crash whenever they tried to sign up, but this crash was only happening in Turkey. We were able to reproduce the issue on our end when we used the test device and set the locale to Turkish. Then we were able to figure out the source of the crash.
We were taking the word tennis and converting it to lower case. Which looks fine at first glance, but if you look more closely you can see that in Turkish, on the right, the lower case I is actually a completely different character. That string was used for a look up elsewhere and so since the Turkish lower case I didn't match the English lower case I, the look up failed and the app crashed. So, since we are using this text just in code and not displaying to the user, we set the locale to always translate to lowercase using the US locale.
Which is really a best practice for dealing with machine-readable strings and code. It's best to use the US locale in that case. So, whenever working with locale, be wary of the default locale.
- The localization process
- Basic internationalization
- Choosing target markets
- Preparing your app for internationalization
- Translating your app
- Testing and releasing your translated app