react-i18next: 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!
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 19 (9 by maintainers)
@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
closing this as i expect it to be solved - otherwise feel free to reopen.