0

I have a frontend project setup with preact-cli, which leverages i18next with http-backend. This configuration is to facilitate the serving of the translations on demand from the CDN the app is to run in production on. So far I can get this to work by doing:

  • npx preact build --no-prerender

followed with a deploy to AWS Cloudfront

Now I would like to statically prerender some of the major routes, but regretfully, a naive: preact build --prerenderUrls ./prerender-urls.js does not work. The reason for this is that once it is to do the step of prerender-ing those routes, it is trying to leverage the i18next-http-backend in the absence of an http server running. At this point, preact build just keeps on hanging(as if I am doing a preact build --analyze).

As such, for that step, I need to use the i18next-fs-backend instead. Regretfully, while this will work for bundling in the translations on a CI/CD-server for those prerendered routes, it will not work for the translations that need to be served over the http-backend.

I only see two types of solutions to this problem:

  1. Do the build in two steps. First with --no-prerender with an i18n.config.js that leverages the http-backend and then with --prerender with an i18n.config.js that leverages the fs-backend. The problem here is that the hashes are different between the two builds so I can not simply copy over the prerendered routes with the other build.
  2. Setup an http server during the build that can serve those translations. This is possible in itself, but a rather brittle work-around.

There is the concept of a chained-backend with i18next that would allow me to define a fallback, but in the context of a browser, how does it make sense to have i18next-fs-backend as the primary source?

What would greatly help me at this stage is if someone can point out that

  1. Either there is a third viable option that I failed to consider
  2. Either I misunderstood some way of doing chained-backend
  3. Either a confirmation that I am correct and that a strong case can be made that preact-cli needs to allow us to do the build in two parts.
Kevin Johnson
  • 1,890
  • 13
  • 15
  • Preact's docs site, [preact-www](https://github.com/preactjs/preact-www), is a full example of how you can implement i18n. I'm not familiar with your setup here, but requiring a server for your translations seems... odd. Static files served over fetch is fewer moving parts and should be just as capable really. – rschristian Oct 24 '21 at 21:15
  • Yeah, the way `i18next-http-backend` works is that you configure an endpoint in your app to fetch translations from: `locale/en/home.json` for instance and then it will fetch it accordingly from the CDN your app is hosted on. Once could specify a third party server/CDN to fetch translations from, but that is certainly no my use-case. `preact-www` seems to have implemented their own i18n solution from the ground up it seems as package.json does not make any mention of a specific i18n library. Certainly cool, to explore later on but for the time being I prefer to leverage something battle-tested – Kevin Johnson Oct 25 '21 at 15:03
  • 1
    The implementation is just a toggle on which language folder to query and `fetch()`, it doesn't get any more "battle-tested" than that. That being said, there's plenty of options out there that work just find. I don't think this tool that you're using makes much sense in the context of what `preact-cli` does. – rschristian Oct 25 '21 at 23:04

0 Answers0