Would Like to Contribute Internationalization Rule Sets

Dear SonarQube community,

I’m Craig Cummings with VMware. My internationalization team and I have developed a set of rules to help find internationalization issues in source code. We have boiled our rules down to a small, but key set rules aimed at finding the most important or worst bug-producing internationalization issues – from P0/P1 encoding issues to locales, formatting, sorting, and more.

We presented our static code analysis work at the 42nd Internationalization and Unicode Conference and you can check out our slides here:

http://unicodeconference.org/presentations-42/S7T1-Cummings-Fang-Yan-Yang.pdf

This includes snippets of compliant/non-compliant code, but I’m happy to provide more details on each rule.

We’d love to open source these internationalization rules starting with our Java rule set. Note that we have JavaScript/TypeScript as well as Python rule sets, too, but let’s start with Java.

Please let us know the next steps towards contributing these internationalization rule sets.

Thank you,

Craig

Dear @i18ncraig ,

Thank you for this great contribution to the community.

As you already have an implementation of those rules and they form a coherent set focused on i18n, you can just open source the project and send us a request on this forum to add the plugin to SonarQube’s marketplace. This documentation describes how to create a plugin and the requirements for having the plugin added to the Marketplace.

Don’t hesitate to ask us for any additional information.

Cheers,
Nicolas

Dear @i18ncraig,

Is the solution I suggested acceptable for you?

If you prefer to contribute those rules directly to SonarJava we can go over the list of rules you would like to add. This is a case by case process where we evaluate the number of false positives each rule would raise and how we can improve the rule to make it valuable for every developer.

In the slides you provided I see only one example of non-compliant code.
It would help us if you could provide for each rule:

  • a description of the rule
  • a non compliant code example
  • a compliant code example showing the fixed code (if applicable).

If there are many rules I suggest to create one post per rule in this section of the forum. You can ping me in each post by writing @Nicolas_Harraudeau.

Here is an example of such post.

We are currently fully focused on the next SonarQube LTS version. As I don’t want to keep you waiting a long time for an answer, I suggest to start this process after the LTS release, i.e. in June.

Let me know if this solution or the previous one is ok for you.

Cheers,
Nicolas

Nicolas,

The process for creating a new plugin from scratch appears a rather daunting task.

We have an existing plugin that is based on https://github.com/SonarSource/sonar-java that has the i18n Java rules incorporated. Will that work?

There are about 20 rules and I’d prefer not to add each post by post. Then again, feedback on each could be valuable. I’ll work on at least an uber doc that has descriptions and examples for each (we were already considering a user’s guide, if you will).

Lastly, we’d really like to get the rules incorporated sooner than later. We have consumers biting at the bit for these as we speak. Please let us know what can we do before June?

Thanks,

Craig

Dear Craig,

Sonar-Java provides a custom rules API which makes the creation of custom plugins a lot easier. You can take a look at this example to see how little code this requires. Modifying a clone of sonar-java is not recommended as it will most probably conflict with the official sonar-java plugin. It will also make your maintenance work more difficult as you will have to follow every modification we do on the main repository.
Once the plugin follows the Marketplace requirements we can add it there.

If you prefer to integrate your rules in the official SonarJava repository instead, provinding all the information in one file is ok too. Once we have reviewed the rules descriptions and accepted them, you will be able to send us one pull request per rule on the Sonar-Java repository. Splitting your contributions in multiple pull requests is necessary to help our engineers review the code.

Cheers,
Nicolas

Nicolas,

Thanks again for the pointers. We just about have the Java custom API rules ready. I still need to work on the doc with compliant/non-compliant examples.

In the meantime, devs on my team are eager to prepare custom API rules for Python and TypeScript. I found the link to JavaScript custom API rule, but not for Python or TypeScript. Could you please point me in the right direction for the latter two?

Thanks,
Craig

2 Likes

Nicolas,

My team and I will have the Java custom rules for internationalization done tomorrow or Friday. They include even the longer descriptions and noncompliant/compliant examples (in HTML files). The Marketplace information you pointed me to seemed to apply more to plugins. Should we put these custom rules in the same place for you and SonarQube team to start reviewing or what means would be best way to get you the custom rules?

I have some more details I’d like to share with you more directly. Please drop me a line at my email or let me know how I may contact you.

Thanks,
Craig

1 Like

Hi Craig,

These are really great news!
Excuse-me for the late reply. To speed up the discussion I’ll send you my email address privately. We can also schedule a meeting.

If you want to contribute the rules directly to SonarJava and not maintain them there is no need to worry about the marketplace. I suggested it in case you wanted to have full control over your internationalization rules set.

The best way to contribute your rules to SonarJava is to create one pull request per rule on the Sonar-Java repository. If you already have all the rules in one repository you can also share it and I will take a look at the rules’ descriptions. You can later create the pull requests.

Regarding Typescript and Python, we don’t have any API for custom rules. You can contribute the rules by directly sending pull requests to SonarTS and SonarPython. The git history shows how we proceed. We usually create one commit for each new rule (ex: python, typescript). Let me know if you need help.

Cheers,
Nicolas