refactor!: read vue-i18n options from config path #1948

ineshbose · 2023-03-22T00:47:01Z

Note: Possibly being chased/continued in #1973

❓ Type of change

📖 Documentation (updates to the documentation or readme)
🐞 Bug fix (a non-breaking change that fixes an issue)
👌 Enhancement (improving an existing functionality like performance)
✨ New feature (a non-breaking change that adds functionality)
⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

Options would need to be passed from a separate file that will be imported by the plugin. This idea is inspired from looking at other modules that require runtime configuration. Please feel free to discuss over Discord about this change.

WORK IN PROGRESS

📝 Checklist

I have linked an issue or discussion.
I have updated the documentation accordingly.

… 'next' of https://github.com/nuxt-modules/i18n into next

ineshbose · 2023-03-22T00:56:57Z

@ kazupon, please feel free to share thoughts at your convenience. I expect the change to be slightly big in certain areas but I'll only finalise things after the previously proposed PRs have been tackled.

Btw, should the default config file be named i18n.config you think? (it follows *.config convention, is shorter than vue-i18n.{config,options} and it's also what I'm using in my personal Nuxt project) It would be customisable regardless - your call 🙂

kazupon · 2023-03-22T10:16:52Z

should the default config file be named i18n.config you think?

Yeah! your idea sounds good.

kazupon · 2023-03-22T10:23:25Z

src/types.ts

-  vueI18n?: I18nOptions | string
+  vueI18n?: {
+    configFile?: string
+  }


I hope the i18n options keep I18nOptions | string because it would break compatibility with v7.

It would need to be string for this change. Sorry if I'm misunderstanding but why is compatibility with v7 important (since this is another major version)?

Indeed, v8 is a major version, so breaking changes are inevitable.
Upgrading to a major version for a large application that has already been built is a huge effort.

Some frameworks (e.g. larave, rails, and react) have been released so that major versions do not cause too much work for the user's application. They are releasing features supported in previous versions in working order, just as Vue3 supports the Options API.

I have once again thought about how much breaking change would detract from the migration experience for the user.

In this PR, it is a change in the configuration interface, so the affected code point is local.
Changing the vueI18n option would not be much of a problem.
Of course, we need to write a migration guide in the documentation.

Absolutely - it would be great to have as less breaking changes as possible.

Similar to #1919 also moving some fragile configuration options to other solutions that Nuxt provides for stability, I'm aiming to do the same here. This may have been a small weak-point in v7, so having this solved in v8 would be great. The migration would indeed be documented.

ineshbose · 2023-03-22T12:36:41Z

PR would also possibly tackle this-

i18n/TODO.md

Line 9 in 7943ca1

    
           - [ ] resolve i18n options of nuxt.config with `useRuntimeConfig`, not `i18n.options.mjs`

kazupon · 2023-03-23T06:10:08Z

Could you prioritize this PR over other tasks? 🙏
I hope to release an RC version soon, and I want this to be the last opportunity involving breaking changes before that release.

…-options

kazupon · 2023-03-24T02:38:51Z

