No More Posting New Topics!

If you have a question or an issue, please start a thread in our Github Discussions Forum.
This forum is closed for new threads/ topics.

Navigation

    Quasar Framework

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search

    can't get vue-i18n initialised properly

    Help
    7
    25
    6835
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • ssuess
      ssuess last edited by

      I have also tried to setup SFC translation blocks as detailed here: https://quasar.dev/options/app-internationalization#Setting-up-Translation-Blocks-in-your-SFCs and here: https://kazupon.github.io/vue-i18n/guide/sfc.html#single-file-components

      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.

      1 Reply Last reply Reply Quote 0
      • ssuess
        ssuess last edited by ssuess

        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'
                cfg.module.rules.push({
                  enforce: 'pre',
                  test: /\.(js|vue)$/,
                  loader: 'eslint-loader',
                  exclude: /node_modules/
                }),
                cfg.module.rules.push({
                  resourceQuery: /blockType=i18n/,
                  use: [
                    {loader: '@kazupon/vue-i18n-loader'}
                  ]
                })
              }
            }
        
        1 Reply Last reply Reply Quote 0
        • ssuess
          ssuess last edited by

          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

          1 Reply Last reply Reply Quote 0
          • s.molinari
            s.molinari last edited by

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

            Did you see and follow this article? https://medium.com/quasar-framework/adding-full-i18n-to-quasar-150da2d5bba4

            Scott

            stukki 1 Reply Last reply Reply Quote 0
            • ssuess
              ssuess last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • s.molinari
                s.molinari last edited by s.molinari

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

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

                Scott

                1 Reply Last reply Reply Quote 0
                • ssuess
                  ssuess last edited by ssuess

                  @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!

                  1 Reply Last reply Reply Quote 0
                  • ssuess
                    ssuess last edited by

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

                    1 Reply Last reply Reply Quote 0
                    • s.molinari
                      s.molinari last edited by

                      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.

                      Scott

                      1 Reply Last reply Reply Quote 0
                      • stukki
                        stukki @s.molinari last edited by

                        @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 }) => {
                          Vue.use(VueI18n)
                          app.i18n = new VueI18n({
                            locale: 'en-us',
                            fallbackLocale: 'en-us',
                            messages
                          })
                          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?

                        1 Reply Last reply Reply Quote 0
                        • s.molinari
                          s.molinari last edited by

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

                          Scott

                          stukki 1 Reply Last reply Reply Quote 0
                          • stukki
                            stukki @s.molinari last edited by

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

                            import i18n from 'boot/i18n.js'
                            ...
                            
                            i18n.t('translation.path')
                            

                            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

                            1 Reply Last reply Reply Quote 0
                            • ssuess
                              ssuess last edited by ssuess

                              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.

                              1 Reply Last reply Reply Quote 0
                              • First post
                                Last post