Would you find localised collation useful in the ex_cldr_* family of libraries?

I’m nearly the next milestone on the ex_cldr_* family of libraries (just need to finish up ex_cldr_dates_times to version 2.x).

I’d like feedback as to whether or not localised collation (sorting in a localised way) would be useful for the community.

Like everything in localisation, is seems straight forward until you start reading the specifications like TR35 and my “lets do this to learn elixir for a couple of weeks” has turned into much more.

Collation is its own special thing and TR10 is another fun spec to decode. But I’m up for the challenge if there is interest.

Oh, and ex_cldr passed 100,000 downloads this week. Well beyond any expectation I had so I hope that means somebody is finding it useful.

10 Likes

This seems like an interesting challenge indeed!

My advice would be – just go for it and do not care about if it’s widely needed now or not. Many people try Elixir, some are staying and some are leaving but IMO if we gradually make the whole experience more mature, we increase the chances of Elixir, and Erlang, and any BEAM languages.

Just go for it is my usual strategy :slight_smile: Thanks for the encouragement. I’ve elected to go ahead basing the implementation of the NIF-based erlang-ucol library. I’ve pushed a 0.10 of an Elixir interface version to hex.

Next up is the work to be able to do locale-sensitive collation. This is my first foray into NIF-land so its going to take a little longer that usual I expect. It will mean that a language tag like de-u-co-phonebk will directly interpreted to mean the phonebk ordering for German.

It will support all of the various options in the u extension in BCP 47 and therefore be a quite feature complete and being a NIF, reasonable performance (locale-sensitive collation is computationally quite heavy).

3 Likes