[elm-discuss] On Intl/CLDR

[Vlad GURDIGA]

Hey everybody! 👋

The other day I found myself writing a function to format numbers
<https://github.com/gurdiga/xo.elm/commit/eac3cb6b92823b9876053c4034de92d307812503#diff-96f92701886b3e767cf8eef9ccf8d9ceR21>.
The first question was: What is the right way to format a number? There
should be a standard or something. 🀔 Googled a bit and found about the
Unicode CLDR Project <http://cldr.unicode.org/>. They have a huge amount of
structured data, and I surely found the data I was looking for. 🀓

Now, seeing all that data, I thought: Wow! Wouldn’t it be cool to have an
Elm library that’l hold all that? elm-cldr? 🎩 Oh, it’d be enormous
 What
if I only need number formatting? Oh, I know: elm-cldr-numbers!
and elm-cldr-dates! and elm-cldr-localenames! and
 Ooooh yeah!! 🀠

Then I remember that the CLDR website was saying that they provide data for
apps and operating systems. Hm
 shouldn’t it be there already somewhere in
the OS? 🀔 Googled a bit more and found that browsers already have that as
window.Intl
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl> and
MDN says it has quite good support, down to IE11. Couldn’t believe that
one, so spun up my Windows VM and pasted a snippet into IE11’s console: it
worked! 👜

Hm
 OK
 Now, it’d really be quite cool to build all those elm-cldr-* things
that I imagined, wouldn’t it make more sense to reuse what’s already there?
What would it be like to use that? OK, let’s go native! A couple hours
later I got myself Native.Intl
<https://github.com/gurdiga/xo.elm/commit/26c5046e9942433cd8f663bd04c18f1ccb6838ee>.
😎

