Handle en_GB and en_US locale

[dangillet]

Fixes #210
Replaces existing PR #222

I tried to push that PR over the finishing line. The commits could all be squashed in a single commit. I wanted to keep track of the original author contribution.

Changes proposed in this pull request:

• Add i18n support for en_GB, en_US and any languages starting with en_*

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.48%. Comparing base (724263d) to head (072b399).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #230   +/-   ##
=======================================
  Coverage   99.47%   99.48%           
=======================================
  Files          11       11           
  Lines         760      771   +11     
=======================================
+ Hits          756      767   +11     
  Misses          4        4           

Flag	Coverage Δ
macos-latest	97.92% <100.00%> (+0.03%)	⬆️
ubuntu-latest	97.92% <100.00%> (+0.03%)	⬆️
windows-latest	96.49% <100.00%> (+0.05%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[hugovk]

I wanted to keep track of the original author contribution.

Appreciated!

What's the reason for removing humanize.i18n.activate(None) from the test (in 36d77e8)? Do we not want to allow that?

[dangillet]

The current type hint for activate is

def activate(
    locale: str, path: str | os.PathLike[str] | None = None
) -> gettext_module.NullTranslations:

So humanize.i18n.activate(None) is not allowed from a type hinting point of view.

If this is desired though, it's absolutely OK to amend the type hint. I will then also need to slightly amend the function implementation to deal with None for locale, which would be the same as choosing an English language.

I don't really see the reason for humanize.i18n.activate(None). If you don't want any translation, or because you're done with one language, I would assume the client would use instead humanize.i18n.deactivate().

I'll let you decide what you think is best.