feat: add basic module locale merging

[BobbieGoede]

🔗 Linked issue

#1942

❓ 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

Allows modules to provide locales in a similar way to layers (#1925), as a potential replacement for i18n:extend-messages hook.

Current usage is using a hook to register your module with its i18n configuration, similar to configuring lazy-load locales. Other locale configuration have not been implemented yet. If a different approach is preferred please let me know!

export default defineNuxtModule({
  async setup(options, nuxt) {
    const { resolve } = createResolver(import.meta.url)
    nuxt.hook('i18n:registerModule', registerI18nModule => {
      registerI18nModule({
        langDir: resolve('./locales'),
        locales: [
          {
            code: 'en',
            iso: 'en-US',
            file: 'en.json',
            name: 'English'
          },
          {
            code: 'fr',
            iso: 'fr-FR',
            file: 'fr.json',
            name: 'Francais'
          },
          {
            code: 'nl',
            iso: 'nl-NL',
            file: 'nl.json',
            name: 'Nederlands'
          }
        ]
      })
    })
  }
})

This PR is still a work in progress, implementation will be more generic to prevent code duplication as it has in its current state. I will add tests and docs later if it's clear that we want this functionality to be added and the usage is agreed on.

📝 Checklist

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

[kazupon]

This is great PR! ❤️

We can replace the i18n:extend-messages hook.
The problem of i18n:extend-messages hook is that at nuxt build-time, object locale is pre-compiled to javascript, so that vue-i18n can handle it. And then pass it to template (i18n options.mjs) in gen.ts.
This was javascript to javascript and unsafe. And if the locale object was huge, i18n options.mjs was huge too.

This PR solves these problems by lazy loading of the locale on runtime builds and Nuxt layers.
We can deprecated the i18n:extend-messages hook.

[BobbieGoede]

@kazupon I added some documentation as well as a basic test and I haven't touched the i18n:extend-messages hook to keep this PR from breaking existing functionality, so deprecation can be done in a separate PR.

The i18n:registerModule hook implementation only supports adding lazy-load translations (locales: LocaleObject[]), I feel that adding support for strings only (locales: ['en', 'fr']) wouldn't make sense as no messages would be added but I can add it if needed.

[kazupon]

@BobbieGoede
Thank you very much!
Great job!

I haven't touched the i18n:extend-messages hook to keep this PR from breaking existing functionality, so deprecation can be done in a separate PR.

I will write the documentation for i18n:extend-messages deprecation/

The i18n:registerModule hook implementation only supports adding lazy-load translations (locales: LocaleObject[]), I feel that adding support for strings only (locales: ['en', 'fr']) wouldn't make sense as no messages would be added but I can add it if needed.

Yes! locales: LocaleObject[] only is enough! locales: string[] makes no sense at all.