# Bindings for Intl

**URL:** https://discourse.elm-lang.org/t/bindings-for-intl/1264
**Category:** Request Feedback
**Created:** [May 16, 2018, 6:40am UTC](https://discourse.elm-lang.org/t/bindings-for-intl/1264 "2018-05-16T06:40:33Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![spookylukey](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/spookylukey/32/669_2.png) [@spookylukey](https://discourse.elm-lang.org/u/spookylukey)
#### Post date: [May 16, 2018, 6:40am UTC](https://discourse.elm-lang.org/t/bindings-for-intl/1264/1 "2018-05-16T06:40:33Z")

</div>

Hi all,

I need to use Intl.NumberFormat, Intl.DateTimeFormat etc. in my app. (see [MDN docs for Intl](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl))

There is an Elm library that provides this - [https://github.com/vanwagonet/elm-intl](https://github.com/vanwagonet/elm-intl) - using native modules, which means it can’t be published to elm-packages etc. The author started a discussion on the Google group about how to move this forward so that it can be easily installed - [https://groups.google.com/forum/#!topic/elm-dev/Qt9Os7dIrSs](https://groups.google.com/forum/#!topic/elm-dev/Qt9Os7dIrSs) - but it stalled. Can we start that discussion again?

Presumably the right thing is for this to be included in elm-lang somewhere. The linked discussion outlines all the reasons why a native/kernel module is the right way to go for this.

---

<div class="post-metadata">

### Author: ![evancz](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/evancz/32/16_2.png) [@evancz](https://discourse.elm-lang.org/u/evancz)
#### Post date: [May 16, 2018, 3:25pm UTC](https://discourse.elm-lang.org/t/bindings-for-intl/1264/3 "2018-05-16T15:25:32Z")

</div>

Reviewing “here is a big package that is an exact copy of JS code” is not an optimal path.

Is everything pure functions? What things are not pure functions? What is special about them? What would need to happen for those functions to work?

In other words, provide information about what’s actually going on. Right now it’s just like “there’s a thing” and that’s not enough information to expand upon. What are people asking for? A full 100% audit with no supporting materials, explanation of the approach, etc. How can I assess if that is worth prioritizing? Do I just have to do the 100% audit to find out? That seems like a risky path that diverts focus from other things. Can it look less risky? Sure. I just need more info.

---

<div class="post-metadata">

### Author: ![spookylukey](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/spookylukey/32/669_2.png) [@spookylukey](https://discourse.elm-lang.org/u/spookylukey)
#### Post date: [May 17, 2018, 11:44am UTC](https://discourse.elm-lang.org/t/bindings-for-intl/1264/4 "2018-05-17T11:44:41Z")

</div>

Thanks for the reply Evan, I’ll try to provide some more information - I was unsure how to go about this at all, especially as the work is not mine, and it looks like the original author currently has limited time to put into this.

After a very quick check, I think everything in the package is pure functions (I can do further checks, but there is no need for any of it to be non-pure, because what is wraps is entirely pure, except for a few functions that can raise exceptions if you pass in invalid values). Very little of the code is a ‘copy’ of JS - it is simply wrappers for the browser builtin package `Intl` (This library is not available in some older browsers, but there is a polyfill).

As explained in another thread, we **really** do not want to re-implement the entire library in pure Elm. This would likely be a massive effort (not to mention extremely boring), the result would be likely very slow and buggy, and it would require sending a huge amount of data over the wire (CLDR data from the Unicode consortium) - data that is built-in to modern browsers.

In terms of design/approach, I think this is one of the ‘boring’ bits of the web platform which is pretty straightforward to wrap, where mostly you should stick as close as possible to the JS API (so that people can transfer knowledge/docs with little friction), and add some Elm-ish improvements. My initial impression is that the current implementation does that already and looks very good.

To be more specific, the browser API ([MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl)) is that you create `NumberFormat`/`DateTimeFormat` objects, and then use methods on these to format a number in local aware way, for example. This API is already well designed for good performance - once you have a `NumberFormat` object, for example, you can keep on using that rather than having to look up the locale every time.

The Elm wrappers pretty much follow the same API, which allows for good performance while keeping them very simple. There are a few points where it does some obvious mappings into Elm:

- `Maybe` for APIs that can return `null` or throw errors
- Where the JS API takes an `options` object (which in JS land can have any number of attributes or none), the default options are exposed as a strongly typed record which can then be used as a basis for specifying non-defaults (like [this](http://elm-directory.herokuapp.com/package/vanwagonet/elm-intl/1.0.0/Intl.DateTimeFormat#defaults))
- Simple union types for options that can take a few specific values.

In addition, it looks like the `Locale` object is an Elm specific innovation. Instead of passing strings like `en-US` to create a `NumberFormat` object, you first create a `Locale` object from `en-US` which validates it (and can therefore return `Nothing`), and then use this to create `NumberFormat`. This means that you get much better error handling and eliminate runtime errors that are possible with the JS API.

Formatted docs for the included modules can be found here:

[http://elm-directory.herokuapp.com/package/vanwagonet/elm-intl/1.0.0/Intl.Locale](http://elm-directory.herokuapp.com/package/vanwagonet/elm-intl/1.0.0/Intl.Locale)

(I’ve spotted some issues in the docs already, these would be need to be cleaned up).

Is there someone else who could do the auditing/review of this to take the burden off you? I’m happy to do a full review of it myself and give a report, if that would help at all, I don’t know what your process is for this kind of thing. I could also go through the docs and submit issues/PRs for anything I find, and then get back to you.

---

<div class="post-metadata">

### Author: ![system](https://canada1.discourse-cdn.com/flex035/uploads/elm_lang/original/1X/50a05e53677a2c3b47776d7abd0f113eb50193a1.png) [@system](https://discourse.elm-lang.org/u/system)
#### Post date: [May 27, 2018, 11:44am UTC](https://discourse.elm-lang.org/t/bindings-for-intl/1264/5 "2018-05-27T11:44:46Z")

</div>

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.
