After localizing everything in your app, you still need to make sure content coming from an external server is localized for your users. In this video, learn about a few techniques for telling your server what language your user expects to see.
- [Man] Most apps have a need to display content that comes from an external source like a server. We'll talk about the best way to manage that content in a couple of different areas. In first is server-driven content. If I had to guess, I would say that your app isn't static. You'll typically have to connect to a server and need to show content based on responses that you get back from the server. For example, let's think about our sample local news app. If this were a real app, when you open the app, it would make a server call to get the latest headlines and then return them to your app.
You can see in this sample response the headlines are returned in English. So what happens if you localize all the strings in your app but then still have your content coming back in your default language? You wouldn't be able translate all possible headlines and ship all of those translations with your app so you need to have the server provide that translated content back to the app on each request. By adding an Accept-Language header to every call, with the desired language, you're signifying to the server that you want your headlines but that you'd like them in Spanish.
Of course, your server developers will have to check for this header and your content providers will have to provide translated headlines, but if that's all set up, then you can request and display the right content in your app. Let's take a look at how to set this up with OkHttp. OkHttP is a very common Java networking library that lets us make and receive requests on the network. So when we set up OkHttp, we can add some code to it that will run on every request and let us attach this Accept-Language header to it.
So in the Android Studio let's open up the LocalNewsApp class. This is the application class for our entire demo app. It's where we're creating out OkHttp client. So down here at line 23, we are just creating a new client, but instead we're going to build it out a little bit and add the configuration to it. So we'll use the OkHttp Client Builder and create a new builder.
And then we're going to add an interceptor to it. An interceptor is just an interface with one method and that method will run for every single request that's made for this OkHttp client. You typically use an interceptor for things like authentication or maybe logging, but in our case we're going to use it to apply this header to every single request that comes through this client. So inside of this intercept method, we can get access to the original request.
And when we import request, we want to make sure to import the OkHttp version. And we'll get it from the chain object. So chain.request. And then we want to build out our new request. So we'll create a new builder. Request.builder newRequestBuilder. And take the original request, create a builder from it and then apply our header to it with the header method.
So the name of the header is Accept Language. Accept-Language. And this an HTTP standard so your server developer should be familiar with it. And then the value for this header is going to be the language for your default locale. So we can access that with the locale object then getDefault. And then there's a method on that locale object called getLanguage that'll get the two character language.
So for English, that would be en, Spanish es, et cetera. So now we have our builder so we can create our new request. newRequest is going to equal the newRequestBuilder.build. And then we need to return the new request chained to the chain that was passed in. So chain.proceed with our new request that we built.
Now we just add a semi colon here for the builder and now we want to actually build the OkHttp client from the builder that we just created. And now there we go, everything's all set up. So let's go ahead and run the app in Spanish. Now because this app is not actually connected to the network, there is a little demo magic going on behind the scenes. But when we open the app we'll be able to see that the first headline used to be in English, should now be translated in Spanish.
And there you go. Where the first headline was English, now it's in Spanish. The next bit of server content you may have to handle is push notifications. When you get a push notification, typically the payload is in the notification and you just display it. Like in our previous example, it's always in our default language. But in this case, since push notifications are asynchronous, we can't add the header to the request. The responses just push from the server.
Instead, we need to set the user's locale information on the server as a property of their user profile. Wherever you're storing their name, email, profile picture, et cetera, you should set their language preference as well. And then when push notifications need to be sent, the server can get the user's locale, can get the right translations, and send to your device. Then you don't have to do anything but display the text sent. Getting your external content localized and into your app is one of those last details that adds the final touch to your fully localized app, so it's important to take the time to address it.
- The localization process
- Basic internationalization
- Choosing target markets
- Preparing your app for internationalization
- Translating your app
- Testing and releasing your translated app