3.4 Localization With the I18N! Plugin
Localization is an important feature of our applications when they are used by a geographically diverse user base. In this lesson we see how we can add a scalable and simple localization mechanism with another of RequireJS’s plugins.
1.Introduction2 lessons, 06:55
2.RequireJS Basics4 lessons, 27:18
3.Handling Common Tasks5 lessons, 51:21
4.Advanced4 lessons, 22:08
5.Conclusion1 lesson, 02:59
3.4 Localization With the I18N! Plugin
Hi folks. In this lesson we're gonna see how we can easily internationalize our simple app using another of Require's official plugins, the I18N plugin. It works in a similar way to the text plugin that we looked at earlier, in that the plugin will be automatically loaded by Require whenever we prefix the path to the module that we want to load with a special identifier. So first of all, let's download the plugin to our external directory. We can also get this file from GitHub. [BLANK AUDIO] So first of all, let's add a new path to this module in our config. [BLANK AUDIO] So the I18N plugin is used to load different language modules based on the browser's language and locale settings. We've already got a module which contains all of the strings that are displayed in the app's UI. So this can serve as the default or root language module. We just need to make a couple of changes to our app's folder structure. The I18N plugin expects all language modules to be within a directory called nls. So first of all, let's create this new folder inside the SRC folder. [BLANK_AUDIO] Inside this we should create another folder called root. We can then move our ui_strings file into the new root folder. [BLANK_AUDIO] So now we need to add a new module to the nls folder which configures the app's language supports. So let's create a new file directly in the nls folder called ui_strings. Inside it, we can add the following code. So this tells the I18N plugin that we want to load the root module which is our original ui_strings module. Now there's a couple of different places where the ui strings module is used, namely our view modules so we just need to update the paths in these modules. In both places we should update the path in the dependency array to use the I18N plugin. So now, if we run the page in a browser once again. We should find that everything is exactly the same as it was before. Which at this stage is good. The difference is that we're loading the new ui_strings module. Which is then loading the root language module. Which is our original UI underscore strings module. The great thing now though is that we're almost completely set up to support any other language or locale that we want. So let's say we want to support Czech in our app. First of all we need to create a new folder in the nls folder called CS hyphen CZ. [BLANK_AUDIO] So we can now add another ui strings module to this folder which contains the translated strings that we want to display. So I've already got this file set up. Here are the strings in Czech form. So now I'm just gonna copy this into the new folder that we just created. So now we just need to signal to the I18N plugin that we want to support Czech. So we do this in the module in the top level nls folder. That's it. We're done. Our app is now internationalized to the Czech language. So to test this is working, I found it's easier to switch to IE briefly, and we just need to make some changes to the region settings in the control panel [BLANK_AUDIO] So I've just set the format and location to Czech Republic. [BLANK_AUDIO] And now let's load our app in IE. [BLANK_AUDIO] And as you can see, it's automatically detected the browser's locale settings. And our app has automatically localized the visible strings to those found in the Czech language file. [BLANK_AUDIO] Okay, great. So our test app is starting to get the functionality that it needs, but there's still a lot of work to do. So let's wire up the add task button so that we can actually add tasks to our lists. The functionality for this can go into the list view model, because it's a part of the list ui. So first of all, we just need to make a minor modification to the renderer, because all of our tasks are being rendered to the same container. So let's just update the render method so that it takes a fourth parameter. And we'll call that parameter, use child. It will be a bouillon. So when this parameter is true, we want to apply the bindings to the intermediate container instead of the container. Otherwise we won't be able to add more than one task. [BLANK_AUDIO] Great, okay. So now in the list view model, we'll need to require in the task manager, renderer, and task view model modules, as well as the task.html view. [BLANK_AUDIO] And now we can add the following function to the List View model. [BLANK_AUDIO] So the new method that we've added is quite simple and differs from the method to create a new list only very slightly. We create a new task, select the list from the page, and create a new task view model. Which we then set some properties on, including an ID, which matches the task position in the tasks array. So lastly we just need to pass the container, the task view, and the task view model, along with true for the new fourth parameter to the renderer. And then we can remove the task name from the input, and lastly we just need to return the task view model that gets created. So we can use the same bind trick to create the handler function to set to this object for the main add task method that we just added. And now let's update the task view model. So we'll want to use knockout inside this module as well. [BLANK_AUDIO] And now we just need to add the bindings to the task view. [BLANK_AUDIO] And don't forget we'll also need to bind to the add task handler method from the list view. And let's just go back to the browser now and check that everything is working as it should do. [BLANK_AUDIO] So it looks like the task name is not being added correctly. Let's see if there's any errors in the console first of all. There's nothing going on in the console, okay. [BLANK_AUDIO] And our task model just needs to accept the name of the task. [BLANK_AUDIO] It's interesting that that's not working. Let's go back to the code and we probably need to get rid of the task name after we've actually rendered it. [BLANK_AUDIO] That's better. So in this lesson we saw how easy it is to provide simple language modules that contains strings in another language that we want our app to support. We can support as many languages as we have translations for. We saw that we should use a particular folder structure where the root folder is nls and all sub folders are named after a lang-locale. We then just need to tell Require which languages we support by setting the lang-locale as a key and true as the value in our root module. Thanks for watching!