toString functions?

[gampleman]

I think there is an interesting challenge related to elm-units, which is how to format them for human consumption.

For example,

Length.meters 12000.3

could be shown as:

• 12 km
• 12,000.3 m
• 7.46 miles

I assume that a formatter for length would like to know the precision and whether to prefer imperial or SI units.

Other units have similar issues.

Angle is interesting, since it is formatted like this often:

• 123º 12' 32"

I don't know if there are significant internationalization challenges here (except perhaps duration), but worth thinking about.

[ianmackenzie]

I agree this is important, but I also think that it is probably sufficiently interesting to go into a separate package (elm-units-format? elm-units-extra?) where the API can evolve independently. Among other things I think there are real internationalization challenges, like "1 foot" in English vs "1 pied" in French if you want to use just about anything other than the standard SI symbols. I'd be happy to collaborate on such a package, though! Thoughts?

[gampleman]

Well, I agree that it is a significant amount of complexity that is slightly orthogonal to the package as it is. But as a user I think I'd quite like to have some of that formatting right at my fingertips and not necessarily have to find out about another package then install it, etc.

On the i18n front, I feel like that's a topic that the Elm community doesn't really have a great solution to yet. There are plenty of options, but none of them feel just right to me (and most of these are oriented towards applications rather than packages). So not sure what to recommend on that front.

[gampleman]

Actually I was reading a bit about the Intl api:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat/NumberFormat

Seems like they solve a decent number of the formatting issues.

[ianmackenzie]

Read through a bit, that does look like a useful reference! I still think it will take a few tries to get an API that works well, though, so my preference would still be to start by adding this to something like an elm-units-extra package (could even be ianmackenzie/elm-units-extra for easier discoverability/'officialness'), with the plan that once the API stabilizes it could be merged into elm-units proper. (I think that approach would also be a good one for some other proposed units types like frequency and binary data that also have some non-obvious API design decisions.) Does that make sense?

[gampleman]

Yes of course. What I was also suggesting with my previous comment, was that when Elm does get official Intl bindings, then it might be best to tackle this, as making internationalised packages is quite annoying without it.