Take it to the next step

How to go global: The internationalization of Angular apps

Lolita Rogers and Olga Nasonova
© Shutterstock /  ESB Professional

How can you expand the reach of your Angular app or site? Internationalization and localization, of course! In this article, Lolita Rogers and Olga Nasonova go over the basics of going global and share some tips and tricks on how to bring your app to the wider world.

Various up-to-date facilities and technologies are expanding the communication boundaries, covering easily any distances over oceans and mountains.

But even though these technologies exist, there is still the not insubstantial hurdle of communication. After all, users from various countries still have to read and understand the interface language. Since we’re still waiting on a Babelfish, there’s only one practical solution: developers have to work with translation.

In this article, we’re going to share our approach towards app internationalization.

A quick clarification

To begin with, let’s review some terms.

Internationalization means creating the structure that would allow supplementing the app with new languages in the future, quickly and without any problems. Internationalization is performed at the initial development stage. When you add a new language later on, you should not need to introduce any changes into the source interface code.

The long term “Internationalization”  is abbreviated as “i18n” (18 meaning the number of letters between the first and the last one (InternationalizatioN)).

SEE MORE: Microsoft Open Source jQuery Globalization/Localization Plugin

Localization is an intended adaptation of your app to the specific language. If you intend to promote your app in a new region, you will need to bring it in accordance with the linguistic, cultural and legal specific features of the region. This is what localization implies. Localization is not limited to text translation but covers changing images, time and date format, symbols, colors, currency, etc.

The abbreviation obeys the same principle as described in the example above  – “l10n” (LocalizatioN).

So, what kinds of things do developers need to keep in mind when localizing or internationalizing their apps?

Interface texts

Obviously, these need to be translated. Any app text visible to the user, such as buttons, messages, or menu items need to be translated. For this purpose, every text intended to be displayed in templates shall pass through special filters at the development stage.

i18n filter is a kind of a function. It receives  the key word from us and the target language we want to display. The filter task is to find and output the source text in the corresponding language.

Later on, in the process of the localization focused on the definite language, the phrases shall only be added, that are translated into the required language. And this requires no restructuring or changing the templates.

SEE MORE: The weight of the global economy on blockchain’s shoulders

Multilingual text

In some cases, it’s not just  the interface language that needs to be translated, but the content as well.

For exampleyou might have a post on your multilingual blog. And you need the post to be presented in these various languages (say, English, French, Japanese).

If this is your case, consider the following:

  • In what way the various content versions will be added to the administration panel?
  • Which language will be used by default, and in what way the fallback to default version is to be provided? For example, in case you fail to arrange French translation for the post in due time, think over the possibility to post in the French version of your blog the default-language post. Otherwise, the French-speaking users will have no chance to read the post as the translation simply does not exist and cannot be displayed.
  • what database structure will be used?
  • which type of content you are going to have translated? Of course, the content can be translated completely, but this will require sufficient efforts.

Language specific features

The more languages you intend to use and the more different they are as compared to each other, the more details need to be taken into account. That way, you avoid eventual issues down the line.

For example, you plan to have Arabic language support in your blog along with some European languages. In this case, you have to take care of the possibility to switch the page to the right-hand version. Why? Arabic is read from right-to-left, as opposed to European languages, which are read left-to-right. And so, switching will have some influence upon the design as well.

SEE MORE: Learn to code AI with

Language switcher

Do not forget to create the language switcher for the interface!

As users, we are all used to the option that allows us switching a great number of sites and/or apps to the selected language. Languages can be designated by various symbols (text, flags and/or other icons). The main idea here is not to make the task more complicated than it is and not to confuse the user.

For examplewe prefer the standard two-letter country codes (en/de/fr).  As a rule, they are placed in the right upper/bottom corner of the page. The user is used to find them located this way by default, and it’s not necessary to reinvent the wheel.


This is a significant thing that needs to be considered carefully. The multilingual product be considered through the lens of SEO (Search Engine Optimization).

Here’s some critical points to keep in mind:

  • locale/language indicator shall be included into URL of the page. This can be done in several possible ways:
    • as part of path|
    • as subdomain
    • as part of file
  • special meta-tags can be added to the page layout. This way, you specify the language of the page to be identified by scanning bots. This information will be used as intended by the browser and page handlers.

