Icu - Fast and lightweight Localization for Elixir

That’s great work. Maybe this is a better way to go for localisation in Elixir than the ex_cldr libs?

I think both libraries have value, would be cool to have benchmarks of both so people have more data points for which and when they should choose one or the other. But also both suffer the same pain that not all data is exposed and need continuous maintenance and contributions.

Is there some particular data you’re thinking of that’s in CLDR but not exposed?

No, but if you look in this repo you’ll see what I mean.

Are you referring to the data directory?

This is automatically generated by a script, was planning on automating publishing updates with CI at some point, but I haven’t gotten there yet.

Thanks!

I am unsure, it certainly has some advantages around compile time and not having to implement a ton of the algorithms.

On the other hand it does use a NIF, which I know some people have a high threshold for using in production.

icu4x is also not fully feature-complete. There are probably a few things which are not present in icu4x at all which ex_cldr has. As an example, when implementing it for our use case I had to get some currency stuff exposed from upstream icu4x which we needed.

I’m thinking the nif and lib, unless that is what you’re generating. And also you mentioned you had to make changes to icux itself.

I do believe that we can make ex_cldr compile a lot faster, especially by leveraging persistent_term. Anyway I believe that runtime behaviour is more interesting.

Ah if you mean that code need to be written in the library to expose this stuff then this is true. I would be curious to hear what you think the alternative here would be through.

If ex_cldr compilation can be made a lot faster then that is great news! This is one of the main pain points which made us write this library.

My comment on the generation was directed at Kip’s question if icux would be a better foundation to build on, I disagree as both solutions faces similar constraints with regards to maintaining and data exposure.

So it does do make it easier. The two approaches have similar value with different trade offs.

Whats great about ex_cldr is that it’s all in Elixir and if we can it should be used as a target for making the BEAM compiler faster.

The upcoming Localize (ex_cldr 3.0) will compile much much faster. The current bottleneck is the compiler phase that deals with multiple functions heads. Its gets very very slow when there are many many function heads - and thats relied upon heavily in the current implementation. The new implementation is runtime only (no compile time config), uses persistent_term for data storage (not compiled artifacts - with a couple of exceptions).