This version of the SonarQube documentation is no longer maintained. It relates to a version of SonarQube that is not active.

See latest version
Start Free
10.0 | Extension Guide | Internationalization

Internationalization

On this page

This page gives guidelines to i18n for:

  • Plugin developers who would like to apply the i18n mechanism in their own plugins, so that these plugins can be available in several languages.
  • People who would like to help the community by making the platform available in a new language.

Principles

Although the basics of the i18n mechanism are the same for every part of the ecosystem, the packaging differs depending on what you are developing:

  • Translations for SonarQube: making SonarQube available in a new language requires you to develop and publish a new language pack plugin.
    • By default, SonarQube embeds the English pack.
    • All other language pack plugins, like the French pack plugin, are maintained by the community and are available through the Marketplace (category "Localization").
  • Translations for the SonarQube community plugins: open-source plugins from the SonarQube community must embed only the bundles for the default locale (en). Translations will be done in the language pack plugins.
  • Translations for other plugins: closed-source/commercial/independent plugins must embed the bundles for the default locale and the translations for every language they want to support.
  • After installing a language, users must change their browser language to see the changes reflected in their plugins.

Translation bundles

Localized messages are stored in properties files:

  • These are regular properties files with key/value pairs where you put most translations
  • These files must be stored in the org.sonar.l10n package (usually in the src/main/resources/org/sonar/l10n directory)
  • The names of these files must follow the convention <key of the plugin to translate>_<language>.properties, for example widgetlabs_fr.properties or core_fr.properties for the core bundle. See sonar-packaging-maven-plugin for details on plugin key derivation.
  • Messages can accept arguments. Such entries would look like:
    • myplugin.foo=This is a message with 2 params: the first "{0}" and the second "{1}".
  • Messages can accept pluralization. Such entries would look like:
    • myplugin.foo={x, number} {x, plural, one {thing} other {things}}
    • We use it for example with a combination of 2 labels: component_navigation.last_analysis_had_warnings=Last analysis had {warnings} and component_navigation.x_warnings={warningsCount, number} {warningsCount, plural, one {warning} other {warnings}}. This renders Last analysis had 1 warning if warningsCount equals 1 and Last analysis had 2 warnings otherwise, in this case 2.
    • Learn more about this syntax here.

How to read localized messages from a plugin extension?

The component org.sonar.api.i18n.I18n is available for web server extensions. Scanner extensions cannot load bundles.

Writing a language pack

A language pack defines bundles for SonarQube and/or plugins.

Creating a language pack

The easiest way to create a new pack is to copy the Chinese pack and adapt it to your language.

Maintaining a language pack

In the pom file, set the versions of SonarQube and of the plugins you want to translate. When it's time to update your language pack for a new version of SonarQube or a plugin, the easiest way to see what keys are missing is to run:

mvn test

If the build fails, it means that some keys are missing. Go to target/l10n to check the reports for each bundle. Missing keys are listed under Missing translations are:

Missing translations are:
code_viewer.no_info_displayed_due_to_security=Due to security settings, no information can be displayed.
comparison.version.latest=LATEST
...

Each time you add a new bundle or update an existing one, please create a JIRA ticket on the corresponding l10n component in order to track changes.

Localizing a plugin

This section applies if you are developing a closed-source plugin. If your plugin falls in this category, it must embed its own bundles. Bundles must be defined in src/main/resources/org/sonar/l10n/<plugin key>_<language>.properties

The default bundle is mandatory and must be in English. For example, the plugin with the key mysonarplugin must define the following files in order to enable the French translation:

  • org/sonar/l10n/mysonarplugin.properties
  • org/sonar/l10n/mysonarplugin_fr.properties

Was this page helpful?

© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARLINT, SONARQUBE, SONARCLOUD, and CLEAN AS YOU CODE are trademarks of SonarSource SA.

Creative Commons License