Thanks, @serkandurusoy, for the ping. You’re 100% correct, Session is used just for backwards compatibility. For React, it’s no problem to pass a
LANG prop all the way down your component tree, but as a convenience, we’ll use the current locale if this is missing and update when it’s changed.
There are a lot of solutions for i18n, and I think everyone will always have their preference. The goal for meteor-messageformat was to be an “all-in-one” solution, where we handle everything for you; extraction of text keys automatically from your files on save, storing of user locale preference, transport of updated strings to the client, a web UI for (crowd) translation, rendering-framework integration, etc. But it’s not for everyone. And as always, my customary no ETA for the final v2.0 release even though a lot of people have been using the preview for almost a year now