Add i18n to go-humanize about go-humanize HOT 7 CLOSED

I agree. Every time I've thought about how to do this, it's been essentially what you described -- write a new library. There's so much involved in dealing with all the different locale-specific ways to represent the data. There are a few high level formatters that can be rearranged in specific applications, but I haven't been able to figure out how to fit in localized variations (and I'm not even that familiar with most of them, just enough to make it seem really complex).

from go-humanize.

Is there any similar lib with i18n support nowadays?

from go-humanize.

Personally, I don't think we should add i18n here. The amount of volume and work to create and maintain it would be huge, and overshadow the size of this entire library as it is now. It's relatively small and focused because it's English-only.

I think that if someone wanted an i18n-capable version of this, it would be best done as a new separate package (and go-humanize README can link to it). When a feature request is more than 100% of scope of existing project, it doesn't feel right to just add it in.

So, I would advise against doing this. If it's not going to be actively developed and maintained, a half-baked partial i18n support is only going to complicate the library, and not provide enough value to people who actually want to make use of it. It's better to stay small and focused and high quality.

Of course, it's up to @dustin, but I'm judging by lack of response and progress on this issue/PR after 3 years that it's not going to be a good fit.

What do you think about making adding it to your own version of a similar library @jfbus? That way, you can also change the APIs to be a better fit, if neccessary.

from go-humanize.

I can submit a PR

from go-humanize.

@dustin, is i18n in scope for this project or out of scope?

from go-humanize.

If necessary, I can update my PR.

from go-humanize.

OK. I'll try to work on an i18n compatible lib.

from go-humanize.