For Meteor+Blaze I’m using anti:i18n, awesome package
In templates - {{i18n "some.label"}}
In JS - i18n('some.label')
And when I need change locale, just simple line in onClick event: i18n.setLanguage(language). And everything magically changing! (-:
How do you localize your React/Redux apps? Is there a simple and elegant way, like anti:i18n, for React?
Not sure how helpful these are to you but worth a look all the same. To add one of them to your meteor app, you run (as an example): meteor npm install i18n-react --save
Messageformat uses Session, I think, react-i18nify - not. I try to avoid using Session, if I use React, only React-style.
But messageformat - awesome package.
Well it does not rely on Session, but it does provide a backwards compatibility fallback for older clients who use session to track the current locale. But @gadicc would know better.
Other than that, and being a “react-only” solution, do you find a specific feature or syntax that react-i18nify provides you that messageformat lacks?
PS: I’m not a messageformat contributor/advocate and in fact trying to expand my react toolbelt with an i18n solution. I was eyeing messageformat because it can be used in both blaze and react, which I find to be an advantage. I am trying to benfit from your experience
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
Yeah, I’m excited about the prospects of moving to the greater node ecosystem. This is the reason why I posted recently that we’re going to stop releasing updates for Meteor < 1.3 later this year, so we can rely on ES6 and npm! Exciting times
Yeah I know It’s still a pre-release. Docs are actually next on my list if I’m not mistaken. But everything in the READMEs from the v2 branch supersede the docs on the site. So you can uninstall the meteor-messageformat npm package, and there’s no more mf_extract, it’s automatic now on each meteor run and every file save.
Ok so the main react helper is the <MF> component. For what you’re describing, you’d use the regular JS function. e.g.
OK (-:
About mf() I understood from docs. But in my case I need Ukrainian and Russian translation… Where these translations?! Where I should place them and how to load them?? It’s not clear in docs (-:
You can add meteor add msgfmt:ui@2.0.0-preview.11 and just go to /translate in your app, there’s a web UI to do the translation (like this one).
It currently supports iron-router and flow-router. If you’re using react-router, you might have to open an issue for us to figure out the best way to do this, or maybe in https://github.com/nicolaslopezj/meteor-router-layer/ since this is what we use for router agnosticism).