Provide a way to consume locales from outside the filesystem

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

At the company I’m working for, we use next.js for the new front-end we are building, and we are considering to use this package to handle i18n strings management.

I understand that for the vast majority of applications it is fine to load i18n strings from the filesystem and have them stored in json files together with code, I think it makes a lot of sense.

However, to comply with our specific use case, we are not allowed to use this approach, since our translations are stored in a database and we are forced to consume them through an API. And of course we can create a server worker which can generate those jsons from another source and keep them in sync, but I think that it should be easier than this…

Describe the solution you’d like

I don’t know exactly which would be the better way to do it, but I think it would be nice to have a sort of “localeLoader” which would be a function responsible to load the strings (from the filesystem or from another place).

So thinking about the API interface, instead of doing this:

const NextI18NextInstance = new NextI18Next({
  defaultLanguage: 'en',
  otherLanguages: ['de'],
  localePath: 'static/locales',
  localeStructure: '{{lng}}/{{ns}}',
  localeSubpaths: false
})

It could be something like this:

const NextI18NextInstance = new NextI18Next({
  defaultLanguage: 'en',
  otherLanguages: ['de'],
  localeLoader: fileSystemLoader({
    path: 'static/locales',
    structure: '{{lng}}/{{ns}}',
    subpaths: false
  })
})

This approach would allow us to write our own “loacaleLoader” which can (for example) request the data to an API, DB, GraphQL or anything else…

[isaachinman]

One thing that occurs to me is that i18next-node-fs-backend is still going to complain about the filesystem not being the right shape. Let me know if you run into any issues there. There might also be issues with SSR and the current preload: allLanguages logic.

[capellini]

Another option (though admittedly less ideal than a pure i18next solution) – assuming that fetching locale files is strictly a server-side issue, then you can do whatever you’d like in your server code.

For example, there’s nothing that precludes someone from doing this:

  server.use(nextI18NextMiddleware(nextI18next))
  server.use((req, res, next) => {
    // do what you would like here when req.url startsWith '/static/locales'
    // call next() if you would like to proceed with the next middleware
  })
  // or
  server.get('/static/locales', (req, res) => {
    // do what you would like here and send your result
    // this can include setting cache headers, reaching out to another service (and,
    //    perhaps caching those files locally), etc
  })
  server.get('*', (req, res) => handle(req, res))  // hand the rest over to Next

Less than ideal, as GET /static/locales/... and a subsequent GET to another service is two round-trips, but that could be mitigated by a custom caching strategy or cache headers. And you have the added flexibility of providing a fallback, should the service you are using be down for some reason.

At any rate, I thought that I would offer it as an option.