What is localization


Often websites and applications are created for people who speak different languages. Therefore, applications must correctly display the interface in the language selected by the user.

Amway multilanguage        Amway multilanguage

How to create a multi-language website or application

In static websites, it is possible to create a separate subtree (folder) for each language, copy and paste whole pages of structure from the base language, and next, replace original text with its translation. A disadvantage of this method is the need to make further changes or bugfixes in each version separately.


In dynamic “rich” websites and desktop or smartphone applications, the situation is more complicated. The Model–View–Controller (MVC) pattern implies a separation of the “view” and the business code; localization applies only to the “view” layer. The view layer is implemented with template utils (e.g., JSP, PHP smarty, etc.) or with patterns provided by the IDE. The “copy-paste” method used for simple sites is definitely wrong or even impossible to carry out in MVC.

Data format for Translator

Another problem is the question of how to deliver content to translate to the person responsible for translating it. Translators are generally not programmers or webmasters so they cannot easily use HTML or any programming language.

Text content for the Translator should be delivered in a simple format; a csv or Excel file is most commonly used.

Unfortunately, the process of extracting text from a template or application code and placing it in an Excel file and then putting back the translated content is very boring and error prone.


The most popular solution is to externalize texts from the content template or application code into separate localization files and use links to them. Each place where localized text will be displayed has its own unique key. Localization files contain translations assigned to each key.  Localization files are grouped in sets related to each language and sets related to application parts.

Next, simple application code retrieves translation from the files for a given key in the currently displayed language version and places it into a template or application element.


Localization files have a simple format, usually as formatted text or xml. They can be delivered directly to a Translator or converted to an Excel file.


User interface elements to be localized

Most user interface consists of two types of localized elements:

  1. Fixed text - unchanged at runtime, such as headers, buttons, labels, links, etc.
  2. Content managed by users at runtime, such as CMS content pages, name and descriptions of product, etc.

Only fixed text elements may be localized; content managed by users at runtime is application-specific and is not supported by our platform.


Localization process during development

We assume that the developed application already contains localization files.

Development phase

In the development phase, Developers create application code with references to keys that put in localization files with the base language version, such as English. The application works with the base language. However, when the Tester changes the current language to another one, then one of these possibilities occurs, depending on the implementation:

  • An application error should be thrown because there is no localization for current language – it is a “hard” method, but it guarantees that after completion of functional tests, all texts are translated,
  • Instead of text in the selected language, text in the base language version will be shown. This is a “soft” method that is comfortable to test, but it doesn't guarantee that after completion of functional tests, all texts are translated,
  • Instead of text in a selected language, only keys will be shown;  it is “soft” method, as above.

When the application development is completed or at the end of development phase, then all localization files are collected and sent to the Translator(s).

Translation phase

Next, the Translators start their job to translate the files’ content. The issue is that most of them do not know the context in which the texts are used. Often the application is not in production and they cannot even see the screen in which the text should be displayed. So they may use only technical specification of the application, key names, base localization, and their intuition. They may generate many questions for the Developers about the context of using each key.

When the Translators complete their jobs, they return the translated files to the Developers.

Tests phase

A Developer puts files into the application code and delivers a working application to acceptance test. The Translator or another person who knows a given language and behavior of the application starts testing the scenarios and ensures that the texts are correctly translated on each screen. The issue is that if he/she found a bug and wanted to make a change, there is no simple way to determine what key in which file should be changed. If the translated text is unique, it is possible to find it in localization text by a simple search. When the text is not unique, the Translator must describe the location of the text and what to change; the Developer must identify which key should be changed. Both methods are cumbersome and tiring.


Limitations and known issues with other localization approaches

  • Translation without context – It is a problem with other approaches that Translators work with text, but the actual location of the text in the website is not visible. Our solution provides the much needed context to ensure accurate translation.
  • No information about the key that is used – You may have struggled with trying to find a  simple way to find the name of the key for text visible on the application screen and to locate it in localization files. That is not the case with our solution. E-point’s localization is simple, easy to use, and gives you all the information you need about the key that is used.
  • Conflicts – When files are translated by Translators, simultaneous modification by programmers should be prohibited. Our solution ensures that during heavy development activity, programmers are not able to keep adding new keys, or even worse, modifying previously added ones.
  • No validation – Perhaps you have seen translated text contained in an Excel file or directly at the source that is not validated. The Translator is able to delete text, remove required parameters, add forbidden characters, etc. Our solution provides that important validation.
  • Process management – Someone must gather information about new keys, notify Translators, and collect and verify the results of their work. For more languages and frequent iterations, it can be a time-consuming task. Our e-point localization solution provides built-in process management.
  • Distributed responsibility – Without an additional tool to control workflow, any information about who added a new key and who translated or changed it is stored in the code repository (as normal application code) and in mailboxes of Managers to collect the Translator's work results. In this situation, tracing a long history of changes of the key is very difficult. Our solution is designed for complete distributed responsibility.

If you are new to localization or have experienced any of these issues, read more about our solution.