docs/content/1.getting-started/2.basic-usage.md

    }
  }
 })
 ```

-The `vueI18n` option is the same as `createI18n` function option of Vue I18n. `vueI18n` option is passed to the `createI18n` function via the nuxt plugin of this module internally.
+The `defineI18nConfig` function is the same as `createI18n` function option of Vue I18n. The configuration is passed to the `createI18n` function via the nuxt plugin (runtime) of this module internally.


I think we should name defineIVue18nConfig, not defineI18nConfig, because that is coniguration forvueI18n option. And some people might misunderstand it as a nuxt i18n setting.

kazupon · 2023-03-24T02:42:19Z

docs/content/3.options/1.vue-i18n.md

+    '@nuxtjs/i18n'
+  ],
+  i18n: {
+    vueI18n: { configPath: './nuxt-i18n.js' } // custom path example


The vueI18n option may no longer be optional. It's recommended to autoload i18n.config.ts if we have a config that conforms to the convention. If we have a nonconventional config file name, we can specify it in the vueI18n option!

ah, sorry, Never mind this comment.
I was misreading. 😅

kazupon · 2023-03-24T02:46:01Z

In additions, we also need to fix the basic usage docs.
https://v8.i18n.nuxtjs.org/getting-started/basic-usage#translate-with-vue-i18n

ineshbose · 2023-03-24T12:51:45Z

Hi @kazupon

I wanted to formalise the context to this PR with complete transparency so that everyone is on the same page!

This module provides enabling vue-i18n with Nuxt 3 and SSR. On further deep-diving into the code of this repository and intlify packages, I realised that there is a lot of code-generation work happening (from JavaScript to JavaScript) which has a reputation of not being the most stable or reliable, so I'm looking for ways around it. Since I'm not an expert in i18n solutions, I cannot comment on the requirement for this. Nuxt 3 also involves a level of code generation through addTemplate, etc, and I have been using these functionalities for a while now to gain a better understanding; I've learnt that code generation should be minimum but also functions shouldn't be serialized (hence #1919 was also made). vue-i18n is excellent for internationalization and it provides modifiers that are passed as functions. From previous versions of this module, vueI18n is the configuration option for it, and then it gets serialized using code generation - but that has the limitations of manual code generation including understandability of code, efficiency and stability.

Based on Nuxt's official guide on a project's contexts - "they are not supposed to share state, code, or context" (also why nuxt.config.ts and app.config.ts are different and declared differently, why plugins and modules are different and declared differently, why app hooks and nuxt hooks are different and declared differently) - since vue-i18n is on the runtime context as a plugin, the configuration shouldn't be in nuxt.config.ts (build context) so that would greatly help with ensuring that developers are aware of the different contexts (as Nuxt aims to help with) and more importantly - code-generation since we don't have to take the build-time configuration to build/serialize it into runtime configuration as discouraged by the guide. Instead, since the configuration is now different, in a different file, it could just be imported in runtime. A great example of this is the FormKit module that only takes in configuration path to create the runtime plugin (docs) - so that is a point of inspiration.

With all that said, this is a massive change that will need to be tested intensively, and for me, as an amateur, to carry this out since I only have such little understanding of how the module and code generation is working, I will need some great help and great guidance. I can't say what steps to take forward, but I'm looking to hear from the lead developer (aka you 😄) if have some plans or feedback on how this can be facilitated or just cancelled (which I'm open to, but I believe it would continue with the code debt). Let me know - and we can continue a close discussion over Discord if required. 🙂

kazupon · 2023-03-25T16:42:51Z

Hi! @ineshbose
Thank you for your detailed and clear explanation!!

I was understanding the current problems with the vueI18n option and that it does not follow the Nuxt development conventions 😅
vueI18n option is not code generated by gen.ts, but by using addPluginTemplate and import in that template.
It's better to use addPluginTemplate, as it will be safely handled by the Nuxt plugin.

The implementation using addPluginTemplate needs huge refactoring in runtime/i18n.ts and gen.ts.
I think that this refactoring would delay the release.

So, I have considered whether there is any compromise for the RC release.

Fortunately, vueI18n option, when a path is specified as a string, the code generated in i18n.options.mjs reads the file specified in the path with dynamic import.

The loaded file is processed by the bundler (vite), so that even if functions such as modifiers are set, they can be safely processed.

i18n.config can be solved with module.ts, so all you have to do is specify the path, and the impact cost is low.

If vueI18n option is set with Object, it will output a warning to set it with i18n.config, when nuxi dev.

In the RC release, we can accept configuration by Object, but in the v8 official release or RC patch version release, we will discontinue that support and vueI18n option will only accept path configuration.

That way, I believe we can make changes to vueI18n option progressive without forcing the community to wait for RC release.
We can refactor for vueI18n option using addPluginTemplate until v8 official release.

What do you think?

ineshbose added 3 commits March 13, 2023 17:05

docs: mention callbacks

baab8be

Merge branch 'next' of https://github.com/ineshbose/nuxt-i18n; branch…

969e60d

… 'next' of https://github.com/nuxt-modules/i18n into next

chore: initial commit

e380f08

ineshbose self-assigned this Mar 22, 2023

ineshbose added WIP v8 labels Mar 22, 2023

kazupon reviewed Mar 22, 2023

View reviewed changes

ineshbose added 2 commits March 23, 2023 09:02

Merge branch 'next' of https://github.com/nuxt-modules/i18n into i18n…

8acf162

…-options

chore: progress

56ad478

ineshbose added the ❗ p4-important Priority 4: bugs that violate documented behavior, or significantly impact perf label Mar 23, 2023

kazupon reviewed Mar 24, 2023

View reviewed changes

chore: updating minor bits and tests

9da8fe7

kazupon mentioned this pull request Apr 2, 2023

refactor!: vueI18n options from config path #1973

Merged

7 tasks

ineshbose added stale and removed ❗ p4-important Priority 4: bugs that violate documented behavior, or significantly impact perf labels Apr 3, 2023

kazupon closed this in #1973 Apr 12, 2023

BobbieGoede mentioned this pull request Feb 3, 2024

Add fallbackLocale to nuxt.config options #2753

Open

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

refactor!: read vue-i18n options from config path #1948

refactor!: read vue-i18n options from config path #1948

ineshbose commented Mar 22, 2023 •

edited

ineshbose commented Mar 22, 2023

kazupon commented Mar 22, 2023

kazupon Mar 22, 2023

ineshbose Mar 22, 2023

kazupon Mar 22, 2023

ineshbose Mar 22, 2023

ineshbose commented Mar 22, 2023

kazupon commented Mar 23, 2023

kazupon Mar 24, 2023

kazupon Mar 24, 2023 •

edited

kazupon Mar 24, 2023 •

edited

kazupon commented Mar 24, 2023

ineshbose commented Mar 24, 2023

kazupon commented Mar 25, 2023

refactor!: read vue-i18n options from config path #1948

refactor!: read vue-i18n options from config path #1948

Conversation

ineshbose commented Mar 22, 2023 • edited

❓ Type of change

📚 Description

📝 Checklist

ineshbose commented Mar 22, 2023

kazupon commented Mar 22, 2023

kazupon Mar 22, 2023

Choose a reason for hiding this comment

ineshbose Mar 22, 2023

Choose a reason for hiding this comment

kazupon Mar 22, 2023

Choose a reason for hiding this comment

ineshbose Mar 22, 2023

Choose a reason for hiding this comment

ineshbose commented Mar 22, 2023

kazupon commented Mar 23, 2023

kazupon Mar 24, 2023

Choose a reason for hiding this comment

kazupon Mar 24, 2023 • edited

Choose a reason for hiding this comment

kazupon Mar 24, 2023 • edited

Choose a reason for hiding this comment

kazupon commented Mar 24, 2023

ineshbose commented Mar 24, 2023

kazupon commented Mar 25, 2023

ineshbose commented Mar 22, 2023 •

edited

kazupon Mar 24, 2023 •

edited

kazupon Mar 24, 2023 •

edited