can't get vue-i18n initialised properly

  • I know this is quite old now, and perhaps things have changed, but I can’t get i18n working (outside of quasar’s built in translations which ARE working). Here is what I am doing:

    1. Using example here ( I can successfully set language for quasar
    2. Using example above as locales, and the same formatting I am successfully importing locales file with strings for my component
    3. I am then attempting to use one of these with {{ $t('langChoose') }} in my template, but it only outputs “langChoose”, not the locale string from my file for that variable.

    Can anyone tell me what I am doing wrong? In step two above I am running into an odd issue where I don’t get errors if I format like this:

    export default {
      es: {
        instructions: 'Elija sus preferencias de aplicación abajo',
        langChoose: 'Eliga idioma'
      en: {
        instructions: 'Please choose app prefs below',
        langChoose: 'Choose your language'

    But removing the export default results in a babel loader syntax error for some reason.

  • I have also tried to setup SFC translation blocks as detailed here: and here:

    Sadly, these do not work either. I have a test on one page where I am embedding a quasar language variable {{$q.lang.label.close}} and my own {{ $t('langChoose') }} side by side with a language switcher. The Quasar variable changes when I change the language, the i18n one does not, it only displays ‘langChoose’

    Does anyone have a working example of using this in one’s own component in a quasar project? I am sure I am not the first one to attempt this.

  • This is what the build section of my quasar.conf.js file looks like, do I need to add anything else?

    build: {
          scopeHoisting: true,
          // vueRouterMode: 'history',
          // vueCompiler: true,
          // gzip: true,
          // analyze: true,
          // extractCSS: false,
          extendWebpack (cfg) {
            cfg.resolve.alias['vue'] = 'vue/dist/vue.common'
              enforce: 'pre',
              test: /\.(js|vue)$/,
              loader: 'eslint-loader',
              exclude: /node_modules/
              resourceQuery: /blockType=i18n/,
              use: [
                {loader: '@kazupon/vue-i18n-loader'}

  • I am starting to think this must be a bug in Quasar, as I have followed all available instructions and still can’t get my strings to show up. If no one has any better suggestions, I guess I will report it as an issue over at github

  • @ssuess - Did you start your project with i18n selected during the creation process?

    Did you see and follow this article?


  • At a quick glance, my setup is almost identical to what you outline in the article except that I am trying to use language files per component (and import them there) instead of using a global one. And I think it is clear that the boot item etc is installed properly or quasar’s own i18n strings would not work either (or are you saying quasar’s locale string switching doesn’t rely on vue-i18n?). I will take a longer look at the article in few hours, perhaps there is something else that I am missing. Thank you very much for your reply and the link, I appreciate it.

  • or are you saying quasar’s locale string switching doesn’t rely on vue-i18n

    No. It doesn’t. It’s two separate systems. 🙂


  • @s-molinari Ok, so (finally) got a chance to look at your article, it seems that I have always had i18n setup correctly in my project. And when I added strings to src/i18n/en-us/index.js, they DO correctly show up. But that would mean that ALL of the components in my app must share this same language file, which I do not want to do. I want each component to have its own. Where these language files live is less important to me than that they are separate, but ideally they would live in something like src/i18n/ComponentName/en-us.js (es.js, de.js, etc) or src/i18n/en-us/ComponentName.js (etc). Any idea how to make this work? Thanks again for your help!

  • also your switching example says to set this.$q.i18n.set(lang.default) but the quasar docs (from here: use this: this.$q.lang.set(lang.default)…I assume the quasar docs are the most up to date?

  • Yes. Thanks for pointing that out. I’ve updated the article.

    As for the solution to separate the files, I’ve not looked into it, so can’t help much there. Sorry.


  • @s-molinari Thank for that article. Although i18n is working in my app I wanted to try your solution because I did not get i18n running in vuex.

    Unfortunately I run in an issue, maybe you can give me a hint what I’m doing wrong?

    In the boot file i18n.js I’ve omitted the curly braces in the 2nd import statement:

    import VueI18n from 'vue-i18n'
    import messages from 'src/i18n'
    let i18n
    export default ({ app, Vue }) => {
      app.i18n = new VueI18n({
        locale: 'en-us',
        fallbackLocale: 'en-us',
      i18n = app.i18n
    export { i18n }

    Because with the curly brace I get this error message in my console:
    2ff9c79b-bf6b-4c76-99f3-d5e34751704c-Screen Shot 2019-06-28 at 14.03.59.png ![alt text](image url)Screen Shot 2019-06-28 at 14.03.59.png

    When omitting the curly braces, the error message dissapears.

    The other issue is that when I import in vuex:

    import i18n from 'boot/i18n.js'

    (that’s from your post in medium)

    I get an error in the browser console:

    a850e744-700e-4665-a274-088193f2d982-Screen Shot 2019-06-28 at 14.01.46.png Screen Shot 2019-06-28 at 14.01.46.png

    The only thing I want to achieve is to use i18n in vuex.

    I hope someone has a solution?

  • Are you using just “t” or $t in your use of i18n in Vuex?


  • @s-molinari Many thanks for your quick reply.
    According to your medium-article I’ve used:

    import i18n from 'boot/i18n.js'

    Is it possible that the i18n-version affects the behavior ? Couple of weeks ago I’ve updated i18n to the current version but that broke my app, so I’ve downgraded i18n.

    That’s my current installation :

    c638d7ad-1de2-4492-9861-6a838dc6d168-Screen Shot 2019-06-29 at 07.43.03.png

    Screen Shot 2019-06-29 at 07.43.03.png

  • In case it helps someone else, I have found a way to keep my translation files separate on the backend but combine them for use in i18n as @s-molinari describes in his article. I simply add new files and then combine them before export in the i18n/index.js file, like so:

    import enUS from './en-us/index.json'
    import es from './es/index.json'
    import ar from './ar/index.json'
    import enUSstrings from './en-us/strings.json'
    import esstrings from './es/strings.json'
    import arstrings from './ar/strings.json'
    const enUSCombined = Object.assign({}, enUS, enUSstrings)
    const esCombined = Object.assign({}, es, esstrings)
    const arCombined = Object.assign({}, ar, arstrings)
    export default {
      'en-us': enUSCombined,
      'es': esCombined,
      'ar': arCombined

    And voila! Now I can keep the actual translations modular while still using them in language switching anywhere in my app.

Log in to reply