Now, looking at all this I begun wondering what would it be like to have it
in the Elm standard library, and inevitably found Evan’s 2 threads (one
<https://groups.google.com/forum/#!topic/elm-discuss/DPuUPv72abc> and two
<https://groups.google.com/forum/#!topic/elm-dev/1JW6wknkDIo>) about the
philosophy around native in Elm, and I kind of see his point about keeping
Elm high-quality, but how about cases like this where we’re not talking
about JS libraries but about browser’s native APIs like Intl? 🀔

It’d probably be not that hard to get that data
<https://github.com/unicode-cldr/cldr-json> packaged into a few Elm
libraries, hopefully not-that-large each, but it’d still end up growing the
final app bundles, and probably some compilation time during the hundreds
of refreshes a day that a dev does 😳 So I’m not entirely sure it’s a
constructive idea. 😶

So although for my little toy-project I can just use Elm native, how about
long-term? What would make more sense? I mean these two options:

1. implement Elm libraries using the CLDR data
<https://github.com/unicode-cldr/cldr-json>
2. hope that window.Intl will some day become part of Elm standard
library

What are some pros and cons? Are there any other options people have
considered? 🀔

[Ian Mackenzie]

Exposing window.Intl directly also ties Elm more tightly to the
browser/JavaScript environment, which Evan mentioned in that second linked
thread that he is trying to avoid:

Elm is designed to be 100% independent of JS. It happens to compile to JS

now because that was the right thing to do, but in a decade, I expect we'll
be compiling to something more efficient. There is a small set of "native"
stuff for now, but that means supporting the entire ecosystem on a new
platform is fairly easy.

So Elm could currently use window.Intl, but that would mean its
functionality would have to be replicated exactly if Elm ever compiles to a
non-browser environment. Even now that would make life a bit more difficult
for people using Elm code within Node applications - it's possible, but you
have to do things like hook up a third-party XMLHttpRequest implementation
like xhr2 <https://github.com/pwnall/node-xhr2>. If it's not too hard, it's
probably better to reimplement the functionality in pure Elm so that it can
be used on any platform that Elm compiles to in the future.

Hey everybody! 👋
The other day I found myself writing a function to format numbers
<https://github.com/gurdiga/xo.elm/commit/eac3cb6b92823b9876053c4034de92d307812503#diff-96f92701886b3e767cf8eef9ccf8d9ceR21>.
The first question was: What is the right way to format a number? There
should be a standard or something. 🀔 Googled a bit and found about the
Unicode CLDR Project <http://cldr.unicode.org/>. They have a huge amount
of structured data, and I surely found the data I was looking for. 🀓
Now, seeing all that data, I thought: Wow! Wouldn’t it be cool to have an
Elm library that’l hold all that? elm-cldr? 🎩 Oh, it’d be enormous
 What
if I only need number formatting? Oh, I know: elm-cldr-numbers!
and elm-cldr-dates! and elm-cldr-localenames! and
 Ooooh yeah!! 🀠
Then I remember that the CLDR website was saying that they provide data
for apps and operating systems. Hm
 shouldn’t it be there already somewhere
in the OS? 🀔 Googled a bit more and found that browsers already have that
as window.Intl
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl> and
MDN says it has quite good support, down to IE11. Couldn’t believe that
one, so spun up my Windows VM and pasted a snippet into IE11’s console: it
worked! 👜
Hm
 OK
 Now, it’d really be quite cool to build all those elm-cldr-*
things that I imagined, wouldn’t it make more sense to reuse what’s already
there? What would it be like to use that? OK, let’s go native! A couple
hours later I got myself Native.Intl
<https://github.com/gurdiga/xo.elm/commit/26c5046e9942433cd8f663bd04c18f1ccb6838ee>.
😎
Now, looking at all this I begun wondering what would it be like to have
it in the Elm standard library, and inevitably found Evan’s 2 threads (one
<https://groups.google.com/forum/#!topic/elm-discuss/DPuUPv72abc> and two
<https://groups.google.com/forum/#!topic/elm-dev/1JW6wknkDIo>) about the
philosophy around native in Elm, and I kind of see his point about keeping
Elm high-quality, but how about cases like this where we’re not talking
about JS libraries but about browser’s native APIs like Intl? 🀔
It’d probably be not that hard to get that data
<https://github.com/unicode-cldr/cldr-json> packaged into a few Elm
libraries, hopefully not-that-large each, but it’d still end up growing the
final app bundles, and probably some compilation time during the hundreds
of refreshes a day that a dev does 😳 So I’m not entirely sure it’s a
constructive idea. 😶
So although for my little toy-project I can just use Elm native, how about
1. implement Elm libraries using the CLDR data
<https://github.com/unicode-cldr/cldr-json>
2. hope that window.Intl will some day become part of Elm standard
library
What are some pros and cons? Are there any other options people have
considered? 🀔

[Mark Hamburg]

One way to maintain language portability to other environments is to make a distinction between the language and the libraries. Almost every environment is likely to have something special — that's part of what justifies being it's own thing. It is entirely reasonable to say that the Basics library should remain portable. It is, however, also entirely reasonable to expect that the people who did the browser internationalization libraries probably know more about the issues than the people likely to write an Elm internationalization library at this point in Elm's evolution. If that functionality isn't available somewhere else then the library isn't available and that's an issue for that platform not for Elm.

Mark

Elm is designed to be 100% independent of JS. It happens to compile to JS now because that was the right thing to do, but in a decade, I expect we'll be compiling to something more efficient. There is a small set of "native" stuff for now, but that means supporting the entire ecosystem on a new platform is fairly easy.

So Elm could currently use window.Intl, but that would mean its functionality would have to be replicated exactly if Elm ever compiles to a non-browser environment. Even now that would make life a bit more difficult for people using Elm code within Node applications - it's possible, but you have to do things like hook up a third-party XMLHttpRequest implementation like xhr2. If it's not too hard, it's probably better to reimplement the functionality in pure Elm so that it can be used on any platform that Elm compiles to in the future.

Hey everybody! 👋
The other day I found myself writing a function to format numbers. The first question was: What is the right way to format a number? There should be a standard or something. 🀔 Googled a bit and found about the Unicode CLDR Project. They have a huge amount of structured data, and I surely found the data I was looking for. 🀓
Now, seeing all that data, I thought: Wow! Wouldn’t it be cool to have an Elm library that’l hold all that? elm-cldr? 🎩 Oh, it’d be enormous
 What if I only need number formatting? Oh, I know: elm-cldr-numbers! and elm-cldr-dates! and elm-cldr-localenames! and
 Ooooh yeah!! 🀠
Then I remember that the CLDR website was saying that they provide data for apps and operating systems. Hm
 shouldn’t it be there already somewhere in the OS? 🀔 Googled a bit more and found that browsers already have that as window.Intl and MDN says it has quite good support, down to IE11. Couldn’t believe that one, so spun up my Windows VM and pasted a snippet into IE11’s console: it worked! 👜
Hm
 OK
 Now, it’d really be quite cool to build all those elm-cldr-* things that I imagined, wouldn’t it make more sense to reuse what’s already there? What would it be like to use that? OK, let’s go native! A couple hours later I got myself Native.Intl. 😎
Now, looking at all this I begun wondering what would it be like to have it in the Elm standard library, and inevitably found Evan’s 2 threads (one and two) about the philosophy around native in Elm, and I kind of see his point about keeping Elm high-quality, but how about cases like this where we’re not talking about JS libraries but about browser’s native APIs like Intl? 🀔
It’d probably be not that hard to get that data packaged into a few Elm libraries, hopefully not-that-large each, but it’d still end up growing the final app bundles, and probably some compilation time during the hundreds of refreshes a day that a dev does 😳 So I’m not entirely sure it’s a constructive idea. 😶
implement Elm libraries using the CLDR data
hope that window.Intl will some day become part of Elm standard library
What are some pros and cons? Are there any other options people have considered? 🀔

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
For more options, visit https://groups.google.com/d/optout.