1. I18n and L10n in AngularJS
1. What are I18n and L10n?
Internationalization, referred to as I18n, is a standard for product development in a way that they can simply localize the product language and culture. Localization, referred to as L10n, is a standard that enables applications and texts to adapt to special cultural or language markets. For application developers, internationalizing a program means that all strings and other areas need to be extracted from the program where they are more special (such as date and currency formats). Localizing a program means providing translation and format localization of blocks extracted from I18n.
2. What levels of I18n and L10n are currently supported by angular?
Currently, angular provides I18n and L10n support for datetime, number, and currency filters.
In addition, angular supports diversified localization through ngPluralize directive (http://docs.angularjs.org/api/ng.directive:ngPluralize).
All localizable controls rely on the locale setting feature rule set managed through the $locale service.
To let readers see actual examples, the official has prepared some web page examples to show how to use angular filters to collect variables through region rules. We can find corresponding examples in Github (https://github.com/angular/angular.js/tree/master/i18n/e2e) or in i18n/e2e in the angular development package.
3. What is a regional id?
locale is a specific geographical, political, and cultural region. The most commonly used locale id consists of two parts: language code and country code. For example, en-US, en-AU, and zh-CN are all valid locale IDs, all containing language codes and country codes. Because the country encoding specified in the locale ID is optional, locale IDs such as en, zh and sk are all valid. Check out the website ICU (http://userguide.icu-project.org/locale), where there is more information about locale ID.
4. angular supported locale
angular separates the set of rules for numbers, date and time formats in different files, each file has a unique area. We can find the currently supported locale list here (https://github.com/angular/angular.js/tree/master/i18n/locale)
2. Customize locale rules in angular
There are two ways to customize locale in angular:
1. Pre-bundled rule sets
We can implement the expected locale file by connecting the locale-specific file to angular.js or angular.min.js.
For example, in *nix, we can create an angular.js file containing the German regional localization rules through the following command:
cat angular.js i18n/angular-locale_de-ge.js > angular_de-ge.js
When the application uses the angular_de-ge.js script instead of the general angular.js script, angular begins automatically pre-configured (pre-configured) localization rules in Germany.
2. Include locale js script to index.html page
We can also include js files in the specified area into the page. For example, if a client requires a German regional file, we can provide a page like the following:
<html ng-app> <head> ... <script src="angular.js"></script> <script src="i18n/angular-locale_de-ge.js"></script> ... </head> ... </html>
Both of the above methods require us to provide different index.html pages or js files in each region for localization. We also need to configure our server to provide the correct, desired locale files.
However, the second method (including locale files into the page) will be slower because one more script is required to load. (-_-!!!).
3. Trap ("Gotchas")
1. Currency Symbol Trap
angular's currency filter allows us to use the default currency symbol from the locale service, and we can also provide custom currency symbols. If our app is only used in one area, then we can rely on (set) the default currency symbol. However, if we expect that users in other regions will also use our app, we should provide our custom currency symbols to ensure that the user understands the actual value.
For example, if we want to bind the currency filter to display the account balance of RMB 1,000: {{ 1,000 | currency}}, and our application is currently using en-US locale, then "$1,000.00" will be displayed. However, if users in some other regions (such as Mainland China) visit our app, the user's browser will specify the region setting to "Mainland China", and the balance will be displayed as "￥1000.00" (a very sad error, exchange rate...).
In this example, when we need to set the filter, we need to rewrite the default currency symbol by providing currency symbols as parameters to currency filter (http://docs.angularjs.org/api/ng.filter:currency), the parameter such as: USD$. In this way, angular will ignore any changes in the locale and keep showing the balance as "USD$1000.00".
2. Translation length trap
Remember, when translating strings and event formats, the length may vary greatly. For example, "June 3, 1977" becomes "3 de junio de 1977" when translated into Spanish. Of course, there may be more extreme situations. Therefore, when we internationalize the application, we need to set up corresponding CSS rules and conduct comprehensive testing to ensure that the UI components do not collapse (variants).
3. Time zone
Remember, angular's datetime filter uses the time zone set by the browser. Therefore, the same application will display different time information according to the time zone settings of the computer running the application, rather than the time zone specified by the developer in JavaScript or angular.