sonar-l10n-zh: matching the Chinese translation pack to your SonarQube version

A translation pack, not a fork of SonarQube

This repository is the Chinese translation pack for SonarQube. It does not change what SonarQube analyses, which rules it runs or what your dashboards contain; it changes the language of the interface that sits on top of all of that. The author is credited in the README as Xu Huisheng, and the project is listed with Java as its primary language, which fits what it actually is: a resource bundle package rather than an application.

That distinction matters for anyone weighing it. A translation pack is small, is coupled tightly to a specific SonarQube release, and carries almost no logic of its own. If your team works in Chinese, the argument for installing one is straightforward: the issue list, the rule descriptions and the project administration screens are read far more often than they are configured, and reading them in a second language slows down exactly the loop where a developer needs to act quickly on a finding.

The repository is not archived and the last push was on 2026-10-20, so this is a pack that is still being produced. The repository's default branch is master rather than main, which is a small signal of its age and of the community it comes from.

Reading the compatibility matrix

The README is built around a table, and the table is the documentation. Each row starts with the SonarQube version and the columns carry the version of sonar-l10n-zh that supports them. The current lines run from SonarQube 26.1 through 26.10, from 25.1 through 25.12, and include 24.12 on its own row. Older SonarQube lines are listed further down: 10.0 through 10.7, 9.0 through 9.9, 8.0 through 8.9, 7.0 through 7.9, 6.0 through 6.7, 5.4 through 5.6, 4.0 through 4.1 and 3.1 through 3.7.

The mechanic underneath is that the pack version tracks the SonarQube minor version, and you install the one that matches. That is straightforward for recent lines and worth double-checking for the oldest ones, because the numbering does not line up there. For SonarQube 7.0 through 7.9 the pack versions are 1.20 through 1.29. For 6.0 through 6.7 they are 1.12 through 1.19. For 5.4 through 5.6 they are 1.9 through 1.11, for 4.0 and 4.1 they are 1.7 and 1.8, and for 3.1 through 3.7 they run from 1.0 to 1.6.

So a reader on an old line cannot assume the pack version equals the SonarQube version, and a script that resolves the artifact by matching the two numbers will break for SonarQube 7.9 and earlier. One further wrinkle appears in the 10.x line, where SonarQube 10.4 pairs with pack version 10.4.1 rather than 10.4. Read the row, do not compute it.

Release cadence tied to SonarQube releases

The tag names make the shipping pattern visible, because each one carries the SonarQube version it targets. Recent releases are named sonar-l10n-zh-plugin-26.10, sonar-l10n-zh-plugin-26.9 and sonar-l10n-zh-plugin-26.8, and their dates line up with the SonarQube release calendar rather than with a fixed interval.

The 26.8 pack was published on 2026-08-12, the 26.9 pack on 2026-09-07 and the 26.10 pack on 2026-10-20, with the repository's last push on the same day as that final tag. In other words, the pack appears within days of each SonarQube release rather than lagging a quarter behind it. For a team that upgrades SonarQube on a schedule, the practical consequence is that a Chinese pack for the new version will normally exist by the time the upgrade lands, and the risk is not a missing translation so much as upgrading before you notice that one has been published.

There is one wrinkle in where to look for the downloads. The README's 'Latest version' link points at the releases page of the SonarQubeCommunity organisation repository rather than at this repository's own releases, while the tags in this repository are named sonar-l10n-zh-plugin followed by the version. Two places, one artifact, and enough naming difference between them to send a first-time installer looking in the wrong spot.

The Maven project behind the translations

Based on the repository layout, the pack is a Java project built with Maven. There is a pom.xml at the root and a src directory holding the sources, which for a translation package would carry the resource bundles that carry the Chinese strings for each SonarQube screen and rule message.

Two other directories and files are worth a look. A compare directory at the root sits alongside src, which suggests the project keeps some form of comparison between translation versions, useful when a new SonarQube release adds or renames screens and you want to see what changed since the previous pack. The build also uses .sonarsource.properties, the properties file SonarSource tooling reads, and the repository has both a .travis.yml and a .github directory together with a trigger-github-action.txt file, which indicates the releases are produced by automated runs rather than by hand-assembled artifacts.

The plugin identity for SonarQube comes from the properties file, and the fact that the project is a plugin rather than a plain archive of strings is what makes version pairing work the way the matrix describes. The README itself is thin on this side: it explains compatibility and points to the releases, but it does not walk through the build, the manifest or the contents of the package.

Where the pack stops being useful

The first limitation is simply the matrix. If your SonarQube version does not appear in it, the README documents no pack for it. The table also ends at SonarQube 26.10, so a newer release line may not yet have a published pack even though the project as a whole is active.

The second is scope. This is a translation of the SonarQube interface. The README describes the project as the Chinese pack for SonarQube and does not mention any effort to translate strings contributed by third-party plugins, and since a plugin carries its own resources, text coming from community plugins is outside what this pack controls. If your team runs a heavy set of community plugins, expect a mixed-language interface even with this pack installed.

The alternative approach is to run SonarQube in English and rely on the fact that rule identifiers, severity levels and issue types are untranslated anyway. That costs the team nothing in capability and avoids any coupling to a release train, but it does mean every developer reads the long-form rule explanations in a second language. The decision is less about the pack's quality than about how much prose your team reads inside the tool.

Licence and redistribution

The licence position here is the one genuinely unresolved item. The repository records no standard open source licence, and the root of the project contains no LICENSE file among the files listed at the top level, only .editorconfig, .sonarsource.properties, .travis.yml, README.md, the pom.xml, the src and compare directories and a few automation files.

That is not a technical obstacle to installing the pack, but it is a real obstacle to redistribution and to anything else that goes beyond using it on your own SonarQube instance. Copying the artifact into an internal artefact repository, bundling it with a deployment pipeline, or shipping it to a customer are all acts of redistribution whose terms depend on a licence the repository does not state in a recognised form. The author and the SonarQubeCommunity organisation are the parties to resolve that, and this description is not legal advice.

The version matrix and the monthly release habit suggest the project intends to keep publishing. The absence of a stated licence is the one gap worth raising with upstream before you build a delivery process on top of it.

Editorial conclusion

Adopt sonar-l10n-zh if your team reads SonarQube in Chinese and you can pin your SonarQube to a minor version that appears in the compatibility matrix, because the pack is versioned per release and will not travel across minors. Do not adopt it for an unlisted SonarQube version, and read the repository's own licensing position before redistributing the artifact, since the project records no standard open source licence. Check first that the pack version you download matches your SonarQube minor version exactly, and that the release tag you pick, named sonar-l10n-zh-plugin followed by the SonarQube version, is the one published for your line.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. xuhuisheng/sonar-l10n-zh on GitHub