Localized Content

Localized Content

In many cases you will need to deliver a content that is tailored to the end-user. This tailoring can take many forms, such as customizing the UI or allowing higher In-App store discounts, and all these can also include message in the end-user’s language. There are many options on how to achieve this in Omniata, in this guide we will present you our favorite one.

The guide assumes you are familiar with the Engager and Campaigns, you have access to create Content and Push Notification has been integrated (if applicable). It is also strictly necessary that your application is sending any means to identify a user’s language, such as Locale or Country Code.

Setting up your Localization data

The first task is to identify a deterministic way to obtain the language of the end-user. This can be using, for example, a parameter locale in your om_load event, or it can be obtained from the country code of the user. This is a application design decisition, so chose the best approach for your own application.

We will work asumming the more complex (configuration wise) case, where we identify the language from the user’s country of activity. While this may not be ideal, the configuration using a locale parameter is a subset of the configuration using country code. At this point om_load event may look like this:

Note that LCID strings are used to identify the user’s language. The preferred locale identification method may vary.

Creating the Languages table

The next step is to create language mappings. For this use a Lookup Table, this will allow one point of maintenance and an easier way to do so.

  1. Go to the Organization’s configuration (Wheel cog icon) in the top right corner of Omniata panel.

  2. Navigate to Data Sources -> Lookup Tables.

  3. Click on New Lookup Table.

The first Lookup Table will map a country to its best suitable locale. Name this table “Country Languages”, adding two columns: country_code and locale, both as string types. Once created, add some test data to it.

This table will be in charge of assigning a language according to the user’s country. We now need to be able to pick a correct text for the language in use. Next we will create a Lookup Table for this too.

Using the same steps above we now create a table called “Localization App 1”, adding the columns: text_code, en, es, fi. Each column will represent a language, and each text_code maps to a text field in the content or application.

In case a new localization is available, a new column can be added and all previous data will still remain. In case a new element is localized, a new row should be added. Alternatively, you can upload all values as a CSV file with the same structure.

Notice that we named this table as “Localization App 1”, you can create one of this tables for each app available or include all values in a single table. We chose the former to keep the localization per app.

Mapping language to Content

You can now create our first localized content. Lets assume that we want a localized Push Notification. When creating the content for the notification you can use will use the following code snippet:

<%= LK( table => 'localization_app_1', key => {text_code => 'welcome_01'}, value => LK( table => 'country_languages', key => {country_code => $user_state->{'country'} || 'US'}, value => 'locale') ) %>

This code snippet is telling Omniata: from the table localization_app_1, where the text_code equals ‘welcome_01’, take the column that equals to: from the table country_languages, where the country_code column equals to the user’s country code, the value of the locale column. In case no country is found we show as default the content attached to the US value, in this case “en” or “English”.

In case you already have the locale information, and the locale is stored in a Custom User Attribute named “Locale”, this snippet can be reduced to:

<%= LK( table => 'localization_app_1', key => {text_code => 'welcome_01'}, value => {$user_vars->{'cuf_locale'} || 'en'} ) %>

Notice that the for the second case we user $user_vars instead of $user_state. In case you want to know what can be retrieved and embedded into Engager Content check our Custom User Attributes in Content guide.

You can use a content type without a form template. The completed Push Notification content should look like this at the moment:

 "aps": {
  "alert": "<%= LK( table => 'localization_app_1', key => {text_code => 'welcome_01'}, value => LK( table => 'country_languages', key => {country_code => $user_state->{'country'} || 'US'}, value => 'locale') ) %>"

You can test how the delivered content will look like by adding the content in a Display Channel.

In the xample the user was active in Finland, and we should receive the Finnish translation of the message. Now that we know the message is correctly configured, we can publish this content in a Push Channel adding the corresponding segmentation rules and Campaign details.

What Next?

Keep your localization tables up to date! And try out different localization campaigns to check the most effective one for your app. Do not forget to check out the Push Notification Metrics package in case you are localizing notifications, or the Engagement Campaign Metrics package in case you are localizing display campaigns.

Remember to add fallback options to your mappings in case the country or language is not available in your tables too. In case neither of these is to be found Omniata will reply with an empty text, and your users may not appreciate a blank message from your app.

This article was last updated on January 25, 2016 21:09. If you didn't find your answer here, search for another article or contact our support to get in touch.