search

dustin / go-humanize

Go Humans! (formatters for units to human friendly sizes)
https://pkg.go.dev/github.com/dustin/go-humanize
Other
4.37k stars 233 forks source link

Monetary Abbreviations (Proposal) #77

Open zacharyburkett opened 5 years ago

zacharyburkett commented 5 years ago

I would like to see functionality for monetary abbreviation.

For example, an application I wrote recently integrates with a game I play. It displays in game currency with abbreviations. $1,000,000 becomes $1m, $150,899 becomes $150.9k, etc.

I already have an implementation that I made, so I was wondering if this functionality would be welcome in this project.

jamesallured commented 3 years ago

Hey! I like this idea a lot but I'd question how you would get around the precision of abbreviation, i.e. some people might want $151k for $150,899 instead of $150.9k. Does your implementation cover this at all?

I'm just trying to think of some similar examples that make decisions on precision but I don't think there are any in this package. I think it's probably fine to be opinionated on what it should be, i.e. if it doesn't round to a whole number, then it displays to one decimal place but would want to be clear in documentation.

lfaoro commented 3 years ago

you mean something like this?

https://github.com/dustin/go-humanize/issues/94

MikkelHJuul commented 2 years ago

@jamesallured - https://github.com/dustin/go-humanize/blob/master/si.go#LC101

The monetary code could follow SI

@lfaoro - one could add non-shorthand notation as well thousand, million, trillion...

I would leave out the currencies in the beginning, focus on something easy

dustin commented 2 years ago

This isn't quite universal, though. In finance, US dollars are abbreviated to million with MM (thousand thousand). In environments that use Lakh, it's super confusing. This quickly becomes a localization issue. I'm not sure how to generalize this to the different use cases since we do have different precision and localization requirements.

MikkelHJuul commented 2 years ago

@dustin - wouldn't it be a lot simpler to have the user supply a map[float64]string

map[float64]string{
        ...
    3: "thousand", 
    6: "million", 
    9: "billion", 
        ...
}

that way you can separate the algorithm from the data. (Decades of multiples of 1 should be handled, also, you may want to have only integer decades (in stead of float64 (how would you handle non-integer floats?))

It may require some work for building the object, that has a parser etc. but it is doable.