Conf42 JavaScript 2022 - Online

Internationalisation(i18n) & Localisation(l10n)

Video size:

Abstract

From this talk the audience will get to know what exactly internalisation and localisation is, how are they related to or different from each other. How i18n can help them upscale their app and increase their user base. They will know how an application can be created to support multiple locales so that the users from different parts and origin around the globe can use their apps in their native locales (language). They will also learn about the common challenges around supporting i18n and how to address those challenges. They will also get to know about the browser support in the context of i18n and l10n. We will also touch base around the Right-to-Left language based app rendering. The audience will also get to know that i18n, l10n are not specific to the textual content but they also deal with images, numbers, currency etc.

Summary

  • We will be covering multilingual software and apps, internationalization and localization. We'll also touch base upon RDL and the browser support available while building multilingual apps. If there are some gaps, probably in next few slides we'll identify those gaps.
  • Multilingual software is something that can be rendered into multiple languages. This process require two phases, internationalization and localization. It's the future of app development because whatever you are building today, you want all the users to use your application.
  • Next topic is localization. Target based localization means it's not like we just have to translate our content. Not everything can be localized. Why do we need internationalization and localisation like we have seen in the first slide? Every business needs an expansion.
  • To make your application internationalised, you have to take out all the textual content to some config. The same config has to be translated into the destination language. The challenges include contextual translation and conditional rendering. Third one is the translation cost.
  • Some users, they don't understand English. So that means I have to translate my application to their native language. How can I do this partial translation? Either you segregate your resources into multiple files. These are some of the interesting challenges which you will face when you try to start within internationalizing your application.
  • This raises an interesting concept called as right to left. Some languages, such as Arabic, Hebrew, urdu, Farsi, are written and read from right toleft. Should those application be also rendering from left to left? There are different ways to achieve this.

Transcript

