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 97.95%. Comparing base (724263d) to head (97afe65).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #230      +/-   ##
==========================================
- Coverage   99.47%   97.95%   -1.52%     
==========================================
  Files          11       11              
  Lines         760      783      +23     
==========================================
+ Hits          756      767      +11     
- Misses          4       16      +12     

Flag	Coverage Δ
macos-latest	97.95% <100.00%> (+0.06%)	⬆️
ubuntu-latest	97.95% <100.00%> (+0.06%)	⬆️
windows-latest	97.95% <100.00%> (+1.50%)	⬆️

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.

[hugovk]

Yes, these are good points.

I do see a couple of uses of humanize.i18n.activate(None if lang == "en" else lang) in the wild, which admittedly isn't much for a package downloaded 13 million times per month.

https://github.com/search?q=%2Factivate%5C%28None%2F&ref=opensearch&type=code

But we don't know how much non-GitHub code might do activate(None), and on balance I think it's probably better to allow it for compatability. It doesn't cost us much to allow None.

What do you think?

[dangillet]

I fully agree. It seems like a good idea to allow activate(None). I just wanted to make sure you were aware of it.

I made the change and I moved to test inside the TestActivate class as it seems to belong there - we're testing more usage to activate.

I then noticed that the original test had a small issue. It did not use the decorator @freeze_time("2020-02-02"), which means that when it was calling humanize.naturaltime(three_seconds), the result actually was 5 years ago which is pretty surprising.

I decided to reduce this gotcha effect by making NOW a pytest fixture. Any code that would use it would have its time frozen in 2020-02-02.

[dangillet]

My unit tests were failing on Windows because gettext was not installed. I amended test.yml file to install gettext on Windows and compile the translation files.

The unit tests now pass on Windows but I'm getting two failures for linting and code coverage one failure for coverage.

I don't understand the linting issue. Locally I'm not getting any linting issue. I also tried to copy-paste test.yml content in https://rhysd.github.io/actionlint/ and I'm not getting any failures. The linter uses actionlint which uses ShellCheck for run commands. It's a shell script static analysis tool, which then does not understand Windows commands. I decided to move those commands to a separate script file. I'm torn on the location. I put it under scripts, but it's only useful for the Github Action, as it's dealing with $env:GITHUB_PATH. Maybe it would be better placed within the .github folder?

For code coverage, I'm looking on Sentry, but the only lines that are not tested seem to be the docstring I added to the pytest fixture. What am I missing?