Your contributions to Humanizer are very welcome.
If you find a bug, please raise it as an issue.
Even better fix it and send a pull request.
If you like to help out with existing bugs and feature requests just check out the list of issues and grab and fix one.
Some of the issues are labeled as as
jump in. These issues are generally low hanging fruit so you can start with easier tasks.
This project uses GitHub flow for pull requests.
So if you want to contribute, fork the repo, preferably create a local branch, based off of the
dev branch, to avoid conflicts with other activities, fix an issue, run build.cmd from the root of the project, and send a PR if all is green.
Pull requests are code reviewed. Here is a checklist you should tick through before submitting a pull request:
- Implementation is clean
- Code adheres to the existing coding standards; e.g. no curlies for one-line blocks, no redundant empty lines between methods or code blocks, spaces rather than tabs, etc.
- No ReSharper warnings
- There is proper unit test coverage
- If the code is copied from StackOverflow (or a blog or OSS) full disclosure is included. That includes required license files and/or file headers explaining where the code came from with proper attribution
- There are very few or no comments (because comments shouldn't be needed if you write clean code)
- Xml documentation is added/updated for the addition/change
- Your PR is (re)based on top of the latest commits from the
devbranch (more info below)
- Link to the issue(s) you're fixing from your PR description. Use
fixes #<the issue number>
- Readme is updated if you change an existing feature or add a new one
- Run either
build.ps1and ensure there are no test failures
Please rebase your code on top of the latest
dev branch commits.
Before working on your fork make sure you pull the latest so you work on top of the latest commits to avoid merge conflicts.
Also before sending the pull request please rebase your code as there is a chance there have been new commits pushed after you pulled last.
Please refer to this guide if you're new to git.
One area where Humanizer can always use your help is localisation.
Currently Humanizer supports quite a few localisations for
Humanizer could definitely do with more translations.
To add a translation for
fork the repository if you haven't done yet, duplicate the resources.resx file, add your target locale code
to the end (e.g. resources.ru.resx for Russian), translate the values to your language, write unit tests for the translation, commit, and send a pull request for it. Thanks.
Some languages have complex rules when it comes to dealing with numbers; for example, in Romanian "5 days" is "5 zile", while "24 days" is "24 de zile" and in Arabic "2 days" is "يومين" not "2 يوم".
Obviously a normal resource file doesn't cut it in these cases as a more complex mapping is required.
In cases like this in addition to creating a resource file you should also subclass
DefaultFormatter in a class that represents your language;
e.g. RomanianFormatter and then override the methods that need the complex rules.
We think overriding the
GetResourceKey method should be enough.
To see how to do that check out
Then you return an instance of your class in the Configurator class in the getter of the Formatter property based on the current culture.
ToOrdinalWords methods are currently done in code as there is a huge difference between the way different languages deal with number words.
Check out Dutch and
Russian localisations for examples of how you can write a Converter for your language.
You should then register your converter in the ConverterFactory for it to kick in on your locale.