i18next / i18next/i18next-http-middleware

Support for frameworks based on web standards (WinterTC)

Open
#97 1 comment 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.