This transcript was autogenerated. To make changes, submit a PR.
Jamaica real time feedback into the behavior of your distributed systems and observing changes exceptions errors in real time allows you to not only experiment with confidence, but respond instantly to get things working again. Those everyone, let's start today's talk on internationalisation and localization. So this will be the agenda for today's talk. We will be covering multilingual software and apps, internationalization and localization. Why do we need these and what is the process to set it up? What are the challenges and complexity we may see when we implement these into our application? We'll also try to touch base upon RDL and the browser support available while building multilingual apps. Let's take an example. There is a user who is trying to browse some content on web using site one. Unfortunately, site one supports only English and this user is not a native english user. So what alternative he has? Probably he'll drop site one and he moved to some other site, for example site two, which is a multilingual app. There he can choose the language of his choice and can browse the content happily. So he was not satisfied using site one. Thus he moved to site two, means site one has just now lost a valuable customer to site two because they couldn't implement multilingual apps. So the question to be asked here is, is my app ready? Is my app capable enough to cater the need of the app? Can all the users across the globe use my app? If the answer is yes, then I think we are on the right track. But yeah, if there are some gaps, probably in next few slides we'll identify those gaps and we'll try to make our application to be used by every users across the globe. So let's see what is there in the next few slides. Multilingual software what do we mean by multilingual software? As those name states, something that can be rendered into multiple languages. So these are the softwares or applications that has the capability to render in multiple languages with just no to minimal change. It's the future of app development because whatever you are building today, you want all the users to use your application. You don't want to build different variants of your application just to cater a particular market segment. This process require two phases, internationalization and localization. So we will be covering up those two topics in the next few slides. What is the end goal here? I think every business wants expansion, so they want to globalize their business. They want to globalize your application off platform. So globalization is the goal of building multilingual software. So you want to build any application which every user across the globe, no matter which language he belongs to, which region he belongs to, he should be able to use your application. So that's the end goal of building internationalized application. What is internationalization then? As the name suggests, it is something to internationalize your application across the nations, across the locales. So it is shortened as I 18 n because there are 18 letters in between. In those is the process of making localization possible. So basically what we are doing here is we are actually architecturing our system or platform in a way that tomorrow if we have to introduce a new language or locale, we should be able to do that without any additional change. So this is a capability to adapt. Different locales is the backbone of app translation. So if you want to translate your application from English to, for example, German, right? So you have to have internationalization in place. It's not like you can directly translate your application because that is also possible, but that requires a lot of effort and lot of cost involved into that. There are approaches through which this internationalization and localization can be implemented, so that you need not worry about those changes at runtime or deployment time. Things can be hosted separately outside of your source code. Then the next question is, is text the only thing that should be internationalized? I think the answer is no, because there are some other assets available on your application, like images, currency, numeric representations, punctuations. All these things should be internationalisation because different locales have different representation of these assets. So if you don't internationalisation it now, then you won't be able to localize it later on. Next topic is localization. As we can see, there are ten letters in between l and n. That's why it's shortened as l ten n. Those is a process of translation to different locales. So in those first phase we actually made our platform or application as internationalisation one, where now the setup is ready. Those next step is to put different locales into your application. So translating to different locales is localization. Target based localization means it's not like we just have to translate our content. We have to see what all segments we are going to cover. What are the different languages, different country, different locales we are going to cover based on that localisation should happen. Then once the localizations are in place, the application should be thoroughly tested. Because when you change the translations or locales of any language into your application, the problem you can see is some of the distorted UI, some of the improper translations, all those things have to be tested thoroughly. Not everything can be localized. In the last slide we have seen what all can be internationalized. That was a limited set though. This says not everything can be localized means okay, you translated your text, you translated your images, currency, everything is localized now. But still there are some technical terms, some names which should not be localized. So based on your application requirement, we have to figure out what all things should not be localized. So those things we have to keep outside of our internationalization scope. Why do we need internationalization and localisation like we have seen in the first slide? Every business needs an expansion. They want a global market footprint. They want to build an application that will be used by each and every users across the globe. In the second slide or in the first slide we have seen that there was a user who was not very satisfied. That's why he moved from site one to site two. So customer satisfaction is one of the aspect or one of the motivation behind internationalization. And we all know a happy customer is like contributing to your sales or growth of the organization, right? If the customer is not happy, he will drop, but if he is happy, probably you will get some conversion from his access to your application. Avoiding cultural conflicts. There are some text or some visuals which are okay in some language, but has some inappropriate or some conflicting or offensive meaning in different locales. So to avoid all those things, translation is good because you are actually going to mold or modify those content based on the target locales. So there won't be any situation where you can see these cultural conflicts. I think one of the important aspect is if I have to launch my application to a new segment. New market segment, right. For example, I have built some application in English, German and Dutch and I want to launch the application in some of the region, like maybe Chinese. Right? So what I have to do is I have to just put those locales or the translation in and I can launch my application into that local market. So the time to market while launching your application into a new market will be relatively very less compared to building an application from those scratch. Okay, so this is the process of translation. What we have to do to make our application internationalisation. First of all, you have to take out all the textual content to some config. Mostly this common approach of putting a key value pair separated from your code base is followed. So if you can see in the first one there is a div with hello word, which is hard coded text into your application. So what we have to do is we have to extract those hello word text to a config file where there will be a key called as hello underscore content and then the text hello word. So this is the english content. So means this config is going to contain all the english text. Now we have to actually translate it to some other language. If you see the third image on the right side which is having a different language. So whatever was in English, we have translated it to for example German, right? And then in your code you will just get that config loaded and just say config hello content. And based on your selected config, it will either render this in English or German. So once you have extracted all your static text, but of your source code, what you are going to do, you are going to do some translation of these config like I have done in image three, the same config has to be translated into the destination language. Then you have to take user's language and pick the right config. So in this example I have two configs ready, English and German. And based on the user preferred language, I will pick one of the config and my application will be rendered using that config only. Like we discussed, numbers, currency, formatting, everything should be localized. So if you can see this example, there was a number, 123456, dot, seven, eight, nine. And if you can see I am translating it to German, which is be and then japanese and then enin. So you can see every localization is having its own representation. Somewhere the currency is at the end, somewhere the currency symbol is at the first place, someone is using dot and someone is using comma instead. So you can see there is a difference. Those is a subtle difference when you actually localize this number. And so you have to do all these changes into your application to make it internationalized. Then the next one is conditional rendering. So there are still chances where your application is initially rendered into some language, for example maybe in German, and then somebody said translate to English and you should be able to translate it. Or instead of user preference settings maybe you have exposed some option where you have provided a drop down where somebody can pick any language so they will be able to pick the language from there. And conditionally you should be able to pick or update your config. What are the challenges and complexity? So implementing I think internationalization in can existing app is more tricky because you don't know where all you have ecstatic text. So you have to first find out or extract all the text. Writing a new application into an internationalisation way is still better because you are still building your application and instead of just moving things from source to some locales config, probably you can directly add your text to the localization config. So I think implementing it in an existing app is a bit challenging. One contextual translation, let me take an example. Import and export. So when we are talking about an application, import and export means importing of data into some format like Excel, CSV and all. And exporting is to take the data out from the app. But if you use the same term into some shipping business which says okay, import means importing of goods from one place to another place, or exporting the goods from. So you see the context is changing a bit. So that's why context translation is very important. So when you are translating these strings or text, make sure you know in which context those are being used into your application. This is handy when you are giving your translation to someone else who is not aware of the application or the business. Third one is the translation cost. So most of the time you are either not familiar with all the languages or you want to offload this to someone else. So people used to give this responsibility to some third party organizations who will do the translation on your behalf. So that means there is a translation cost involved. And this translation cost, unfortunately is not a one time cost because every release you are going to add new features to your applications means you are going to add new more text, more content, more messages on your application, and those needs to be translated on every. So it's like a recurring cost that your application will have to pay. But still, I think this cost is still bearable considering a cost to spin up a new application into that language. Localization testing as we have already discussed in the previous slides, once you translate your application, you have to test both from the quality of the content as well as the UI. For example, I have built some UI assuming some character length, but when I translate that text to some other language, those character length got breached. So that means my UI will break somehow. So that's why testing can application after putting in the latest localisation is really important overhead in case of partial translation. So I have one interesting use case. Let's say I am having a platform or application where I have two user personas. One are the system admins and the other one are the system users. So there are some pages into your application which are only being used by the system admins. So system users, they are not going to see those pages. Now, let's say all my admins, they are good in English, so they can use my application without fail. But some of the users, they don't understand English. They understand their native language only. So that means I have to translate my application to their native language. My application is internationalized, so it's not a big deal for me to translate my application. But what is matter here is the translation cost. If I have to translate the entire application, it will have some cost associated with it. But I want the translation only for the end user pages. I don't want to translate the admin pages because those end users are never going to see the admin pages. So how can I do this partial translation? So I think I paste this somewhere in the past into one of my projects. And what we thought of doing was that either you segregate your resources into multiple files and there will be one which is used for admin and the other one which is used for end user images. And based on whether your user is admin or end user, you will render either the end user file only or admin plus end user file. Or what you can do is you can namespace your resources in the config. So in the config where you have all these key value pair, you can namespace those, maybe suffix or prefix them with something so that you can identify, and you can translate only those resources which are required as end user level. So these are some of the interesting challenges which you will face when you try to start within internationalizing your application. I think this is one of the interesting, and one of my favorite images I have seen in those past when I started looking into this internationalization stuff. So you can see there are three images. In the left one there is a user who is very lazy, kind of sleepy. And then the next image says there is an energy drink. And the third one you can see is full on energy. So I think what I'll drive out of this image is that I think this guy, after drinking this drink, this energy drink, he got some energy, right? Just flip the sequence and you can see there is a guy who was full on energy after drinking this energy drink. He is stuck, he's down. So you see, just by changing the sequence of events, the ordering of these images, the meaning got completely changed. In the first slide, it was like an advertisement of this energy drink. And in those slide, I'm not sure how this will impact this organization, who is dealing with this energy tank. This raises an interesting concept called as right to left. So we have some languages, we call them RTL languages, such as Arabic, Hebrew, urdu, Farsi. So these languages are written and read from right to left. So that means if you have to build any application using these languages, should those application be also rendering from right to left? I think the answer is yes. So you have to toggle the layout. Most of the application they have sidebar on the left and on the top navigation bar. Their menus start from left to right and they have a layout which will usually drive from top to bottom and left to right. So all these things should be flipped, should be mirrored. So your sidebar should be coming from the right and your menu should be starting from the right. Your layout will flow from right to left. So this thing should happen. And then you should also change your input language. So when you're typing something, should you be able to type only in English or since your application is Arabic, you should be able to type in Arabic once you're typing how the rendering should be. Because when you're typing in a field, it should be right aligned right it should not be left aligned. Then the text representation. You definitely have to change the flow of the text as well. Image transition and slideshow I think this is what we have seen in the previous slide that you also have to take a look at the slideshow whether your back and forth navigation, they are working as per the RTL notation or not. What are the browser support available to implement this? There are different ways to achieve this. If you are working with HTML, I think you can use this attribute dir equal to RTL. So if you use this then your direction will be RTL. The default is obviously LTR. Then there are some tags like BDI, bi directional isolation elements. So if you have a mix of RTL and LTR content. So browser will use its bi directional algorithm to decide whether has to render that into left to right mode or right to left mode. Then on the CSS also you can do this thing by putting this props in direction equal to RTL. Then you also have your custom css written into your application. So what you have to do is you have to figure out if there are direction specific rules. For example float left right or margin left margin right padding left padding right. If you have those kind of rules defined into your custom CSS, probably you also want to segregate those. So most of the time what we usually do is we create one common config, one common cSs where there is nothing specific to direction and then we create one lTR CSS and one RTL CSS based on the user language, whether it's RTL or lTR. So let's say if the user's language is ltr, we'll pick common plus ltr. If the user's language is rtl, we'll pick common plus rtlcss. This way we can actually try to control the layout of our page. Then, like we have seen in the currency conversion in two slides back where we were actually translating some number into german, japanese and english iron. So there are some Javascript built in function, two locales, two local strings. So you can find a numerous number of Javascript functions available to do this job for you. There are some other things to be taken care while you are working with those internationalized application. So let's say you have a text, you have a message, right? So translate the text as a whole. Do not try to translate it partially because sometimes you feel, okay, I have this common text into two messages. Probably I'll just translate it separately, and the rest of the things I'll translate and then probably I'll try to concatenate these two strings. That's not the right approach, because in this way you will lose the meaning of that message altogether. So that's why it's preferred to translate those whole text. Do not translate partially, don't just rely on language code. You should also look at country code, for example, en us engbc. You see, we are talking about English only, but they have their own country codes associated with it. Because the language is different, the locales are different. That's why instead of focusing on language, I try to focus on a word called as locales. Right? So you have to focus on the locales, not just the language. Do not design your application based on any assumption, like, okay, my content will be rending in this space because the moment you translate it, you don't know how much space will it take. So try to build generic or dynamic content applications. I think this is what I have. Thank you everyone for listening. Let's go global. If you have any question, any doubt, or any suggestion, feel free to reach me. Thank you so much.
...

Mayank Kumar

Senior Software Engineer II @ Rakuten India

Mayank Kumar's LinkedIn account



Awesome tech events for

Priority access to all content

Video hallway track

Community chat

Exclusive promotions and giveaways