Closed liel-almog closed 1 year ago
The only way to have typesafe translations is to to tell TypeScript the actual translations. I have no idea how this could be done via http in a async way.
I don't think that will ever be possible without having the translations saved also locally. Am I right @pedrodurek ?
That is what I thought. But loading translation files on a big project will be cumbersome. My question is what do most people do when they approach this situation with i18next react
The i18next-http-backend loads the translations on runtime... TypeScript is not relevant during runtime. So if you want to have typesafe translations and also use i18next-http-backend, just use the i18next-http-backend as usual and also define typescript declaration file like described here. There's not much we can do here.
Thank you for your time. I will sure find a way to make it work for our case
I reopened the issue because I would like to ask, from your experience what do other programmers do when dealing with the issue of validating the language translation for every supported language and that the translations are correct. Thank you
Try stackoverflow
what about using a translation management tool like locize.com for that?
at least on a big project you will need some tooling that helps both your developers and translators to keep up with the ongoing translation process.
locize bridges both sides by helping translators and developers
Thank you
Translation file types support for http-backend plugin
My team wants to add
i18next
, we are using a React with Vite ( without SSR ). I was given this task. We use heavily on TS and I noticed that is the Docs there is a section about Typescript but this section only talks about local translation files but I think that the better approach is to use the HTTP plugin, this adds speed and reduces code complexity but unfortunately I could not find a way of adding the types in a .d.ts file as recommended in the docs or any way of validating thet('key')
Motivation
I think that a good combination would include types validity and also the HTTP plugin because this two cloud sky rocket the usage of the package. We will be able to write blazing fast translation files and also get auto complete and code validation by TS