Implement Globalization Using AngularJS

What is Globalization

The term “Globalization” also abbreviated as g11n where 11 is number of characters between ‘g’ and ‘n’ and is a combination of two terms - internationalization & localization.

  • Internationalization (i18n) - It’s a process of designing a software application so that it can adapt to various languages and regions and responses accordingly.

  • Localization (l10n) – It is a process of adapting internationalized software for a specific region or language by adding locale-specific components. It actually converts the application into locale formats.

So it can be said that localization uses the infrastructure provided by internationalization and add locale-specific components to the application and hence localize the application.

What is a locale ID?

Essentially this is an ID given to various locales that are available. The locale ID consists of the following two parts:

  • Language code
  • Country code

    en us

Here, en stands for English and US stands for United States. As we know, English is different in US and it’s different in UK and it’s even different in various other countries. So the combination of language & country makes it a unique combination. These are all valid locales for English language:

English language

How does Angular support i18n/l10n?

Angular supports i18n/l10n for date, number and currency filters. It separates number and date time format rule sets into different files, each file for a particular locale. So we have one file for each locale. Below you can see the list of files. You get these files when you install AngularJS in your application. Also, note the locale id appended at the end of each file name.

end of each file name

Angular also provides $locale service that can be used in code. It provides all the information like date formats & currency symbol. This can be quite useful to implement the custom requirements.

custom requirements

Implementation

Locale can be identified from two different places. It can be read from browser or from machine settings. Browser locale is used to display the content of the website. Machine locale is used to apply formatting on documents like excel that are downloaded on client side.

To make this work, we need to:

  • Detect the client’s locale id
  • Set the application to pick that locale

To summarize the steps, I will be reading the locale from the header of the request that’s coming to the server. Then I will put it into view data to make it available on page. Next, I will be rendering the path of the file that I need to download. And then I just need to add that file to the page. When the application containing specific file instead of the generic angular.js script is downloaded on client side, it will automatically pre-configure with localization rules for that locale all over. After this, I just need to make sure that each field column has a correct data type in order to get formatting.

The detailed steps goes as follows:
  1. Detect browser language

    One can detect browser locale on client side only and request the server for that specific file. But due to diversity in browsers it’s always recommended to read language accepted by browser from the request coming to the server. So the server side code goes like this:
    1. ViewData["currentLocale"] = Request.UserLanguages[0];  
    This is how it will look in debugger:

    debugger

    This gives us the priority wise list of the locales accepted by the browser. We need to pick up only the top most priority locale and download corresponding file to the client’s machine. If the language of the browser is changed, on refreshing, the new locale file will be downloaded and formats will be changed accordingly.

    Make sure to put this code in a file that gets executed every time the application runs. Ideal file will be home controller.

  2. Rendering the path
    1. <label id="lblLocaleFilePath" hidden>  
    2. @Url.Content("~/Scripts/3rdParty/i18n/angular-locale_" + @ViewData["currentLocale"] + ".js")</label>  
    There may be other ways, but I chose to keep a hidden label on master page and keep the rendered path in this label so that it is accessible to all pages. So fetch the local id from view data and append it to the file name. Now the label will contain the path of the local specific file required from the server.

  3. Download locale file to client
    1. <script type="text/javascript">document.write("<script src=" + $("#lblLocaleFilePath").text() + "><\/script>");  
    2. </script>  
    Here value of label should be – ~/Scripts/3rdParty/i18n/angular-locale_en-US.js

    Again, I have added this code to my master file. We can check in developer’s tool that local specific file is downloaded to the client side.

  4. Specify data types of the column/field

    The columns or fields that needs to get formatting should have proper data type defined. If we want a column to take number formatting then its data type should be defined as number. The following is a sample of a column from ui-grid:
    1. {name: Calculated value', displayName: Calculated value ', field: ‘CalculatedValue ', minWidth: 60, enableCellEdit: false, cellClass: 'right', cellFilter: 'number:2'}  
    Notice the cell filter where I have defined the data type to be number of up to two decimal places.

    That’s all we need to do in order to apply local formatting to read only fields. Notice that we don’t need to call any formatting or un-formatting functions separately.

Sample

The following shows the formatting as per en-US locale:

formatting as per en US locale

Notice the group separator, decimal separator, currency symbol and date formatting.

Now let’s change the language accepted by the browser. For Internet Explorer, go to Internet options, then Languages. Move French (France) [fr-FR] to the top in the list. On refreshing the browser, formatting change as in the following table:

formatting change

Notice the changed group separator, decimal separator, currency symbol and date formatting as per new locale.

Closing thoughts

Angular provides a generic solution to implement globalization. As you can see we need to write minimal code to turn the application to support diverse locales. No 3rd party file/support is required for basic formatting. Formatting editable fields require some extra steps for un-formatting the values, that I’ll cover in my next topic. That’s it for now. Hope this helps.