Multiple namespaces not rendering on client.

I have my common.json file being pulled into Jade template files which are working fine, but I can add another namespace and have it work correctly, it keeps getting overwritten, and the resources is not added within the window.__i18n object.

Here’s my i18n-server.js

import i18n from 'i18next'
import Backend from 'i18next-node-fs-backend'
import { LanguageDetector } from 'i18next-express-middleware'

i18n
  .use(Backend)
  .use(LanguageDetector)
  .init({
    whitelist: ['en'],
    fallbackLng: 'en',

    // have a common namespace used around the full app
    ns: [
      'common',
      'homepage'
    ],
    defaultNS: 'common',

    debug: true,

    interpolation: {
      escapeValue: false // not needed for react!!
    },

    backend: {
      loadPath: 'locales/{{lng}}/{{ns}}.json',
      jsonIndent: 2
    }
  })

export default i18n

and the i18n-client.js

import i18n from 'i18next'

i18n
  .init({
    whitelist: ['en'],
    fallbackLng: 'en',

    // have a common namespace used around the full app
    ns: [
      'common',
      'homepage'
    ],
    defaultNS: 'common',

    interpolation: {
      escapeValue: false // not needed for react!!
    }
  })

export default i18n

I also have this within my client.js file

i18n.changeLanguage(window.__i18n.locale)
i18n.addResourceBundle(window.__i18n.locale, 'common', window.__i18n.resources, true)

ReactDOM.render(
  <I18nextProvider i18n={i18n}>
    <Router history={browserHistory}>
      { Routes }
    </Router>
  </I18nextProvider>,
  document.getElementById('app-container')
)

And this is my server.js file

  const locale = req.language
  const resources = i18n.getResourceBundle(locale, 'common')
  const i18nClient = {locale, resources}

  const i18nServer = i18n.cloneInstance()
  i18nServer.changeLanguage(locale)

And i18n is picking up my homepage.json file and it renders in the jade file (as =t('homepage:test.title') at first but then gets overwritten because it’s not in the window.__i18n resources. What am I missing!

[davidfurlong]

@tricoder42 Yes, so I wrote a little (very naive) way of doing that isn’t good enough (https://github.com/davidfurlong/react-local-translations) - as I was trying to avoid having to add more API surface area on my react code. But I am totally on board with what you are saying.

If local CSS is a good idea, then surely so is local translation files. Ofcourse having a build process to unify them would be useful for handing to translators (this is a pain with local translations), but it also means that you can add / remove components really quickly and not worry about global namespace. It also solves the issue of having huge translation files being loaded into your bundle. I tried using this repo and (without benchmarking) I could see a noticeable performance hit, so I’m trying to keep what I build minimal (for the vast majority of translations, things like pluralization or other helper utilities aren’t needed).

I’m about to start writing a basic version of this, and I think it’ll be pretty quick. But I’m still uncertain of what i18n library to use

[jamuhl]

closing this as i expect it to be solved - otherwise feel free to reopen.