Question: Is it possible to lazy-load a language namespace on first use?

[mjmasn]

Given:

# en-translation.json
{
    "some": {
        "key": "Some string in English"
    }    
}
# fr-translation.json
{
    "some": {
        "key": "Some string in French"
    }    
}

If I init i18next with lng:'en', I would expect that calling t('some.key', {lng:'fr'}) would automatically attempt to load the relevant 'fr' translations (assuming i18next knows the possible languages - e.g. by setting whitelist: ['en','fr']). However it just returns the english translation. Is there any way to do this automatically? I can just use preload or call loadLanguages when required but would rather not load all namespaces for all languages on the client.

[jamuhl]

the problem here is it is only possible when you can load the files in a synchronous way as calling t returns the translation. v1 of i18next had that option but as browsers started to warn about doing synchronous xhr calls that option got dropped.

to optimize your case - if you're using the xhr-backend:

• call i18next.backend.read directly with fr, namespace, callback(err, data) https://github.com/i18next/i18next-xhr-backend/blob/master/src/index.js#L90
• append the data to resourceStore via i18next.addResourceBundle http://i18next.com/docs/api/#add-resource-bundle

so at least you don't have to load every namespace for the one key you need in fixed language t('some.key', {lng:'fr'})

May i ask your usecase? why you need to display one part in fr while user language is en?

[mjmasn]

That makes perfect sense. I was just vaguely thinking about possibilities for a translation interface I'm building but hadn't really considered it would require sync XHR which I knew had been removed in v2. I think preload will be fine for our use case, the part that needs multiple languages isn't customer facing so I don't care too much about initial load time.

Thanks for taking the time to explain, useful to know about i8next.backend.read too! As a side note v2 is working really nicely with MeteorJS on both client and server. Doesn't quite work with React out of the box but I think this will be resolved in Meteor 1.3 which has proper NPM/modules support and React will be loaded via NPM. Replacing the require('react') statements with the global React variable seemed to fix it for now in case any other Meteor users are having issues...

[jamuhl]

hi @mjmasn can you provide more details on what you plan to build? jan.muehlemann@gmail.com

i'm very interested on that because we plan ourself to create some translation interface for a 'translation as a service' platform for i18next using companies.

[mjmasn]

@jamuhl sure, should have some time over the weekend :)