As many of you developers out there are aware, sometimes you have to build or bring with you a number of application infrastructure items before you can even get started with the core application logic. For example, you might need some helpers, services and base classes that make your job easier or allow you to start with your base patterns, such as, MVC, MVVM, etc.
So, I have decided to create a series of posts that build up a bunch of common, important parts of an application that you might want to have in place before you even start developing your core functionality. I have discussed a number of topics in my previous posts:
Building a Universal Windows Platform (UWP) Application (Part 1) – Using Template10
Building a Universal Windows Platform (UWP) Application (Part 2) – T4 and Strings
If you haven’t already read the previous posts, I recommend you do since they all build on each other.
Today, we are going to discuss how we can add multilingual support to our application.
Add Multilingual App Toolkit
Not all, but a lot of applications not only target one language, but multiple languages. So, let’s add support for multiple languages. To do this, we will install the Multilingual App Toolkit created by Microsoft.
Click on the Download button.
Once you select Download, you will be prompted to save the download. Select Save.
Now, you will be prompted to run the install. If you have Visual Studio open, you might want to close it. Better to be safe than sorry. Select Run.
At this point, you will be prompted to install the toolkit.
Once you have finished installing the toolkit, open the project again. First, select our UWPT10 project in our solution. Second, from the main menu select Tools, Multilingual App Toolkit and then Enable selection.
This will enable us to use the Multilingual App Toolkit for this project. Now, right click on the Strings folder, select Multilingual App Toolkit then select Add translation languages…
A dialog will popup prompting you for any languages you would like to support in your application.
For now, we are going to add support for Spanish. So, in the search box on the top right side of the dialog, type Spanish. Now, select Spanish. Notice the icons next to the language. This signifies that there are two translation providers that can be used to translate your strings. Now select OK.
Two things happen:
- A resource file for the language is created. Which is what you would expect.
- A new folder, MultilingualResources, is created and a file UWPT10.es.xlf file is created and placed in it.
So, if we open the Spanish resource file, what would you expect? Well, open it. Is it what you expected? Probably not. It is empty.
Why didn’t it fill in? Well, let’s put this on hold until I discuss the UWPT10.es.xlf file in more detail.
What Does the UWPT10.es.xlf file do for us?
Well, it is a common document format that translation services use. It basically holds all the status and translation information for a particular translation. For example, if we want to have a service translate our English resources to Spanish, we would create a XLIFF file and have them translate it on their end with a tool. (Actually, in some cases you could just send them the whole resource file and they can probably create a new XLIFF file.)
So, when we added the new language with the toolkit, it automatically created it for us. However, if you open up the file in the editor, it looks like this…
You can see some cool information. Like source and target language, where the original resource file is located, a list of strings to translate, state of each string and if we are supposed to translate it or not. However, as a developer, you don’t want to have to learn yet another document format, right? (the answer is no).
So, with the installation of the Multilingual App Toolkit, a XLIFF file editor was included. This is nice, because someone who is translating information for you can just install the toolkit and get the editor for free, do the translation with the too and then send you back the file with the new translations.
What is the this crazy all powerful editor that I speak about? Well, if you right click on the XLIFF file, and select Open With…, you are given a choice of what tool you want to use to open the file.
From this dialog, scroll down to the Multilingual Editor and select it. Since you will probably never want to edit the file by hand, select Set as Default. Then, select OK.
The Multilingual Editor will open the file and look like this…
I won’t go too much into all the details of the editor, but there are a few things to note:
- You can select the resource you want to manage in the list at the bottom.
- You can see the source string.
- You can see the target string.
- You can set the state of the string. This allows you to set the string as New, Needs Review, Translated and Final.
- The tool also lets you translate the one or all of the strings to the appropriate language using online service providers provided by Microsoft. You can also get suggestions for a specific string and choose from one of them.
So, for our demo, lets convert our “Welcome Everyone!” text to Spanish. First, let’s open the editor, select our message in the list and select Translate. Remember, this will attempt to translate the string using the Microsoft providers available for this language.
If everything went well, you will now see that the string was translated and the state has been set to Needs Review.
If you are happy with the translation, you can now set the State to Translated. Now select Save.
Go ahead and close the Multilingual editor. Now, do a build and open Resources.resw from our Spanish folder. It should now look like this …
Nice! Now you are an expert translator right? Well, not really, but this will surely get you started.
Okay, now that we can translate our strings, let’s see them in action. First thing we will want to do is make sure that the Spanish language pack is installed on your machine. To do this, open Settings by hitting your Windows key and typing Settings. Select Settings from the result list.
Now search for region and select Region & language settings.
Once you have selected Region & language settings. If you don’t already have the Spanish language pack installed, you need to add our Spanish Language pack by selecting the Add a Language option.
The Add a language dialog will be displayed with a list of languages. To save time, in the search box, type Spanish. Select the Español option.
At this point, you will be selected to choose from a subset of Spanish dialects from various countries. Type u into the search box and then select the United States version of Spanish.
At this point, you should see the new Spanish pack in your list.
Okay, we are almost there. Now, we can finally test our application with the new language. Note, if you were to run the application now, you would still only see the English version of our strings. Whatever the language is set as default, will be displayed if we have a resource for it. So, in order to test he Spanish language pack, we simply select Español, then select Set as Default.
You should have noticed that the Spanish pack we chose now moved to the top of the list and has a message: “Will be display language after next sign-in.”
Since we don’t really need the whole Windows UI to change, we don’t need to sign-in. All we have to do is run our application.
Bueno, si? There you have it.
(NOTE: Don’t forget to change your default language back to English or you will be surprised the next time you sign-in to Windows.)
What We Accomplished In Part 3 Of Building A Universal Windows Platform Application
So, to summarize what we accomplished in this blog post:
- Added the Multilingual App toolkit to the project, created new Spanish translations using the Microsoft Translation provider and tested out our application with another language.
- How we can change our language quickly to test the changes in our application without restarting Windows.
I know, the blog post got pretty long. However, having the ability to add new strings, get them translated and use them in code this early in the software development lifecycle is pretty nice.
In Part 4 of our Building a Universal Windows Platform Application series, I thought it might be a good idea to implement a logging service so that we can log issues to a local file. This can be very useful when trying to analyze issues with the software.
I hope you enjoyed this post. If so, please share it with others.
Part 1 – Building a Universal Windows Platform (UWP) Application (Part 1) – Using Template10
Part 2 – Building a Universal Windows Platform (UWP) Application (Part 2) – T4 and Strings
Part 3 – Building a Universal Windows Platform (UWP) Application (Part 3) – Multilingual Support
Part 4 – Building a Universal Windows Platform (UWP) Application (Part 4) – Logging w/ MetroLog
How about cross platform support for iOS, Android Ave UWP in Xamarin.Forms?