i18n and Mantra

[Billybobbonnet]

Since Mantra is supposed to be an architecture suited for large project, I miss a clear guideline on i18n integration. It has been mentioned in 2 issues (#44 and #102) but it does not answer to common/general questions people could have:

• What should be the preferred i18n component (npm like i18next or TAP:i18n package or ...)
• What should be the best approach to handle it in components (and keep the reactivity):
  • use a common composer (afaik react-komposer have no built-in "common" composer) to share context between component and container
  • pass the context to every component
  • pass the fields content to every component
  • import it directly in every component
• How should the language files be organized (and loaded): one per module or one for all the app?

[arunoda]

This is a very valid question. I like to start a chapter on the spec. But, I'm quite not sure how to do it since specially I haven't worked with i18n based apps.

Looking for some ideas for this. But, we should not break our core principles unless if there's a real reason.

So, this is how I think about this.

• Mantra is only for client side apps, so do we need to ship all language files to client? (I assume we should not)
• Also, I think i18n doesn't need to be reactive
• It it's not, we can simply import a module from the component and use it. Here's an example.

import {T} from 'my-i18n';
import React from 'react';

const MyClass = () => (
  <div>{T('some-text-here')}</div>
);

Then we can configure this my-18n module even before we load Mantra. So, we can configure them in a the route.

import {setLang} from 'my-i18n';
FlowRouter('/:lang/:page', function(params) {
   setLang(params.lang);
  //  ... other FR stuff
});

[Billybobbonnet]

Mantra is only for client side apps, so do we need to ship all language files to client? (I assume we should not)

This point is definitely a must.

Concerning the reactivity, it allows to avoid relying on the router to change the UI language. I would say it is a good thing. What would be great would be to set a Locale field in the LocaleState reactive-dict and refresh all the i18n values once the language file has been downloaded.

The package universe:i18n should allow this but I can't get the other files (besides English) : basically, it inserts a script node in the document head, expecting the translation to be somewhere in the public folder. As far as I can tell, it is not working. Also note the use of a refresh mixin to update React component when locale is changed.

[smeijer]

As we now have access to the npm registry. Is there not a big "standard" node library that we can use for this? Would be great to not depend on a meteor package for this. And it would be a great thing if all mantra fanatics were using the same i18n "standard". So npm install your-module results in a already translated module which plays nicely with my-module and their-modules.

[Billybobbonnet]

i18next would be my first choice, as npm package (I did a bit of naive research). It has a plugin system but out of the box, it is not something you can use with meteor (e.g. xhr requests to load new language files, by plugin). It would require an integration effort, what most of i18n package basically did.

That would be great to have a i18next plugin for meteor in mantra flavour, a package or a wrapper npm, but to be honest, I feel that it's out of my league and I don't have enough time to make it.

[arunoda]

Currently, we are moving our issues to Mantra Talk. So, we found a really good question about i18n and a potential solution.

Have a look at it here.