We have specified the key items, critical for internationalization and localization.

To get an idea of technical implementation and scope of work required, let’s follow the internationalization procedure by the example of Angular.

SEE MORE: On the road to Angular 5: Rushing to the finish line

Angular’s interface translation

Today, numerous ready-made solutions like libraries are available for typical tasks. Developers willingly share these with each other. Angular translations are not an exception.

To avoid re-inventing the wheel, we used the library: ngx-translate. We applied it in several apps, and found to be easy-to-use.

The procedure is as easy, even for beginners. The library can be found here on GitHub.

As we have already mentioned above, that the text will be displayed in the template through filters.

This means, we don’t have to write the text directly, but we use the keyword for the text and output it in the template through “translate” filter:

<div>{{ ‘HELLO’ | translate:name }}</div>


Preparing translation files

Now, we can create a translation file for every language that we want to be supported. The format we used here is json. As a result, our app will have a folder with translation files. Every file will refer to a definite language, though in large-scale apps one language may be covered with several files.

   ru .json

The files will contain all keywords used in templates.

The files are sent to be translated. The translators add variants of text in various languages therein. As a result we will have the files with the following structure and content:


  "HELLO": " Hallo",

  "HELLO": "Привет",

SEE MORE: Angular, Ember and Vue: Is choosing a framework simply a matter of taste?

Language switcher

It’s important that you don’t forget the language switcher!

We shall add it to app.component, otherwise the users will be deprived of the chance to read your amazing translation.


  clabel class="lang-switcher">
    <select #langSelect (change)="setLang(langSelect.value)">
option *ngFor="let lang of translate.getLangs()" [value]="lang" [selected]="lang === translate.currentLang">{{ lang }}


The above is valid for any simple application. But sometimes the practice may give us some unpleasant surprises.

Any language is like a living organism with its own specific features and traditions. A number of factors are to be taken into account in any Angular app when you are internationalizaing and localizing:

Length of line

The same sentence in different languages will be of different length. Certainly, the sentences can be subdivided into small phrases. But in some languages this division may lead to sense distortion. Moreover, the page layout may shift.

For example, the German language is distinguished through its fixed word order, and translation of the divided parts of the sentence may result in differing and/or unclear message.

Punctuation marks

¿Quieres continuar?

In Spanish the exclamation and interrogation marks shall be put in the beginning and the end of the sentence. And they are inverted as well!


Dates and times are an important format to keep straight. However, September 21, 2017 will look different in different countries:

  • 09-21-2017 – USA
  • 21/09/2017 – Great Britain
  • 2017-09-21 – Canada
  • 21.09.2017 – Germany

The list can be continued with:

  • weights and measures
  • currency
  • telephone numbers
  • and more!

The exact items will always depend on the specific features of your project under development.

SEE MORE: Open source your education: the best online courses for ML, AI and more

In conclusion

The main idea is to realize, that such a global task as internationalization does not accept negligent attitude to details. Any details that have been ignored may lead to the situation, when the users will simply misunderstand the message you are trying to communicate.

The range of eventual errors is really broad: starting from immediate translation errors to misused units of measurement or mess about the time and date format.

But we are not going to end our article in a pessimistic way. That is against our principles!

After all, the internet offers a number of Angular apps and sites that are multilingual. Look at iStockphotoMicrosoft, and Freelancer!

This means that neither internationalization nor localization of Angular apps presents an impossible task. They are just things to be approached with accuracy and care.


Do you have any unimplemented ideas? Do you want to clear up any details? Contact Umbrella right now, and together we will turn any of your projects into reality!



Lolita Rogers and Olga Nasonova

Lolita Rogers is a web developer and UI/UX designer. Producing at the crossroads of minimalism and sustainability to answer design problems with honest solutions.


Olga Nasonova is a marketing and development leading expert. Having been working in Umbrella-web for several years she became an Agile certified sales strategist. She enjoys learning new and useful information about IT and also loves to share it.

Inline Feedbacks
View all comments