nextI18NextMiddleware for Koa?

[foreseaz]

Checking out the src of middlewares, now only support express, may I know is there plan to support Koa? Thanks.

[isaachinman]

I'm not a koa user, so I'm not too sure how that'd work.

@jamuhl is koa-i18next-middleware a 1:1 replacement for i18next-express-middleware?

[jamuhl]

the koa-i18next-middleware was done by community...so i never watched that...my guess is no...but like you i never used koa so i never looked deeper into it.

eventual @foreseaz could help with this?!!?

[isaachinman]

Okay. This will definitely need to come from someone who personally uses koa and can ensure things are set up correctly and functional. I have absolutely no idea if we could achieve parity, but my initial assumption is that this would be very difficult or impossible if there isn't a pre-existing 1:1 solution.

[isaachinman]

Ah, also just to mention - this impacts our own next-i18next-middleware in addition to the need for a 1:1 replacement for i18next-express-middleware.

Again I'm not a koa user, but it seems like the same .use function exists, so that might work without any modification.

[jamuhl]

Really someone using koa should look into this. Also, i would give the next-i18next some time to stabilize before adding support for koa.

[isaachinman]

@jamuhl Absolutely agreed. My initial impression is that support for koa will never be added, but someone might come along and surprise me.

[jamuhl]

fully agree...and yes...i would be surprised too...

[foreseaz]

lol, why surprised? Because Koa is seldom used in community?

[jamuhl]

@foreseaz not because of koa - because it's not so easy - you will need to understand: next.js, koa, i18next, react-i18next and next-i18next

[isaachinman]

next-i18next depends upon several other open source packages. The main problem here is that i18next-express-middleware handles a lot of otherwise complicated logic for us involving the delivery of translation content.

We would need a 1:1 koa replacement of i18next-express-middleware in order for next-i18next to support koa, and that simply doesn't exist.

I'm going to close this issue for now - if anyone in the future feels as though it's worth discussing again, just let me know.

[Abramovick]

I'm also using koa, any updates on having a koa version? Or would i need to make one myself?

[Janealter]

@Abramovick try this https://github.com/winstrike/next-i18next-koa

[isaachinman]

@Janealter Does that fork work? First time I have seen it.

[Abramovick]

@Janealter thanks man. The difference seems to be the use of koa-i18next-middleware-fixed instead of i18next-express-middleware. I'll try just installing koa-i18next-middleware-fixed and see if things work.

[Abramovick]

Also am i missing something? The notes say "@isaachinman cannot support koa until a 1:1 replacement for i18next-express-middleware exists"... I thought koa-i18next-middleware-fixed is acting as the replacement...?

[isaachinman]

@Abramovick I hadn't heard of koa-i18next-middleware-fixed until now, and am not entirely sure it will be a good choice in the long run.

We might be able to provide a bailout option where users can just pass their own middleware function, though.

[Janealter]

@isaachinman Yes, it does. But not 1:1.

[Janealter]

@Abramovick, besides using koa-i18next-middleware-fixed, I rewrote some parts of the code, you can see it in the repository next-i18next-koa

[Janealter]

@isaachinman koa-i18next-middleware-fixed is the fixed version of koa-i18next-middleware. I published this package until @lxzxl approved my pull requests with necessary fixes.

We might be able to provide a bailout option where users can just pass their own middleware function, though.

This is a good idea but it is not enough just to replace middleware, we still need to rewrite some other parts of the code that depend on the type of server. In a good way, we need to redo the library structure so that it gives the choice of server to use, koa or express.

[isaachinman]

we need to redo the library

If this project was to be refactored at all, it would be done to be completely agnostic of server framework, and would operate in an entirely serverless manner (vanilla req and res). See #274.

[sep2]

I am using koa2 server also, any updates on this?