Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internationalise the decimal separator in intcomma() #53

Merged
merged 1 commit into from Aug 30, 2022

Conversation

Luflosi
Copy link
Contributor

@Luflosi Luflosi commented Aug 30, 2022

See discussion in #48.

Changes proposed in this pull request:

  • Add the proper decimal separator for the de_DE locale
  • Add some tests

@codecov-commenter
Copy link

codecov-commenter commented Aug 30, 2022

Codecov Report

Merging #53 (496b5a8) into main (d8e2739) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #53      +/-   ##
==========================================
+ Coverage   99.28%   99.29%   +0.01%     
==========================================
  Files           9        9              
  Lines         696      710      +14     
==========================================
+ Hits          691      705      +14     
  Misses          5        5              
Flag Coverage Δ
macos-latest 97.60% <100.00%> (+0.04%) ⬆️
ubuntu-latest 97.60% <100.00%> (+0.04%) ⬆️
windows-latest 96.33% <75.00%> (-0.65%) ⬇️

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

Impacted Files Coverage Δ
src/humanize/__init__.py 100.00% <100.00%> (ø)
src/humanize/i18n.py 98.33% <100.00%> (+0.22%) ⬆️
src/humanize/number.py 97.12% <100.00%> (+0.04%) ⬆️
tests/test_i18n.py 100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Comment on lines 44 to 54
try:
humanize.i18n.activate("de_DE")
assert humanize.intcomma(number) == "10.000.000"
assert humanize.intcomma(1_234_567.8901) == "1.234.567,8901"
assert humanize.intcomma(1_234_567.89) == "1.234.567,89"
assert humanize.intcomma("1234567,89") == "1.234.567,89"
assert humanize.intcomma("1.234.567,89") == "1.234.567,89"
assert humanize.intcomma("1.234.567,8") == "1.234.567,8"

humanize.i18n.activate("fr_FR")
assert humanize.intcomma(number) == "10 000 000"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

humanize.i18n.activate("EN")
assert humanize.intcomma(1_234_567.8901) == "1,234,567.8901"

It would be good to add a test for a non-German locale to show that the original behavior is preserved. @hugovk, are the doctests verified by the CI?

Also, it should be documented that if the input is a string, it must already match the locale. i.e. This function is not to be used to convert a string from one locale to another.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to add a test for a non-German locale

There are already tests for the default locale. Or do you mean a non-German, non-default locale?

Also, it should be documented that if the input is a string, it must already match the locale.

This was already the case with the thousands separator btw. Where would be a good place to document this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are already tests for the default locale. Or do you mean a non-German, non-default locale?

This is exactly it. I didn't realize localization tests were separate from default locale tests. Thanks!

Where would be a good place to document this?

In the intcomma docstring would be the best place. It may already be the case, but it is not documented as such.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how best to write this, given that it doesn't really even mention that strings are allowed, except in two examples and partially in the arguments.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to add a test for a non-German locale to show that the original behavior is preserved. @hugovk, are the doctests verified by the CI?

Yes, doctests are run by pytest and pytest is run on the CI.

Copy link
Contributor

@carterbox carterbox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation closely follows existing implementation for thousands separation localization. Tests are sufficient. LGTM!

Copy link
Member

@hugovk hugovk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this! Just a few little nits :)

src/humanize/__init__.py Outdated Show resolved Hide resolved
src/humanize/i18n.py Outdated Show resolved Hide resolved
@hugovk hugovk added the changelog: Added For new features label Aug 30, 2022
@Luflosi
Copy link
Contributor Author

Luflosi commented Aug 30, 2022

Done.

@hugovk hugovk enabled auto-merge August 30, 2022 18:58
@hugovk hugovk merged commit 72d3ef4 into python-humanize:main Aug 30, 2022
@Luflosi Luflosi deleted the implement-decimal-sep-i18n branch August 30, 2022 18:59
@hugovk
Copy link
Member

hugovk commented Aug 30, 2022

Thank you!

@hugovk hugovk changed the title Internationalise the decimal separator in intcomma() Internationalise the decimal separator in intcomma() Sep 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog: Added For new features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants