Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange warning messages 'Value of key '<<message>>' is not a string!' #201

Closed
matuscongrady opened this issue Jul 30, 2017 · 6 comments
Closed

Comments

@matuscongrady
Copy link

Vue version: 2.4.2
vue-i18n version: 7.0.5

Hello,

I'm using both global messages
const i18n = new VueI18n({ locale: getCurrentUserLanguage(), messages });
and local, component based messages:

i18n: {
    messages: {
      en: { msg: 'msg' },
      sk: { msg: 'msg' }
    }
  }

Everything works as expected.
But when I access global messages in the component that does have local, component-based messages, I get following warning:
image

I really don't like having bloated console, just to inform me about using fallback to global-translation.
And the warning message is kind of misleading.

Am I doing something wrong? If not, please consider removing this warning message for this particular use-case.

Thanks!

@kazupon
Copy link
Owner

kazupon commented Aug 1, 2017

You can avoid with silentTranslationWarn.
https://kazupon.github.io/vue-i18n/en/api.html#vuei18n-class#silenttranslationwarn

@kazupon kazupon closed this as completed Aug 1, 2017
@roelvan
Copy link

roelvan commented May 2, 2018

Yep I added this:

export default new VueI18n({
  locale: 'en',
  silentTranslationWarn: process.env.NODE_ENV === 'production'
})

@chatondearu
Copy link

Maybe it's a good point to add this use case in the documentation for Component based localization

@kissu
Copy link

kissu commented Aug 14, 2018

Here is the updated link for the specific option above.

@Fusseldieb
Copy link

Fusseldieb commented Jun 24, 2019

That seems to work, but it's a workaround, because it also silences real errros, I believe. This becomes an issue particularly when actively debugging, when these "errors" mix with real translation errors and you lose sight.

Is it wrong to access global translation on a Component based approach? If so, why?

@kevinmarrec
Copy link
Contributor

Since 8.8 there is a silentFallbackWarn option that should better fit for people using Component based localization.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants