Disclaimer: @theosp is the author of TAP:i18n, I am just a guy who rewrote it. Furthermore, for the last couple of month I was not very involved with the meteor community. So I might not be up to date on what’s going on right now.
late last year I found myself in the situation were I had no other choice than rewriting TAP:i18n because in our projects we wanted to use ES6 modules (v1.3), which broke TAP:i18n, and I didn’t want to reason about coffeescript. after all the main work, which includes preserving reactivity and the attempt of preserving the API (and declarative configuration concept) for (partial) backward compatibility, I had to take a break and write my masters thesis. That’s why I am only now reaching out to you.
Currently, I have no idea of how important the TAP:i18n support for meteor >= 1.3 is for the community at the moment. So, some feedback on that would be appreciated. I searched through the forum, but aside from a mention from the original author here I didn’t found much on the topic
one major thing is still missing: testing. maybe some existing tests can be reused, they have to be at least revisited though. But my guess, most of the testing has to be rewritten. Also that’s why It never got merged into upstream
it was written with 1.3 but I just tested it with 1.4, which works just fine
I never tested it with the other TAP packages: UI, DB
I think, my main questions would be, is it worth to get tap:i18n fully operational again (with current meteor versions)? And what is the best way to proceed?
I think it maskes a lot of sense to switch it to es2015, since translations is something that might benefit from the upcoming 1.5, which will allow to dynamically import modules(and also translation parts) as needed. I’m sure that to move in that direction, starting from a es2015 base would be much easier.
In regards to other libraries/packages that work on meteor for translation, there are a few, but I think TAP is still one of the most used(especially for Blaze users)
For Blaze definitely, for React there are libraries like react-intl and Angular has internationalization build in.
It would be nice if the other packages could be refactored as well. Would be nice to see the DB package not to have the admin dependency and possibly be completely independent, but that is getting into my wish list.
If you’ll get to the point where you think your rewrite is satisfactory, we can discuss release of tap:i18n v2.0 (major increase to allow for breaking changes, and to indicate the rewrite).
You can contact me directly over DM, to find a more direct channel for discussions between us, and I can find time for Skype meetings to help your effort to succeed.
I’ll comment that a lot of work was invested on tap:i18n. In total I guess it is around 2 full-time month. While it is sad that over time Meteor API changes made it more and more non-functional, we did get better Meteor with every version released (the compile time improvement in v1.4 is astonishing).
Therefore, I think it was wrong of me to say in the comment you linked to that every new release is a net-negative. For their available resources MDG is doing huge and amazing work, and for the moment I think it is too much to expect something equivalent to LTS in terms of API changes etc - I really see they do the best they can.
