Editing language files

ReportServer is available in numerous languages, however if you like to add a new language, or improve one of the existing translations, this document outlines the necessary steps.

Let’s start by looking at some of the core concepts of how different language versions of ReportServer are implemented. The first thing you need to know is that within ReportServer every text, label or message is assigned a unique key. You can view these keys by starting ReportServer using the special “keys”-language. To select this language append the locale=keys parameter to your ReportServer URL (e.g.

ReportServer with selected keys language

This replaces all labels with their respective keys, for example the OK button on the logon screen is now no longer labeled “OK” but has a caption of “ok::net.datenwerke.gxtdto.client.locale.BaseMessages” which is the logon buttons key. The key consists of two parts: The part before the “::” is the module specific key, the second part is the name of the module. The combination of both form the canonical version of the key, which is unique throughout ReportServer, the module specific key (“ok”) on the other hand might be used in different modules.

The translations into the different languages for these keys is stored in textfiles which are included in the .jar archives for each module. So for the login OK button, in the gxt-dto.jar archive, there is a file BaseMessages.properties (in the folder net/datenwerke/gxtdto/client/locale). Actually, there is not just one file but one for each supported language, so the english version is stored in the BaseMessages_en.properties file, Portugese in BaseMessages_pt.properties and so on.
The format of the properties files is simple: each line defines one key and assignes the value for the respective language. So BaseMessages_en.properties contains

loadingMsg=Loading data
progressMsg=Please wait...

In theory that is all you need to know to edit ReportServer translations. But as you can imagine working with a huge number of text files and always moving them in and out of the archives isn’t much fun. So we created some tools that make the process much easier. The idea is that instead of having dozens of separate files we merge the translations for all modules and all languages into a single excel spreadsheet that has one key per row and shows all available translations side by side. The resulting file translation-template.xlsx is included in every ReportServer download and can be found in the resources directory.

Excel Spreadsheet to help with translating ReportServer

To test your changes you can load the excel spreadsheet into ReportServer. To do so, use this script localeimporter.groovy. Upload it to ReportServers internal Fileserver and place it into the /bin directory. Open the terminal by pressing Ctrl+Alt+T and execute the script by typing exec /fileserver/bin/localeimporter.groovy. More information on ReportServer Scripts and the Terminal are available in the Administrator’s Guide and the Script Guide available in the shop. There are also some other posts on the topic in this blog, checkout the “groovy” category.

After you executed the script, reload your browser. You should now see the updated translations.

There are some drawbacks to this method, that are important to be aware of:

  • Translations loaded with the script are not persistent. So if you restart the server the default translations are loaded. To be honest this isn’t entirely accidental – we want to encourage you to share your translations with all users of ReportServer. So if you created a new language version, or improved an existing one, send us your excel spreadsheet and we will include it into the official build. If you send us translations please include a short statement, that you provide the translation under a creative commons zero (CC0 – http://creativecommons.org/publicdomain/zero/1.0/) license.
  • There are some few labels, for which the translation does not show up when loaded with the script. It’s really just a few, but don’t be surprised, if that happens.