Update "lazy" loading API

Is your feature request related to a problem? Please describe.

I’m using a translation platform Phrase (something like POEditor). They provide “lots of” methods to receive translation files. But none of these methods seems to fit well with vue-i18n or i18n-module. Currently my favorite is vue-cli-plugin-i18n. You just yarn download-translations into a single folder before generating a project.

tl;dr:

1. I don’t have a list of locales (because I receive it from API).
2. I don’t have the files (because I receive them from API) (and it would be nice to cache them, because translators keep translating them).

Describe the solution you’d like

options.lazy (or some other new method like translations) should accept a string or async function:

const options = {

  // /locales contain `locale.(json|js)` translation files
  translations: `/locales`,

  // API (request handled by module)
  translations: locale => `https://translations.server/api/client_id/project_id/${locale}`,

  // custom request handling (some people might need custom headers)
  translations: async (locale) => axios(`https://translations.server/api/client_id/project_id/${locale}`).data
}

options.locales should be an optional list of locale Strings or async function:

const options = {

  locales: ['en', 'fr', 'es'],

  // API
  locales: async () => axios(`https://translations.server/api/client_id/project_id/locales-list`).data,

  // maybe we can infer locales from `translations` folder? Just like vue-cli plugin?
  locales: undefined
}

We might also need some mechanism to cache/invalidate locale list.

Describe alternatives you’ve considered

• Node scripts
• i18next
• Using vue-i18n with plugin that I wrote 2 year ago for custom project
• CI/CD with ENV tricks

[rchl]

i.e. no-prefix route.

We could generate just one extra route with the dynamic locale prefix and leave the existing, unprefixed untouched. So there would be just one extra route per route for all locales, rather than one extra route for each locale.

It also brings me to another tricky question. Which is translated routes.

Handling those dynamically sounds too crazy to me so I guess those could only be added at build time.

[rchl]

Thank you for reminding me! I totally forgot about “route generation”. I wanted to ask: Why are you generating routes for locales instead of generating dynamic route “_locale”?

I’m not sure. It was done like that when I’ve inherited this module. I suppose doing a dynamic locale would pose some challenges. At least locale validation would have to be done on the code level rather than relying on VueRouter validating it now. But it would have the benefit of generating fewer routes which would be good for performance.