extend locale lazy-loading

[kazupon]

Describe the feature

describe

Currently, lazy-loading loads the locale messages specified in the i18n.locales file.

BCP47 supports language tags such as language - script - region - variant - extension - privateuse.
https://en.wikipedia.org/wiki/IETF_language_tag

If you define locale messages as resources in a file according to that specification, there is a possibility of duplication.
For example, en-US and en-GB have the same language, just different regions.
In that case, most resources would be the same.

For convenience in managing resources for locale messages, it would be useful to have a mechanism to define resources only for the difference of region and variant and to be able to load them lazily.

usecase projects

elk-zone/elk#1172

more details for this feature request

https://discord.com/channels/1044887051155292200/1045783579520684062/1063952424764719154

Additional information

• Would you be willing to help implement this feature?
• Could this feature be implemented as a module?

Final checks

• Read the contribution guide (The contribution guideline of nuxt-modules/i18n is compliant with Nuxt too).
• Check existing discussions and issues.

[userquin]

The main problem is the locale (we need it, we cannot use a generic locale), I mean, the html lang tag and Intl usage, just a few examples:

• in Colombia datetime format is AM/PM, in Spain we use HH24
• First day of week in Argentina is Sunday while in Spain it is Monday
• arabic languages: we cannot use ar, we lost numbers

About messages duplication: favorite and favourites for en-US and en-GB respectivelly.

[kazupon]

in Colombia datetime format is AM/PM, in Spain we use HH24
First day of week in Argentina is Sunday while in Spain it is Monday

I think we can configure those to vueI18n.datetimeFormats. does this mean we want to lazily load datetimeForamts as well as locale messages?

arabic languages: we cannot use ar, we lost numbers

for arabic, sorry, I’m not familiar with that language. sorry, could you please give me some more detail explanation? 🙏

[userquin]

My previous comment was just to justify the PR.

Just check i18n module https://github.com/elk-zone/elk/blob/main/config/i18n.ts: rn we're using only es-ES for all spanish variants, and that's wrong, for example we're using datetimes and ppl using Elk from countries using AM/PM will end up with HH24.

About arabic, check the script we've in Elk contributing.md file, if we use ar for generic arabic (that's why we're using ar-EG), Intl will use latin numbers, and so arabic numbers will never be used.

[userquin]

[1, 12, 123, 1234, 12345, 123456, 1234567].forEach((n) => {
  const acc = {}

  Array.from(['ar-EG', 'ar']).forEach((l) => {
    const nf = new Intl.NumberFormat(l, {
      style: 'decimal',
      maximumFractionDigits: 0,
    })
    const nf2 = new Intl.NumberFormat(l, {
      notation: 'compact',
      compactDisplay: 'short',
      maximumFractionDigits: 1,
    })
    acc[l] = {
      number: n,
      format: nf.format(n),
      compact: nf2.format(n),
    }
  })
  console.table(acc)
})

[kazupon]

Thanks! I appreciate your kindful explanation.

I’m working at #1801.
Could that PR meet your expectations?

[userquin]

Could that PR meet your expectations?

The only thing I need confirmation is that a module is generated per language with the overwritten messages: for Spanish surely there will not be too many messages to overwrite, but for other languages (Arabic) surely yes

[kazupon]

I need confirmation is that a module is generated per language with the overwritten messages

In That PR, it's generated by the bundler (vite) for per language.
I will merge the PR and release beta.8
when you would try that version, if you need any more support, you would give me feedback!

[userquin]

I will merge the PR and release beta.8

Thx man: we've also some problems with i18n module and ts types overriden #1711 (should also be included in the new beta 8?)