i18next / i18next/i18next-http-middleware
Support for frameworks based on web standards (WinterTC)
- Dominant language
- JavaScript
- Stars
- 170
- Forks
- 30
- Avg merge
- 14m
- Merged PRs (30d)
- 2
Description
## 🚀 Feature Proposal
In 2025, there are many frameworks that are based on pure web standards, as formalized by WinterTC. One of the most popular ones is [Hono](https://hono.dev/), which uses `fetch()` and `Request/Response` headers as available in every JS runtime (and so, can run almost everywhere).
Looking at the code, it looks like this middleware still doesn't support such frameworks (apparently it is based more on NodeJS based frameworks, like Express, Hapi and so on). Can we add support to them?
## Motivation
The goal is to be able to run i18next everywhere, even on limited environments, like edge runtimes (cloudflare workers, AWS lambda, etc.)
## Example
Adapt the API to support frameworks based on `fetch()` API, and maybe implement a [custom Hono Middleware](https://hono.dev/docs/guides/middleware#custom-middleware) integrated with it.
Contributor guide
Research direction
Review the current middleware entry points and how they depend on Node.js request and response objects; the issue does not name files or tests. Compare those assumptions with Hono's custom middleware and the fetch Request/Response model. Done means a decided API and verified support for standards-based runtimes such as Hono, including edge environments.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- deno, javascript
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100