vue 2.0.0.rc3
vue-i18n 4.3.1
vue-loader 9.4.0
vue-router 2.0.0-rc.3
I updated a project to vue 2, and now most of the translated strings don't display when the component loads for the first time. It makes an error
[vue-i18n] Cannot translate the value of keypath " ". Use the value of keypath as default.
When the component is re-used, the translated string appears.
this is like the page loads before the translated string is parsed.
In webpack.config.js, add such alias setting.
resolve: {
alias: {
'vue': 'vue/dist/vue.js'
}
},
And import Vue 2.0 from 'vue', do not use 'vue/dist/vue'.
import Vue from 'vue'
Then restart dev server, everything works.
If vue-router 2.0 is used, the alias setting is necessary.
vue-i18n is OK, but vue-router sucks.
vuex 2.0 have the same problem too.
It seems I get the same problem.
I have this problem too.
{
"vue": "2.0.0-rc.8",
"vue-resource": "1.0.3",
"vue-router": "^2.0.0-rc.7"
}
https://github.com/erguotou520/dashboard
index.js:3 Uncaught TypeError: Cannot read property 'indexPath' of undefinedIt seems that reproduce only on windows, my Mac don't shows any error, need to confirm on windows again.
@erguotou520
Thank you for your feedback. :)
@francoisromain I have the same problem . I agree with "this is like the page loads before the translated string is parsed."
when i open the module , the translated string appears at once , but there is some warnings in the console.
is there a method to solve this problem or just don't care?
I'm getting the same warning using Vue 2.0 on a Laravel application and none of the localized strings are displayed...
I'm also using laravel-vue-i18n-generator plugin to get Laravel translation files formatted.
Hello,
It seems that I have the same issue here. The translation is loaded via an API and I can see in logs that the vue components are parsed before the translation, so that's why it generates these warnings.
Once the translation is loaded and the Vue.config.lang set, then correct translations are displayed.
"vue": "^2.0.1",
"vue-i18n": "^4.10.0",
"vue-resource": "^1.0.3",
"vue-router": "^2.0.3",
"vuex": "^2.0.0"
Vue.locale(lang, function () {
return new Promise((resolve, reject) => {
// Fetch online translations
Vue.http.get(endpoint + 'translation/florapos/' + lang).then(
(response) => {
if (response.body && response.body.hasOwnProperty(lang)) {
console.log('set locale', response.body)
// Return the locale json
resolve(response.body[lang])
Vue.config.lang = lang
}
else {
console.log('Locale ' + lang + ' is not available')
reject()
}
},
(response) => {
console.log('Error during the tranlation loading')
reject()
}
)
})
})
I make it happy by placing the language set codes into beforeCreate hook in your Vue obejct
I get the same error even if translations are included in the Vue app's assets, but ONLY if there are in the component scope (defined in 'i18n' key of component).
I just try the document code(http://kazupon.github.io/vue-i18n/en/started.html)
But Chrome show me warnning:
vue-i18n.esm.js?ac9a:14 [vue-i18n] Cannot translate the value of keypath 'message.hello'. Use the value of keypath as default.
"vue": "^2.4.2"
"vue-router": "^2.7.0"
"vuex": "^2.4.1"
"vue-i18n": "^7.3.1"
Getting the same issue here
This was my bad
I had
const i18n = new VueI18n({
locale: 'en', // set locale
translations // set locale messages
})
Instead of
const i18n = new VueI18n({
locale: 'en', // set locale
messages: translations // set locale messages
})
In case that our case could help to someone to solve the same problem.
We got this issue a few months ago and today I found the solution. In summary we have a medium size application which has a root locales passed to the VueI18n constructor with the property messages as commented in https://github.com/kazupon/vue-i18n/issues/49#issuecomment-337136653
We also have locales defined in the components which are children of the root component (called App component); at some point, we don't remember exactly in what change, we observed that the components failed to reference the root messages locales, though they referenced without any issue their local locales.
So basically we had a similar or the same problem expressed in some comments of this issue.
Several times, I checked the options properties, messages, fallbackRoot, etc., an even set different values in some of them (e.g. fallbackRoot), but I didn't solve the issue.
Today, just adding the @kazupon/vue-i18n-loader in order to be able to use the custom blocks and if for any chance, the problem could be fixed if we change our i18n component properties by the <i18n> blocks, I found the issue (maybe it's a workaround). The loader didn't solve the issue, so it doesn't matter if you use or not, but it led me to take a look to the example of setting and using the vue-i18n-loader https://github.com/kazupon/vue-i18n/tree/dev/examples/sfc
In that example I found that the App component is added to Vue as a result of the render function](https://github.com/kazupon/vue-i18n/blob/894be3677d2f39ac20d77b7078459399d3c319a4/examples/sfc/src/main.js#L18), so basically I swapped how we passed the App component which was, like
new Vue({
i18n,
el: '#app',
...App
})
by using the render function and the problem was gone.
Last but not least, I found that once I did that, I've seen that the missing handler was called for each component page (we use vue-router) at the first load with the {lang}.{pagename} (e.g. 'en.user) but, swappingfallbackRootfromtruetofalsethemissing` handler isn't called with those anymore.
Hello, @ifraixedes @kazupon I tried all, rendering with render callback, rewriting the code, clearing up the base and have the same problem as above. It always falls back to default language for some keys, its all random, no reason for it to not work. Any idea how to fix this? Thanks!
@CodeSkills I don't have it; this issue is very annoying and there is no reason as you stated, I found that what was exposed worked for us, but it was after a lot of back and forth changing things, etc.
In my opinion is an important issue, however it looks that the issue only exist for some not for all.
close due to in-activity
This was closed a while ago but I came upon this issue on my frontend setup and found an easy solve.
I lazy load my translations as described in the docs except I don't need a vue router, thus no beforeEach magic.
But if you take a look at the lazy load example, the language loading method can return a promise (because why not?)
I wait for the promise to resolve to instantiate my vue object.
(async function () {
await loadMessages(my_lazy_loaded_locale)
})().then(() => {
new Vue({
i18n: i18n,
...App
}).$mount('#app')
})
The loadMessages method is defined as follows:
const {locale} = window.config
const i18n = new VueI18n({
locale: locale,
fallbackLocale: locale,
messages: {}
})
export async function loadMessages () {
const messages = await import(/* webpackChunkName: "lang-[request]" */ `../lang/${locale}`)
i18n.setLocaleMessage(locale, messages)
return Promise.resolve(locale)
}
A big arigato for all the hard work, @kazupon!
闋戝嫉銇c仸銆併伃
if anyone ends up here again, my issue was that i was translating the key when sending it to a child component's prop, and then, when rendering that prop, i was calling the translation method once again, to a value that was already translated and, of course, had no key.
Most helpful comment
This was my bad
I had
Instead of