The Future™ about twitter-cldr-rb

[arnavk]

Something like breaking up the project might affect feature development (i.e., in terms of which gem gets which feature, etc.) For this reason, I think it might make sense for us to decide on/tackle the more logistical issues like a name change or the project split before the heavier tasks like feature development. What do you guys think?

[camertron]

@radzinzki Well, the feature development work is stuff that I'm already working on in my (limited) spare time, which might get merged before we've sorted out all the logistics. If we create one gem per feature, dividing the project shouldn't be too difficult.

[KL-7]

That's a lot of ideas, @camertron! Like that. Here are my thoughts:

1. I don't think renaming the project and all the gems and repositories is worth it at this point. People who are familiar with the libraries already know what they do and people who aren't should easily figure it out from the READMEs. I agree that we could have picked a better name from the start, but now all the renaming will do is make both us and our users deal with all sorts of tedious changes (renaming all the repositories, libraries, modules, etc.).
2. ruby-cldr definitely needs some revamping. It'd be awesome if we could use JSON data directly in twitter-cldr. How incomplete is it? If not, I'd still prefer to use our own YAML resources simply because they contain only what we need and in a much more succinct format. In that case we'll need some replacement for ruby-cldr (either a fork or a rewritten from scratch library), that I'd suggest to keep out of twitter-cldr simply because it's a lot of code that is never needed during runtime. We can move our resource importers into that library as well.
3. I understand why we might want to break up twitter-cldr-js into multiple libraries and that's actually something people have been asking for after we added quite a few data-heavy features this year (basically having core library and then all the "big" features in a separate package). Though, I don't think we need to split twitter-cldr-rb. Maintaining and versioning multiple related gems can become cumbersome really fast and the benefits it'd provide are probably not worth it. As long as it is well modularized and uses auto-load (as it is right now) I don't see why anybody would care about the size of the gem.
4. Yay for more features! \o/
5. That's definitely something we need to do. We also have some features that are stuck on v24 CLDR data, so it might not be easy, but definitely should be done.
6. Yeah, a more flexible mechanism for extensions/overrides would be awesome.

[camertron]

1. Ok, I'm cool with keeping the name the same.
2. I'm not sure how incomplete the JSON data is. I just remember that last time I looked at date formatting, I couldn't find all the data I needed. Everything is present in the XML. Another thing to consider is that CLDR doesn't consider the JSON format to be "official." There does seem to be quite a bit of momentum behind it, mostly because of JavaScript. I guess we just have to decide what the JSON benefits are. Honestly I don't see that many. Revamping ruby-cldr's existing XML parsing functionality is probably the easiest path forward. I also agree with moving our Unicode resource importers to ruby-cldr.
3. It's not minimizing the size of the gem that I see as important. As a maintainer of the project, I know where most of the code lives, but someone who's never seen the code before would likely be overwhelmed by the complexity. To me, dividing the library up into smaller pieces helps minimize that complexity. It also helps in that we can release parts of the library independent of other parts. This is how rspec does things, and from what I can tell it works well for them.
4. 😀
5. 😀
6. 😀

[KL-7]

Regarding 3:

My concern is that unless the separation is absolutely straight-forward and obvious (e.g., in Rails every gem has its own top-level module), separation actually makes it harder to find certain things if you want to check out the source code. I ran into that issue myself with Rspec – even though their separation is quite simple, I wasn't familiar with it and it took me a while to locate the class I was interested in. With one gem and one repository, everything is in one bundle and it's much easier to find things both for users and for developers.

Regarding release, I don't really see any benefits to releasing different features independently in case of twitter-cldr-rb.

Also, I had to support a few interconnected gems a couple of years ago and the release process wasn't fun simply because any minor/major bump in the core part requires you to go and upgrade every single dependent gem just for the sake of bumping up core gem version.

[camertron]

Right, releasing interdependent gems can be a real issue. We run into that all the time at Lumosity, actually (lots of PRs that say, "Bumping gem xyz"). Honestly I don't think we would run into those kinds of issues, since the gem hierarchy I'm thinking of would be a single core gem with feature gems built on top. Generally we would release all the gems at the same time, i.e. when we update to a newer version of CLDR.

That said, the more I think about it though the more I'm realizing that we probably won't get that much benefit out of separate gems. What we need instead is better internal gem organization.

[KL-7]

What we need instead is better internal gem organization.

This is something I definitely agree with. I don't think it's too bad right now, but there's a lot of space for improvement.

[sandstrom]

Thanks for an excellent library! I found this very useful! ⛵

1. Renaming the project I think it works, renaming takes a bit of effort. But I also agree that it's not a good name.

   ricu may be pretty cryptic though, I'd suggest a word of some sort! Unfortunately rosetta is taken by an (abandoned) gem. Something in that vein would be great!

2. Absorb or improve CLDR parsing logic I understand, perhaps it can be forked/reworked. Agree it would make sense to keep it separate.

3. Break the project up into different gems I think this isn't really worth it, gem size isn't an issue, people can pick the pieces they want. My only wish here would be a way of disabling the automatic injection of localize methods on Time etc.

4. Upgrade to the latest CLDR Version Would be useful, especially trying to automate this process (to the extent it's possible, to reduce the cost)

[camertron]

Thanks for your input @sandstrom :) I've thought about a mechanism for disabling the automatic injection of the localize method on the core ruby classes. That's probably something we should address in the next major release.

[camertron]

All the feature development described in this issue has been implemented and released as v4.0.0, including transliteration and an upgrade to CLDR v29 (not quite the latest, but damn it if they didn't release a new version a few weeks ago).

We have decided not to rename the gem or break it up into different gems. Gem overrides and better CLDR parsing logic remain issues we should continue looking into.

[sandstrom]

Awesome @camertron! 🎉

Renaming isn't a major thing, this name totally works. Happy to see a big update! 😃