EhTagTranslation Database, the tag corpus behind a family of E-Hentai clients

A corpus, not an application

This repository holds translation data and almost nothing else. The top level is a `database/` directory, a `scripts/` directory, a `version` file, `CONTRIBUTING.md`, `LICENSE.md` and the project README. The scripts are written in PowerShell, which is why the primary language on the repository is recorded as PowerShell rather than anything web related, and the presence of a `.prettierignore` suggests the data files themselves are kept in a consistent format. The interesting engineering here is not application logic but corpus maintenance: keeping a mapping of community tags, artist names, group names, parody references and character names accurate as new content appears, and publishing that mapping in a form several unrelated clients can consume. The downstream project list makes the scale visible, with more than a dozen applications across web, Android, iOS, Windows and macOS depending on the same translation source.

The category split is what clients actually consume

The corpus is published as separate datasets by category, and the categories are the vocabulary of the tagging system itself. The badge list in the project documentation names them: `all` as the combined set, `reclass`, `female`, `male`, `mixed`, `location`, `language`, `other`, `group`, `artist`, `cosplayer`, `parody` and `character`. Several of these are not parallel. `all` is a union view, and `reclass` is a different axis from the gender categories, which is exactly the sort of distinction that makes a shared corpus hard to consume correctly. Each category has its own published dataset path on the hosting service, and the documentation links a browsable list page per category on the web front end, so a client developer can see what a category contains before deciding how to consume it.

https://ehtt.vercel.app/list/all
https://ehtt.vercel.app/list/artist
https://ehtt.vercel.app/list/group
https://ehtt.vercel.app/list/character
https://ehtt.vercel.app/list/parody
https://ehtt.vercel.app/list/cosplayer
https://ehtt.vercel.app/list/location
https://ehtt.vercel.app/list/language

A reader who wants to know the real shape of the data should browse those list pages rather than infer it from the badge names.

The licence carries a non-commercial clause and collective ownership

The data is not public domain, and the terms are stated in the project documentation with unusual precision. Unless otherwise declared, the text content of the database is offered under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 licence, with additional terms possibly applying, and the licence file sits in the repository as LICENSE.md. The second condition is the one that shapes who can use the corpus. The content is owned jointly by all the editors, and publishing an edit in the project is taken as permission to use that contribution freely and without charge in the various downstream EhTagTranslation projects. That is a grant to the ecosystem, not a blanket public licence, so a commercial product has to read the terms rather than assume a Creative Commons badge settles the question. The repository metadata itself cannot classify the licence and points to the LICENSE file, which is the correct signal to read the file.

Contributions go through the web editor, not through pull requests

The participation path is a hosted tool rather than a git workflow. The documentation directs contributors to the EhTag Editor, hosted at the same domain as the project front end, and tells them to read the participation guide before editing. The legacy workflow that the editor replaced is still visible in the discontinued projects list, where EhTagBuilder is described as the predecessor that implemented translations as a UserScript: it fetched the wiki database web page, generated matching CSS, and had the Stylus browser extension attach that CSS to the site pages. The current approach is a server side editor, which means the data entry surface is the web app and the repository is the output rather than the input. That inversion is the main architectural fact about the project, and it also explains why the repository accepts contributions through the editor rather than through merge requests.

A dozen clients read the same translation source

The downstream list is the proof that the corpus is treated as infrastructure. EhSyringe is named as the official implementation of the project, shipping both a UserScript and a browser extension that injects the Chinese translation into the site, and the documentation describes it as replacing the older EhTagBuilder approach. Around it sit client applications in almost every mobile and desktop stack: E-Viewer as a UWP client, EhViewer-Overhauled which the documentation marks as maintenance only after the original project stopped updating, several forked and modified EhViewer builds for Android, Dai-Hentai and EhPanda for iOS, JHenTai as a Flutter application covering Android, iOS, macOS and Windows, and FEhViewer as a Flutter reader that supports direct connection. One downstream project is not a viewer at all: EhDatabase2Dictionary converts the corpus into dictionary formats such as MDict, which is a neat illustration that the data is useful outside the site it was scraped from.

Release names record the last edit, not a version of the software

The release names are the most unusual thing about the publishing process, and they tell you how the project is versioned. The three most recent releases are named for the edit they contain: one for a change to the artist entry for sashimi, one for a change to the group entry for Whisp, and one for a change to the artist entry for homare. All three landed on 2026-10-15 within a few minutes of each other. The version numbers follow the same scheme, incrementing the build component for each edit, so the repository carries a dense sequence of releases rather than periodic ones. Practically, that means a consumer pinning a version is pinning a specific point in the translation history, and the release notes double as a changelog of individual corrections. The project is not archived.

Where the shared-corpus model strains

Two limitations are worth naming, both implied by the structure rather than stated as complaints. The first is that a corpus owned collectively and edited through a hosted web tool is a single point of coordination. A client developer cannot fix a bad entry locally without forking, and a project that wants its own naming policy has to fork rather than configure. The second is the non-commercial clause. A community corpus is a reasonable default for a hobby ecosystem, but it means a company building a commercial reader on top of the data has a licensing question to answer that the repository's own metadata declines to answer for you. A third practical point is that the data is served from a hosted endpoint with a web front end, so a client that needs the corpus bundled rather than fetched has to snapshot it, and the version file in the repository is the thing to snapshot against.

Editorial conclusion

Adopt this database if you maintain a client for E-Hentai and want Chinese tag translations without maintaining a translation effort of your own, and skip it if your product is commercial, because the licence carries a non-commercial clause that the metadata cannot even classify, and if you need the data offline, because the canonical copy is served from a hosted endpoint rather than packaged as a release artifact you can vendor freely. Verify three things before you build on it: which category endpoints you actually need, since the corpus is split into more than a dozen of them; that your client can consume the format those endpoints serve; and whether the licence terms in LICENSE.md fit your use, since the data is owned collectively by the editors rather than by a single holder.

Frequently asked questions

Official sources

1. EhTagTranslation/Database on GitHub
2. Issues
3. Project website
4. README
5. Releases