Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: order languages by alphabet

How to view Jenkins in your language.


Table of Contents

Translations to Specific languages

What developers need to know/do

HudsonJenkins' s i18n support has two some aspects that developers need to be aware of.

  1. Generation of type-safe Messages classes from
  2. Marking messages in jelly files.
  3. Creation of html files for help tips.

Generation of Messages classes

Hudson Jenkins uses localizer to generate classes for accessing message resources in a type-safe way. For each src/main/resources/**/, a Messages class is generated. See the referenced page for how this class looks like. If your IDE fails to find these classes, manually add "target/generated-sources/localizer" directory to your source root.


  1. You identify messages that need be localized
  2. You place that in One can choose to have this file for each package, or you could just have one such file for the whole module/plugin.
  3. You run mvn compile once to re-generate
  4. Update your code to use the newly generated message formatting method


    As usual, looking at how the core code does this might help you get the idea of how to do this.


    Note: If your message contains single quote character ('), then you need to escape it with another single quote character (i.e. ''). So "that's" becomes "that''s". If you're in need of an apostrophe character you might consider using ’ - the unicode character U+2019, written in properties file as \u2019.

Marking messages in jelly files


In the simplest case, suppose you have a part of a Jelly file that looks like the following:

No Format


Then all you need to do is to change this to the following:

No Format



Let's consider the case where the localization requires parameters. Suppose you have a Jelly file foo.jelly like this:

No Format

<p>Click <a href="${obj.someMethod(a,b,c)}" >here</a></p>

In this case, first you have to write for the default locale:

No Format <a href="{0}" >here</a>

Then update foo.jelly to refer to this like this:

No Format


If you have multiple parameters you can pass them by separating ',' (just like a function call), and from property files you can reference them as {0}, {1}, etc., by following the MessageFormat class convention.

Finally, let's Now consider the case where you put a message in an expression like this. Suppose you have a Jelly file like this:

No Format

<p>${h.ifThenElse(x,"no error","error")}</p>

You can mark those two strings for localization like this:

No Format

<p>${h.ifThenElse(x,"%no error","%error")}</p>

Finally, because you can use expressions in Jelly, you need to ensure your regular strings don't contain brackets.
For example, this will not parse correctly, as it will be parsed as an expression:

No Format
<h1>${%Path to file (.ipa or .apk)}</h1>

You need to create two separate strings in this case:

No Format
<h1>${%Path to file} (${%.ipa or .apk})</h1>

Creation of html files for help tips.

It is possible in jelly files to configure entries which can show a tip message when the user clicks on a help icon.

No Format
<f:entry title="${%title}" help="/plugin/myPlugin/help.html">

Then, just create the file help.html for English or help_xx.html for the 'xx' language.

What translators need to know/do

The Hudson Jenkins project always welcomes contributions to translations. If you are interested in helping us, please drop us a note at, so that we can give you the commit access. In the reminder just file a pull request on GitHub. In the remainder of this section, we'll discuss what needs to be translated and how.

ISO 8859-1
ISO 8859-1

Remember that properties files must be encoded in ISO 8859-1. This should be the default anyway.

Translation tools



Sometimes looking at alone doesn't give you enough contextual information as to where the messages are used. For this, developers are encouraged to access messages by using the type-safe Messages class generated by localizer. To find out where messages are actually used, use your IDE to find all the usages of the message format method.


The other messages that need to be translated are in Jelly view files, which are in src/main/resources/**.jelly. To localize them, first you run Maven to generate skeleton property file for your locale:

No Format

$ cd hudsonjenkins/main/core  (or hudson/plugins/xyza plugin dir)
$ mvn stapler:i18n -Dlocale=fr


Stand-alone HTML files are often used in Hudson Jenkins for things like inline help messages. These resources need to be translated by adding the locale code between the file name and the extension. For example, the Japanese version of abc.html would be abc._ja.html, and British version of it could be abc._en_GB.html. These files need to be encoded in UTF-8.


When starting a translation, try to check if there's anyone else working on the same locale. You can find out who they are by finding existing localization and looking at its CVS history. Try to get in touch with them to avoid a surprise.


Refactoring the existing code to handle i18n correctly is tedious. So Stapler IntelliJ IDEA plugin for IntelliJ IDEAStapler is developed to simplify this (note that JetBrains kindly offered the open-source license for the Hudson Jenkins project, so contributers can get the license for free — contact Kohsuke if you need one.)

Once installed, this adds a menu item in the main menu, under "Refactor." It is highly recommended to give some keyboard short cut to this. I use "Ctrl+Alt+I":

Now, to use this feature, select the message you'd like to internationalize, then trigger this refactoring command. It'll ask you the message property name for this, so pick a name:

IDEA will place the message into the resource file, and adjust the code accordingly. Note that an error is highlighted until you run mvn compile again to generate new methods on the Messages class.

Stapler plugin for NetBeans

See NetBeans plugin for Stapler for details.

Translation Completeness Reports

Visit for Glottr Report by Unknown User (swiest)