MiuRead for KOReader: two OTA channels, a tag that moves after creation, and chapter-scoped translation

Two branches, two OTA manifests and one legacy root file

Updates are organised around channels rather than around a single version file. The stable line lives on `main` and publishes its manifest at `stable-channel/update.json`. The beta line lives on `beta` and publishes at `beta-channel/update-beta.json`. A third file sits in the repository root, `update.json`, and the project is explicit about its role: it is kept only as a bridge entry for older stable versions and is not the live update manifest for the current stable release. That means an older install pointing at the root path will keep working while a current stable install reads from the channel directory instead. The repository root also carries `CHANGELOG.md` as the full version record, alongside `LICENSE`, `NOTICE` and `THIRD_PARTY_NOTICES`, and two implementation notes in `PERFORMANCE_IMPLEMENTATION.md` and `VERIFICATION.md`. The plugin itself is the single `miuread.koplugin` directory.

Stable means newest non pre-release, so the newest tag is often a beta

Which build you get is decided by the pre-release flag rather than by a branch name or a version prefix. The stable build is the newest release that is not marked pre-release; the beta build is the newest one that is. Sorting tags by date gives a different answer, and the recent history shows why that matters. The three most recent releases are all internal-test builds: v5.9.0-beta.4 and v5.9.0-beta.1 were both published on 2026-10-02, and v5.8.0-beta.22 came on 2026-09-08. Two releases of the same beta line on one day also means beta numbering is dense, reaching beta.22 within the 5.8 line. The last commit to the default branch landed on 2026-10-02, the same day as the two beta tags, so the project is moving fast enough that a weekly check of the release list is closer to necessary than not.

The tag is created first, then moved to the synced commit

The release process inverts the order you would expect. Stable tags follow `vX.Y.Z` and beta tags follow `vX.Y.Z-beta.N`. After the tag is created, a release workflow syncs the version number, the release channel and `CHANGELOG.md` into the branch source, and only then does the tag get pointed at the synced commit. So the tag you see in the list did not point at the commit it was made on, and the branch it belongs to gains a version bump after the tag exists. Two constraints keep this honest: a beta tag must be created on the latest commit of `beta`, and a stable tag must be created on the latest commit of `main`. The end state is that branch source, tag source, release package and OTA manifest all carry the same version. The root `update.json` is deliberately excluded from that chain, which is why it is described as a bridge rather than a manifest.

Translation runs on WeRead's service and stops at two chapters

The foreign-language translation feature has an external dependency and a hard limit. For books uploaded to WeRead, the reader toolbar offers three display modes: original, bilingual, or translation only. Generated translations come from WeRead's own official service, which means the account signed into the plugin has to be a paid member, and requests are restricted to the current chapter and the next one. Whole-book generation is not on the menu. The display modes behave differently depending on what is already on the device. If the current chapter has a local translation, switching mode only changes what is displayed and downloads nothing; paragraphs with no translation keep showing the original text; and for books where the original and the translation cannot be separated safely, bilingual is the mode that works.

A failed migration keeps the old file instead of the new one

Translation updates are staged rather than applied in place. When a chapter needs new translation, the update is first written as a pending install file. The reader is expected to close the book, wait for the new-version-installed notice, and reopen it, at which point the chapter, its images, the reading position and the highlights are migrated and verified. If that verification fails, the original file is kept rather than the pending one, which is the safer of the two outcomes for a reader with existing annotations. Typography is per book rather than global: the translation body size can be moved between 80% and 180% and the setting is remembered for each book. Text produced from an uploaded PDF matches the relative size of the corresponding English text and follows changes to the reading font size.

Installing means dropping one directory into the plugin folder

There is no package manager involved. Installation is four steps: download the build you want from GitHub Releases, unzip it, put the complete `miuread.koplugin` directory into the KOReader plugin directory, and restart KOReader fully. A partial copy is not a valid install, since the release artifact is the directory rather than a single file. Versions that support dual update channels add a channel switch in the plugin settings, under the update-and-about screen, where you can pick between the stable and beta manifests. That switch is a property of the build, not of the settings screen, so a version without dual-channel support leaves you on whatever manifest it shipped with. The plugin targets Kindle through KOReader, and its feature set covers the bookshelf, downloading, highlights and thoughts, reading time and progress sync.

AGPL-3.0-only, forked from a plugin at v0.1.1

Licensing and lineage are stated plainly. MiuRead began as a modified version of `finlater/weread.koplugin` v0.1.1 and has since been restructured, modified and extended. It is distributed under the GNU Affero General Public License version 3 only, spelled `AGPL-3.0-only`, with `LICENSE`, `NOTICE` and `THIRD_PARTY_NOTICES` in the repository for the details. The same section states that the project is an unofficial community effort with no affiliation to or endorsement from WeRead, Tencent, KOReader or their maintainers. That disclaimer matters more than usual here, because the plugin reads another company's service and because the origin is another person's plugin: anyone redistributing a modified build is working inside the copyleft terms rather than around them. The primary language is Lua, and the working tree holds the plugin directory plus a `tools/` directory.

Editorial conclusion

MiuRead is worth trying for Kindle KOReader users who read from WeRead and want bookshelf, download, highlights, reading time and progress sync in one plugin, and who can accept a community project with no affiliation to WeRead or Tencent. Before you install, pick your channel deliberately: stable is the newest non pre-release and beta is the newest pre-release, and both use different manifest files, so grabbing the newest tag by date can hand you a beta. Check the language-translation features against a paid WeRead account, since generation depends on WeRead's own service and is limited to the current and next chapter, and keep the CHANGELOG next to you because the recent release history is entirely beta builds.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. miumiupy98-art/miuread-koreader on GitHub
4. README
5. Releases