diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index e2b544234..fad7a6c0d 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -30,14 +30,15 @@ Opening an issue beforehand allows the administrators and the community to discu
 2. Create a new branch for each PR. **Make sure your branch name wasn't used before** - you can add date (for example `patch3_20200528`) to ensure its uniqueness.
 3. Single feature or bug-fix per PR.
 4. Create a PR with a single commit to make the review process easier.
-5. Make your modification compact - don't reformat source code in your request. It makes code review more difficult.
-6. PR of reformatting (changing of ws/TAB, line endings or coding style) of source code won't be accepted. Use issue trackers for your request instead.
-7. Typo fixing and code refactoring won't be accepted - please create issues with title started with `TYPO` to request the changing.
-8. The PR for the enhancement of Function List parser should also include unit test. Please refer [here](https://npp-user-manual.org/docs/function-list/#contribute-your-new-or-enhanced-parser-rule-to-the-notepad-codebase) for more information. 
-9. Address the review change requests by pushing new commits to the same PR. Avoid amending a commit and then force pushing it. All the PR commits are squashed before merging to the main branch.
-10. When creating new PR, try to base it on latest master.
-11. Normally you don't need to merge `upstream/master` (using git or via github sync), if your PR is based on older `upstream/master`. If you need to base it on latest `master` (e.g. to check and fix merge conflict), use commands `git fetch upstream` to get latest `master` and then `git rebase upstream/master` to rebase it onto this latest `upstream/master`.
-12. Finally, please test your pull requests, at least once.
+5. For the PR of translation, don't guess or use the next version number. Use the current version number instead.
+6. Make your modification compact - don't reformat source code in your request. It makes code review more difficult.
+7. PR of reformatting (changing of ws/TAB, line endings or coding style) of source code won't be accepted. Use issue trackers for your request instead.
+8. Typo fixing and code refactoring won't be accepted - please create issues with title started with `TYPO` to request the changing.
+9. The PR for the enhancement of Function List parser should also include unit test. Please refer [here](https://npp-user-manual.org/docs/function-list/#contribute-your-new-or-enhanced-parser-rule-to-the-notepad-codebase) for more information. 
+10. Address the review change requests by pushing new commits to the same PR. Avoid amending a commit and then force pushing it. All the PR commits are squashed before merging to the main branch.
+11. When creating new PR, try to base it on latest master.
+12. Normally you don't need to merge `upstream/master` (using git or via github sync), if your PR is based on older `upstream/master`. If you need to base it on latest `master` (e.g. to check and fix merge conflict), use commands `git fetch upstream` to get latest `master` and then `git rebase upstream/master` to rebase it onto this latest `upstream/master`.
+13. Finally, please test your pull requests, at least once.
 
 In short: The easier the code review is, the better the chance your pull request will get accepted.