Manga Translator for Android: On-Device Bubble Detection, LLM Translation, and a Screen Overlay
安卓手机端的即时自动漫画翻译软件，由LLM驱动。Instant automatic manga translation app for mobile devices, powered by LLM.
At a glance
- What is it?
- An MIT-licensed Kotlin app that runs YOLO and PaddleOCR models locally to find manga speech bubbles, then sends the text to any OpenAI-compatible endpoint for translation. The design bets on local detection plus remote translation, and the documentation is explicit about where that bet can fail.
- Who is it for?
- Adopt it if you read untranslated manga on an Android device, are willing to supply your own OpenAI-compatible endpoint and API key, and can accept that page order depends on you renaming files before import. Do not adopt it if you need a zero-configuration reader, if you cannot run an LLM endpoint reachable from the phone, or if you expect translated text to land inside the original bubble shape without manual dragging.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 13 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Gap Between Raw Manga Scans and Readable Text on a Phone
Manga translation on a phone usually means one of two things: a cloud service that uploads your pages to a translation vendor, or a desktop toolchain you run on a laptop and then copy to the device. This project sits between those. The README describes an Android app that performs bubble detection and OCR locally, then calls an OpenAI-compatible API for the translation step, and draws draggable translated bubbles over the original image. The target user is someone reading Japanese, English, Korean, French, Spanish, Portuguese, German, Italian or Russian manga on an Android phone who wants Chinese output, or someone reading Chinese who wants English or Russian output. The screen translation mode extends this beyond the app's own reader: a floating window recognizes and translates whatever is on screen in any app or on the launcher. That is a narrower audience than a general OCR tool, and the feature list reflects it. Library management, CBZ and ZIP and PDF import, reading progress, and a per-folder glossary all exist to support the reading loop rather than to be standalone utilities.
How the Pipeline Runs: Local Detection, Remote Translation, Overlay Rendering
The mechanism is a two-stage split. Stage one is entirely on-device. A YOLO26n-seg model at 1472x1472 ONNX resolution handles ordinary bubble detection and outputs bubble contours, so the app knows where speech bubbles are rather than just where text is. A separate PaddleOCR detection model (PP-OCRv6_det_mobile_infer.onnx) finds text lines and merges text blocks, and recognition models handle the scripts: PP-OCRv6_small_rec.onnx for Japanese, English, Chinese and mixed Chinese-English, plus a Korean PP-OCRv5 mobile recognition model with its own dictionary file. Stage two is the LLM call. The README states the app works with an OpenAI-compatible interface and that you configure the OCR side either as local OCR or as an OpenAI-compatible OCR API with address, key and model. Translation results are written per image as a same-named .json file, with OCR cache in .ocr.json. The reading view then renders translated bubbles as an overlay on the original page, and those bubbles can be dragged to reposition them. A per-folder glossary.json accumulates fixed terminology, which is the mechanism that keeps character names consistent across pages without you re-entering them.
Getting It Building: JDK 17, Android SDK 36, and Model Files You Must Supply
The build section is unusually specific, which is a good sign for reproducibility. Environment requirements are JDK 17.0.17 or later, Kotlin 2.0.0 or later, Gradle 8.11.1 or later, and Android SDK platform 36 with build-tools 36.0.0. Build commands are ./gradlew :app:assembleDebug and ./gradlew :app:assembleRelease. The part that will stop most people is the assets. The README instructs you to place model files into corresponding subdirectories under assets/: models/detection/manga-bubble-seg-yolo26n-1472.onnx for bubble detection, models/detection/PP-OCRv6_det_mobile_infer.onnx for text line detection, models/ocr/PP-OCRv6_small_rec.onnx for general recognition, and models/ocr/korean_PP-OCRv5_mobile_rec.onnx plus its .txt dictionary for Korean. Several models are linked to Hugging Face repositories under PaddlePaddle, and the README notes that prompts, fonts and OCR configuration also live under assets/ with names that must match the code. Release version numbers must be kept in sync across three places: app/src/main/java/com/manga/translate/app/VersionInfo.kt, app/build.gradle.kts, and update.json. If you are only using the app rather than building it, the setup path is shorter: create a folder in the library, import images, ensure filenames sort in reading order (the README's example is 1.jpg, 2.jpg), pick local OCR or enter an OpenAI-compatible OCR endpoint, then tap translate folder.
Where the Design Breaks: Page Order, Timeouts, and the Wrong Base URL
The FAQ section is effectively a list of failure modes, and it is worth reading as one. Translation ordering can come out wrong, and the documented fix is that you must rename images into reading order before importing. That is a manual step the app does not perform for you, and it means a freshly downloaded chapter with arbitrary filenames will produce scrambled output until you fix it. Translation can fail or return empty results, and the README attributes this to two causes: the API address must be the OpenAI-compatible parent address the provider gives, with the app appending /chat/completions itself, and the model name must match the provider and be network-reachable. The examples given are https://api.deepseek.com/v1 and https://open.bigmodel.cn/api/paas/v4. A user who pastes the full chat completions URL instead of the parent will get failures. Full-text fast translation is advised to be uploaded in batches when page counts are high, or the API timeout raised in settings, which tells you the request size scales with page count and the default timeout is not sized for large batches. On the question of where to obtain an AI endpoint, the README's answer is to search for it yourself. That is a real gap: the app has no bundled translation backend, so it is unusable until you bring your own credentials.
What the Overlay Approach Costs Compared with a Full Reader
The alternative most people reach for is a dedicated manga reader with a translation plugin, or a desktop pipeline like the manga-ocr lineage that this project credits. The difference in approach is where the text ends up. This app keeps the original artwork as the page and renders translated bubbles as a movable overlay, which preserves the drawing but means the translated text does not conform to the original bubble shape. The README addresses this with drag positioning and plus/minus fine adjustment, plus a cancel key, which is an admission that automatic placement is not final. A reader that reflows or in-paints the page would avoid that manual step but would also alter the source image. The screen translation mode is the feature with no clean equivalent in a reader plugin: a floating window over any app means you can translate a manga page inside a browser or a social feed without importing it into the library first. The trade-off is that screen translation depends on the same remote LLM, so it inherits the same latency and endpoint requirements, and it cannot use the per-folder glossary.json that the library path maintains.
Maintenance Surface: Three Version Files, Local Models, and an MIT Licence
The maintenance cost visible in the repository is mostly about keeping model assets and version strings aligned. Because detection and OCR models are shipped under assets/ with names the code depends on, swapping a model means matching the filename and the configuration the README says lives alongside it. The release process touches VersionInfo.kt, app/build.gradle.kts and update.json together, so a release that updates only one of them will report an inconsistent version. The app checks for updates at startup, which means the update.json file is a live part of the distribution, not a build artifact. On licensing: the project is MIT, which is permissive and permits commercial use and modification, but the bundled and referenced models come from separate projects (PaddleOCR, kha-white/manga-ocr, bluolightning/manga-ocr-mobile) with their own terms, and the README does not restate those terms. If you plan to redistribute a build with models included, check each model's licence independently rather than assuming MIT covers the weights. This is not legal advice, and the repository does not resolve the question for you.
Who Should Take This On, and What to Check Before Committing
The project earns its place for a specific reader: someone with an Android phone, an OpenAI-compatible endpoint they already pay for or self-host, and a library of manga in one of the supported source languages. For that person the local detection and OCR stage removes the per-page upload of images to a translation vendor, and the glossary plus per-image JSON cache means repeat reads do not re-translate. The people who should not adopt it are those who want a translation feature with no setup: there is no bundled model endpoint, the README tells you to search for how to obtain AI access, and the build path requires downloading and placing several ONNX files under assets/ before anything compiles. Before committing, verify three things against your own situation. First, that your provider's base URL is the parent form, since the app appends /chat/completions and a full URL will fail. Second, that your source language appears in the supported list, because the recognition models are per-script and Korean in particular has its own model and dictionary. Third, that your reading workflow can tolerate renaming files into order, because nothing in the documented pipeline infers page sequence for you.
Editorial conclusion
Adopt it if you read untranslated manga on an Android device, are willing to supply your own OpenAI-compatible endpoint and API key, and can accept that page order depends on you renaming files before import. Do not adopt it if you need a zero-configuration reader, if you cannot run an LLM endpoint reachable from the phone, or if you expect translated text to land inside the original bubble shape without manual dragging. Verify first that your chosen provider's base URL matches the OpenAI-compatible parent form the README names, that your source language is on the supported list, and that the model files listed under assets/models actually download, since the app will not build or run without them.
Community notes