| id | contributing |
|---|---|
| title | Contribute to Humanizer documentation and languages |
| sidebar_position | 1 |
| diataxis | explanation |
| persona | contributor |
| example | illustrative |
Start with the smallest path that matches the problem:
- Wrong or awkward output: report a language issue.
- Locale behavior needs code or YAML changes: add or update a locale.
- Existing engines do not fit: choose or extend a locale engine.
- Output differs by platform: probe globalization data and add a narrow override.
- Documentation is wrong or unclear: contribute documentation.
- You need a field name or engine contract: use the YAML reference.
Language contribution is visible here without being a prerequisite for using Humanizer. User guidance stays under Languages and cultures.
A useful issue report is a compact, reproducible record:
Culture: fr-CA
Humanizer version: 3.0.10
API call: 2.ToWords(culture)
Expected: ...
Actual: ...
Platform/TFM: macOS, net8.0
That is enough to route the problem before anyone changes locale ownership or grammar.
Do not start by copying a parent locale or adding a culture code to a registry. A successful lookup is not proof of natural output, and package presence is not capability coverage. Trace the owning YAML surface and reproduce the behavior first.
The YAML and generator workflow in this contributor cluster describes
main/preview. Published releases through 3.0.10 have version-specific
package and localization implementations. Report the exact version, and make
changes against the branch that owns that version.