Why Automated Tools are the Key to Managing Translation Resources - For the Example angular-translate

Introduction

Today's business applications often get deployed to a broad variety of different users in different parts around the world. Relying on target users speaking solid English and being familiar with US styles and formatting gets more and more outdated. To adapt the programs' appearance to end users' native languages and cultures is no longer a nice-to-have feature, but a very mandatory requirement. This process, usually known as internationalization / i18n and localization / l10n, became an elementary component in developing state of the art business applications.

I18n/l10n for Visible Texts

Besides some other aspects, i18n/l10n implies translating all visible texts in the application to users' languages.

For UI developers, these requirements go far beyond implementing the pure translation mechanics. In the long run, this implies particularly one thing: Handling a huge amount of translation data: Translation IDs in the view layouts, translation resources for every supported language, export files going to a translator office, import files returning back and so on. All these data sets are subject to change and someone has to keep them consistent over the development process. So on the day of shipping, the language resource for all cultures are complete and ready.

Repetitive Work Equals Automated Tools

Extracting translation IDs from layout files and comparing them with already existing resources is highly repetitive work. There is a large amount of keys to be handled in one application and it has to be dealt with at least once, but more likely several times, during every release turn. So to work as efficiently as possible, we must base our work flow on as highly automated tools as possible.

Tools

For applications in AngularJS, angular-translate by Pascal Precht [^] currently is the number 1 module to provide localized texts in the application.

grunt-angular-translate

To extract translation IDs from the application's source code, grunt-angular-translate [^], a.k.a. i18nextract, is a handy tool. Instead of browsing all files manually or creating a custom reg-ex parser, this plug in provides a grunt task called i18nextract, which browses the angular source files (usually JS and HTML) and filters for angular-translate-specific translation IDs. The most commonly used patterns are:

• Filters: {{'TRANSLATION_ID'| translate}}
• Directives: <any translate>TRANSLATION_ID</any>
• Service calls: $translate('TRANSLATION_ID')

For more details and examples, take a look at the docs [^].

Version Control for Language Resources

Automating the export of translation IDs from your source code avoids a lot of repetitive work and therefore is great. But imagine, you see this summary report:

$ grunt 
Running "i18nextract:default_options" (i18nextract) task
Process en_US : l10n/en_US.json 

Statistics : empty: 2 / Updated: 150 / Deleted: 17 / New: 42 

OK, what happened to those deleted entries? Did someone change the code and they are not longer needed? Or did someone move code files and the grunt task doesn't parse them anymore? Yet, you cannot log deleted entries with i18nextract. safeMode avoids deleting existing entries in your language resources. But this way, you will never get rid of old, unused translation IDs.

Luckily, we have all source code files in our version control of choice. If not, take a break from reading this article and do so. When talking about Language resources, we talk about plain text files that get deployed with your program. So they should be in the same repository on your version control.

After running the script and reading Deleted: 17 entries, you can easily figure out what happened. When diffing your working copy of the language resource files with the original version, you can select exactly the changes you want to save.

Using the Code

There is a small example in the appendix. It uses grunt-angular-translate to automatically extract translation IDs from a small HTML project. After extracting the project folder, do the following:

1. npm install
2. grunt

Then, you should find an updated translation table in l10n/en_US.json (see image). Feel welcome to take a close look, how already existing entries and new IDs are handled.

Conclusion

Knowing the right tools around the pure i18n module and automating typical tasks in the work flow can save a lot of time and energy. This especially applies during release turns.

History

• 18^th February, 2016: Initial version