I’ve requested changes to the PR. Other than that it looks good except that I would like to see a small change to the plugin description before I add the plugin to the marketplace.
After a little internal investigation, we’ve learned this:
The backend API is designed to support the official bcp47 standard : https://tools.ietf.org/html/bcp47. The internal representation is the Java class Locale, which is compliant with this standard. We then look for a translation file matching the locale.
But tests show that the API can only find the (Language,Culture) part. The region is ignored. Looks like a bug.
The plugin proposed is working because it provides both
core_zh_tw.properties files. They are identical, and the
zh_tw file is ignored.
So first the “Looks like a bug” part: I sense no enthusiasm on our side to pursue this. So let’s not hold our collective breath.
Next I asked myself if this was a breaking / blocker bug. What happens if I have both l10n-zh plugins installed? I found that the server loaded fine and web pages were rendered as expected. So then I turned on localization in my browser. I got this:
You guys will have to tell me which version I’m looking at.
So! Since there’s no apparent conflict (probably just first-loaded-wins) between this new plugin and the extant one, I don’t see a barrier to Marketplace entry. However, since this comes down to the user being careful about which l10n plugin she chooses, I request @Tim that you update your plugin description to reflect that it is not compatible with the “Chinese Pack” (that’s the description that shows up in the Marketplace), re-release, and update your PR accordingly. Feel free to expand on the incompatibility in your documentation. Or not. @xuhuisheng, whether or not you want to add a note about not being compatible with your plugin is up to you, since you got here first.
And thanks to both of you for your continued efforts to bring SonarQube to a wider audience!