MidLangTranslation middleware

How it works ​

An application asks for a key. MidLang answers from the store, or records the miss so it can be translated next:

your app ── GET /t/zh-CN/greeting.hello ──▶ MidLang ──▶ store (one table per locale)
                                              │
                                              └── miss ──▶ issues (what to translate next)

Reads and writes are authenticated and permission-scoped (translation:read, translation:write, translation:delete). Every committed write is published to the changelog and to coverage tracking, so history and statistics stay current instead of being recomputed on demand.

What it is not ​

• A general expression or query engine.
• A full translation management system or a real-time collaborative editor.
• Broad format support before the first formats are lossless.

Status ​

MidLang is early. The store, the HTTP translation API and the admin console exist; deployment hardening, bulk import and export are still ahead.

• Working now — a redb-backed store with paged listing and statistics, authenticated translation read/write/delete over HTTP, opaque bearer tokens with permission groups, missing-key issues, a queryable changelog with one-step rollback, and per-locale coverage measured against a reference locale (/coverage/locales, /coverage/{reference} and /coverage/{reference}/{locale}/missing, served from maintained state the server keeps by default).
• In progress — configurable deployment and packaging, and initial bulk import.
• Planned — the SDK, versioned export, the offline runtime, and plurals/ICU in the value model.