Hello, Salut & Hola? Internationalization in your Google Actions
When Google Assistant was released, it was only available in English, and it was great at the time, however, its growth was such that it was necessary to work on its availability for different languages.
Since then, thanks to the support of Google and the communities we have Google Assistant available in different languages: English, German, French, Japanese, Korean, Spanish and many others.
And why am I saying all this? Because you’ve probably did something like this with your Google Assistant configured in English:
It’s likely that the result was not as expected 🙃. To avoid these lapses, we’ll work on the internationalization of our application. But before we start, let’s review a couple of terms that are necessary to know:
- Language: An agreed upon, spoken and written mode of communication.
- Region: A defined physical area that’s usually associated with a country.
- Locale: The combination of a language and region.
It’s important to know all this since the pronunciation, meaning and even the way of pronouncing a language, changes in each country and even within the localities of each country. Things to keep in mind when you start working on your applications.
Knowing that, let’s start.
First, we need to configure the languages that our actions will support. To do this, we have two ways. Through the Actions on Google console or through the Dialogflow platform.
Actions on Google Console
In the left panel of the console, you’ll have the Actions option, in the Build section, you must click on it to see the language options of your actions or add more of them.
Not only will you be able to add the language you want your application to support, also the available location that has the assistant. Such as American English or British English.
It’s important to keep this in mind as we must seek to give the best user experience when creating our applications. For example, there’re different variations of English: British, American, Canadian, Australian; each with different accents, or even the meaning of some words changes. That’s why it’s important to keep this in mind in order to offer users the best conversational experience with the assistant.
Dialogflow Platform
The same procedure we did on the Actions on Google platform, we can do from the Dialogflow platform. Click on the cross button on the left side of our project panel to enable more languages for our project.
As with the Actions on Google platform, we can not only add the language we want, also the supported localizations.
Up to this point, we’ve only defined the languages that will be supported by our application. However, we still have to customize the behavior of our actions in each language. And for this, we’re going to work in two parts:
- Customize the application on the platform
- Customize our WebHook
Customizing the application on the platform
Each language added from any platform (Actions on Google or Dialogflow), will be reflected in the other by being connected. In other words, if I add a language from the Actions on Google console, it’ll be reflected in Dialogflow and vice versa.
The added language will be displayed in the left panel of the Dialogflow platform, and if more than one has been added, the remaining language will be displayed in the three-dot button.
The best part of all this is that Dialogflow automatically creates a replica of every attempt or entity we have previously created, or continue to create thereafter, for every language we set up in our application. So we don’t have to re-create everything from scratch. However, be careful, since it creates a replica of intents or entities, but not of their internal values. We need to customize each section in order to have the answers we want in each language.
Intents
For example, here I have the same intent but in two different languages (English and Spanish).
Don’t worry about the variables you use in your intents, the name of these is also replicated in each language, just don’t try to change it in each language, because you could have problems when trying to homologate those variables in your webhook later. So remember that you should always have the same thing in all languages and their variants.
Entities
In the case of entities, the same thing happens as with intents. Each entity is replicated for each added language.
However, here we must take special care. Although the names of the entities are the same, the values change according to each language. If you have a conditional or index of an entity tied to these values in your webhook, you probably have an error, because the value will always change according to the language.
My recomendation? Always have the same name in the “references values” and only vary the “synonyms” for each case.
For now we have finished configuring our application on the Dialogflow platform. Now we have to configure our webhook to give a good experience to the user with their respective language when using our application.
Customizing our WebHook
In the case of the Dialogflow platform, we had a graphical interface that allowed us to switch between the languages we had configured in our application. But in our webhook, where do we get this data?
Getting locale
Suppose we have any attempt, for example “Welcome”, we will use our conversational instance “conv”, so we can access the User class and through it to the locale property.
The user class has many other properties (That you can see in this link), but for now, we’ll just focus on locale.
Locale will return a String with the regional language of the user configured in the Assistant, which is composed of both the language and the region we talked before. For example, ‘en-US’:
- en = English
- US = United States.
With this data we will be able to work on the type of answer we need according to the language. At first, we could work like this:
But what would have happened if, instead of an intent or language, we had three or four?. Working with only conditionals, would have been unsustainable. So to handle our application in a more scalable way, we will use a very useful library called i18n, which will help us to manage the languages within our application.
Using i18n
This module will help us with translation through dynamic storage in json. More information here.
The first thing is to import the library and configure it in our project:
In this part, we will see that i18n has many configuration options, among the most important for our actions we have the following:
- Directory: Where to store json files — defaults to ‘./locales’ relative to modules directory.
- Default Locale: You can define a default location for those that are not available in your app.
- Object Notation: Enable object notation for use templates in your json objects.
- Fallbacks: Fallbacks (Alternatives) that you can to set manually for certain languages.
i18n has many other settings that you can use, available in its documentation.
The next thing to do is to set the location to i18n, but when should we do it? The SDK handles middleware that runs just before the IntentHandler, allowing us to configure the third-party libraries we need in our application, in this case, i18n.
Let’s not forget to have our locale folder in our project with the respective files. Names should follow the Language-Region nomenclature in json format.
In this case I have two files for English (American and British) and one for Spanish in general, just as an example. Now let’s review the structure of one of these objects.
en-US.json & es.json
As you can see, for this case I have two properties: simple_hello and template_hello; both files have the same keys, because if they were different, we would have a problem trying to find the values in the objects.
They may look similar, however the first one is a simple String, while the second one is a String Template, this will allow us to pass values to our object and have a dynamic response. How?
See?, you only have to pass the values you require separated by commas, but the number of variables passed must be considered in your template.
However, to make all this work, remember to have the objectNotation parameter we saw above in true.
Hey!!!, You only have one file for Spanish, what happened with the other locations like Spain, Mexico or Peru?
Keep calm 😉, remember the Fallback parameter? This parameter allows us to have a default for the languages we define.
And that’s it. Now you have the bases for your app to support all the languages you want.
Conclusion
Remember that the main reason for all this is always to give a better user experience, not only in the characteristics of the application, but also in the experience when speaking, not something mechanized, instead of, something with a human touch.
I’ve implemented a demo of it in my github, using as a base project the Google Actions Codelabs, which you can find here. Feel free to ask me any questions you have 🙌.
