If you need to make your web application available to an international audience, then you need to understand how you can localize it with AngularJS. This example is very simple. The entry point of the web application, index.html, just allows us to select between two different localizations, English in USA (English (USA)) and Italian in Italy (Italiano (Italia)). Each one of the choices points to a specific directory with a new index.html for each localization, so we have en_us and it_it. Those index.html are the localized versions of the same page and they both use the same script.js in the root of the project.
Let's take a look at en_us/index.html. The first tag inside head is meta and specifies the charset of the page (utf-8 in this case) to let the browser know how to interpret the content of the page. Note that your files on the server side must be saved with the same charset and your web server must be configured to serve the files in that charset. In this example the files don't really use UTF-8 characters, just plain ASCII characters, but this might not be the case with other web pages and we declare in advance that we're going to serve all our files to the browser with the UTF-8 encoding. After the charset, we include AngularJS' files and we see that we have a file named angular-locale_en-us.js in the i18n directory. Try to take a look at that directory in your own AngularJS package and you'll find a lot of locale-specific files. In their name you can see both the language code and the country code, or just the language code. In angular-locale_en-us.js, the language code is en (English) and the country code is us (USA). Depending on the country, even though the spoken language is the same, there might be differences in words, conventions, symbols, etc... This is the reason why we have both language and country code. If just the language is specified, the conventions of a specific country are used without considering all the other variants. All these files represent some locale-specific constants used by AngularJS internally. For example, try to open the angular-locale_en-us.js file. You see that we have a module declared with the name ngLocale and, inside it, there are many constants like those used for the dates and also the ID of the locale. So, all you have to do to make AngularJS use your chosen locale is include in your HTML page the right script file from the i18n directory and remember to declare a dependency on the ngLocale module in your application's module (in the script.js file you see that mainModule depends on the ngLocale module).
In each of the localized index.html of our example, we output the locale ID, a localized date and a localized number. While using filters, the localization information is loaded by AngularJS from the file you've included from the i18n directory. The default is en-us if nothing specific is included in the page. When you use a specific format string for a date filter, then the localization won't have any effect, but if you use a mnemonic format string (like fullDate), then the date format will change according to the selected locale. The number filters give a sort of localization as well. Here are just a couple of examples to show the differences in the output depending on the locale. Just a small note about the it_it/index.html. You see that HTML names have been used for some characters (those with accents in this case). This is just a way to make the HTML render correctly in the browser, but since the UTF-8 charset has been declared (and not every single character has a corresponding HTML name), we could just write our page with all the characters directly, save it with the UTF-8 encoding and let the server send that page to the browser and it will render correctly anyway.
OK, now you've seen how to deal with simple localization in AngularJS, but what's the problem with this? The locale must be specified in advance during the bootstrap phase of AngularJS in your page. This simply means that the locale declaration is static and cannot be changed once the page has been loaded. You can find many different ways to let the server send the right page for the chosen locale, but you have to find your own way to switch the locale on the fly in case you need it. The next example will illustrate a possible solution.