BasicCAT — Computer-Aided Translation (CAT) Tools

9 Manga Translation Tools Tested and Compared: AI Translation Plus Manual Editing, Which One Fits You

Sun, 04 Oct 2026 12:00:00 +0000

Recent years have seen a flood of manga translation tools. They can not only fully automate translation and lettering, producing a translated comic, but also support manual editing so you can polish and fine-tune the AI output.

This article first covers what manga translation tools are used for, how to evaluate them, and the technical details behind them. Then it runs a rough hands-on comparison of nine tools that support post-editing, using a single page of Detective Conan translated into Chinese and English as the example.

What Manga Translation Tools Are For, and How to Judge Them

You might reach for a manga translation tool for any number of reasons:

To quickly translate raw manga on a web page for your own reading
To extract the text from a comic for language learning, building a corpus, or academic research
To produce high-quality translated pages for other readers

Different purposes call for different criteria. For quick reading, image translation needs to finish within seconds, quality is not the priority, and a browser extension matters. For high-quality work, you need configuration options, a convenient human-in-the-loop interface, and where necessary the ability to export the data and carry on translating in third-party software such as Photoshop.

Ease of use and the operating systems supported are further dimensions worth weighing.

Technical Details Behind Manga Translation Tools

Before evaluating anything, it helps to understand how these tools work under the hood.

A manga translation tool usually involves four steps:

Text recognition
Text removal
Text translation
Lettering

These steps are normally carried out separately. With the arrival of multimodal and image-generation large language models, end-to-end approaches have appeared as well — a single model that solves all of the above. Nearly every tool offers the traditional step-by-step mode and has adopted large language models to varying degrees.

Text Recognition

Text recognition (OCR) typically takes two stages: text localization and character recognition.

Every manga translation tool uses some combination of text detection and character recognition models, and many train specifically on comics. Some common models:

Detection models:

comic-text-detector: a text detection model trained by dmMaze. It accurately produces text masks, which can then be used for text removal and for determining text rotation.
YSGYolo: a detection model trained on YOLO that can detect speech bubbles, text lines and more, while deliberately skipping sound effects.
PaddleOCR: PaddleOCR provides a text detection model where one model handles localization across languages, plus layout detection models such as PPDocLayout that can determine reading order at the same time.

Recognition models:

mitOCR 48px: the character recognition model from the manga-image-translator open-source project. It also detects text color and must be run line by line.
manga-ocr: a Transformer model trained on the manga109 Japanese manga dataset. It handles multi-line text images and ignores furigana automatically.
PaddleOCR: PaddleOCR also provides recognition models, from small fast ones to PaddleOCR-VL, a large language model with high accuracy but slower inference.

There are auxiliary models too, such as panel detection, text direction detection, language identification and font recognition. Panel detection is the most useful of these, since it helps correct the reading order.

Text Removal

Text removal can be done in many ways: blurring the text, filling with a solid color, or using image inpainting to strip the text and redraw the area it covered.

Many inpainting methods are used by these tools.

Traditional image processing:

OpenCV Telea
PatchMatch

Deep learning:

AOT
Lama

Image-editing large models:

Flux
Gemini Nano Banana

Inpainting requires a text mask first. The comic-text-detector mentioned above can produce a fairly precise mask. For ordinary images, a plain rectangle combined with a good removal model already works well. If the text separates easily from the background, simple binarization is enough — fast and accurate.

Text Translation

Traditional neural machine translation generally translates sentence by sentence and can send several sentences in one request. Some of the more advanced options support custom terminology; DeepL and Caiyun both perform well.

Large language models now substantially outperform traditional machine translation. They handle very long context, can read images with vision models, let you constrain the style through prompts, and support terminology as well — and they can still translate correctly even when the OCR result contains errors.

Lettering

Placing text into the original image looks simple but is actually fairly involved. It needs to handle letter spacing, line spacing, font size, font family, rich text (bold and italic), color, rotation, outlines, vertical Chinese characters and many other settings. It also needs a degree of automation — automatically adjusting font size, setting text direction, and so on.

Technology Stacks

The technology stack is whatever the tool is built with. Because Python is the dominant language in AI and is easy to learn, most manga translation tools are written in it, with QT as the UI library and PyTorch or ONNXRuntime for inference.

Plenty of tools use something different, though — Java, Rust, JavaScript, Flutter, Go and so on. Each has its strengths: some are easy to distribute, some are cross-platform, some are fast. The field today is genuinely a contest of many schools.

Basic Information on the Nine Manga Translation Tools

A note on versions: these tools are all under active development and release frequently, so the descriptions here may change over time. The versions compared in this article are: ImageTrans v6.5.2, BallonsTranslator v1.5.18, Comic-Translate v2.8.9, Koharu v0.83.5, Dango Translator v7.0, ComiTrans v2.3.0, Saber Translator v3.5.10, Manga-Translator-UI v3.0.4, and Nekotranslator v1.3.0.

The table below summarizes the basics of these nine tools. Note that the size given is the Windows installer or archive, and where models are downloaded separately or bundled, that is noted. “Paid” here refers to the software itself, and “models bundled” means whether the installer already contains the OCR and text removal (inpainting) models.

Software	Released	Tech stack	Size	Paid	Open source	Models bundled	Link
ImageTrans	2020	Java + JavaFX	~400MB (models included)	Paid (personal from ¥75)	No	✅ Bundled (OCR and Lama inpainting models, runs offline)	Link
BallonsTranslator	April 2022	Python + PyTorch	~32MB (~1.7GB models to download)	Free	✅ GPL-3.0	❌ Downloads on first run	Link
Comic-Translate	January 2024	Python + ONNXRuntime	~95MB	Free	✅ Apache-2.0	❌ Downloads from Hugging Face	Link
Koharu	April 2025	Rust + Tauri	~166MB	Free	✅ Apache-2.0	❌ Downloads on first run	Link
Manga-Translator-UI	August 2025	Python	~1.3GB (models included)	Free	✅ GPL-3.0	✅ Bundled (integrates manga-image-translator models)	Link
Saber Translator	February 2025	Python + TypeScript/Vue	~3.5GB (plus ~1.3GB models)	Free	✅ GPL-3.0	⚠️ Models packaged separately	Link
Nekotranslator	July 2026	Flutter	~66MB	Free (bring your own translation API)	No	❌ Requires a download	Link
ComiTrans	December 2025	Python + ONNXRuntime	~442MB (plus ~463MB models)	Free	⚠️ No open-source license	⚠️ Models packaged separately	Link
Dango Translator	February 2020	Go	~833MB	Manga translation is paid	No	❌ Fully cloud-dependent, no local models	Link

As you can see, the overwhelming majority of manga translation tools choose Python with PyTorch or ONNXRuntime, go the free and open-source route, and distribute the program and models separately, downloading the models on first run. ImageTrans ships its models by default for an out-of-the-box experience, yet still comes in at only 400MB.

The technical details are too numerous to compare one by one. These tools broadly support all the models and algorithms for the four translation steps above. As it stands, ImageTrans additionally supports panel detection and BallonsTranslator additionally supports font detection.

The Tools, One by One

Below are brief reviews, screenshots and result comparisons for each tool.

The sample manga page:

The official Chinese edition of the sample page:

The official English edition of the sample page:

ImageTrans

ImageTrans is a cross-platform computer-aided image translation tool written in JavaFX. As paid software it genuinely delivers on usability, with rich features and deep customizability. At around 400MB it includes the runtime and all the basic OCR and text removal models, and it works well whether you are translating fully automatically or editing by hand — and it is fast. It supports a browser extension and PSD export, along with many other features such as translation memory — the core of a traditional computer-aided translation tool — searchable PDF generation, converting traditional comics to webtoon format, and document scanning. The flip side of having so many features is that you may struggle to find your way around without reading the documentation.

Automatically translated Chinese version:

Chinese version after manual editing:

Automatically translated English version:

English version after manual editing:

Because ImageTrans makes lettering and removing sound effects relatively easy, a manually adjusted version is included here as well.

BallonsTranslator

BallonsTranslator was the earliest open-source computer-aided manga translation tool. It is written in Python, runs most of its models through PyTorch, and supports acceleration on a range of GPUs. It can be difficult to use from mainland China, though — the models often fail to download — and the default output and the degree of interactivity leave something to be desired. Still, the number of adjustable parameters is already substantial, and being open source means anyone can customize it to their heart’s content.

Automatically translated Chinese version:

Automatically translated English version:

Comic-Translate

Another open-source tool focused on manga translation, also written in Python, but running most models through ONNXRuntime. The default translation requires buying credits, though a custom endpoint lets you use your own API. The editing interface is on the simple side.

Automatically translated Chinese version:

Automatically translated English version:

Koharu

Koharu is an open-source manga translation tool written in Rust and Tauri. Its author has contributed a great deal to the Rust ecosystem along the way, training and converting a number of models. Users in mainland China need a VPN to download the binaries, which is less than friendly. The engineering here is strong, but I still did not find it comfortable to use. Text is centered on the speech bubble, for instance, and bubbles are often irregular, so centering gives a poor result.

Automatically translated Chinese version:

Automatically translated English version:

Manga-Translator-UI

An open-source graphical program built on the main models and design of manga-image-translator. The developer communicates technical ideas well and works quickly, and there are plenty of distinctive features. I am not fond of its line breaking, though: you have to insert line breaks by hand and it cannot wrap automatically, so the lettering is only so-so. It offers two interfaces, a web one and a Python desktop one. The default desktop interface is shown here.

Automatically translated Chinese version:

Automatically translated English version:

Saber Translator

This open-source project uses a separated front-end and back-end architecture and offers an online version, so users can run it in the browser without downloading anything. It has some original ideas too, such as book management that generates a synopsis to assist translation. For now it is mainly used to translate into Chinese, and support for other languages is average.

Images rendered through web technology look decent, but I really do not like this web interface. It is rough, and it does not display well on my small screen.

Main interface:

Editing interface:

Automatically translated Chinese version:

Nekotranslator

A new manga translation tool from the author of LabelPlus, the collaborative scanlation software. Written in Flutter, it is the only tool here that supports desktop, Android and iOS.

The workflow is novel, but I am still more used to an interface like Photoshop’s. It is also still fairly rough around the edges.

Automatically translated Chinese version:

Automatically translated English version:

ComiTrans

A recently released open-source tool. It is simple to use and easy to install, with a 400MB main program and 400MB of models. The number of configurable options is still very limited, and neither the interface language nor translating into other languages can be set yet. Like ImageTrans, it can choose an appropriate inpainting method depending on whether the background is complex.

Automatically translated Chinese version:

Dango Translator

Dango Translator appeared back in 2020, mainly for translating games via screenshot OCR, and it now supports manga translation as well. It is written in Go. Unfortunately its manga translation depends entirely on cloud services for OCR and text removal, which requires a subscription. When I tried it, the cloud service was down and the translation never went through. It does offer some editing, though the display has problems on small screens.

Conclusion

They are all manga translation tools, but each has its own features and interface design, some open source and some paid. Use this article as a reference when choosing the translation tool that suits you. If, for example, I need to translate an image into several languages, I can use ImageTrans: it has a dedicated project file, so I can OCR and then translate, saving each language in its own project, and it even supports being driven by an AI agent. If I want to edit images on my phone, on the other hand, Nekotranslator is the only option.

Improving the Availability of the ImageTrans Remote Translation Service

Mon, 21 Sep 2026 12:10:00 +0000

ImageTrans can connect to a remote server over WebSocket to provide image translation as a service. There are two ends in this setup:

The server (ImageTrans_wsServer) runs on a VPS, receiving and dispatching translation requests
The client (ImageTrans) runs on a mac mini m4 at home, doing the actual OCR, text detection, translation and typesetting

The architecture itself is simple, but keeping it running reliably means dealing with a fair number of availability problems. Here’s a record of the improvements made so far and the pitfalls found along the way.

Dispatching on the server

The most basic problem is dispatching across multiple clients. The server keeps a connection pool, and each client reports its own displayName on connect via set_name_and_password; the server dispatches based on that.

Dispatching prefers idle instances. If the requested instance is busy, another idle one picks up the work. Each instance has its own busy flag, with ConcurrentHashMap’s putIfAbsent providing atomicity so two requests can’t grab the same instance at once.

There’s also a failure cooldown: after an instance fails repeatedly, it stops receiving work for a while. And timeout redispatch — if an instance doesn’t respond within 3 seconds, or hasn’t finished within 60 seconds, the request is redispatched to another instance.

Process isolation on the client

On the client side, two things were done:

The first is starting a separate process. Translation jobs run in their own process, so memory leaks don’t accumulate in the main one. This is controlled by the useIndependentProcessForServer preference and kicks in during ExecuteWorkFlow.

The second is periodically restarting itself. The client has a RestartTimer, defaulting to an 8-hour interval, which relaunches itself when it fires. In theory this clears out accumulated state.

Problems found

The mechanisms above look reasonably complete, but some problems showed up in actual operation.

One major problem is that the client receives an image, starts processing it, and then mysteriously hangs, leaving that instance unavailable from then on.

Workarounds

Since RestartTimer can’t be relied on once things hang, the fix bypasses it and works from outside the process. A scheduled task on the host system pkills the client process and restarts it every 24 hours.

Scheduled killing has an obvious flaw: 24 hours is a fixed period, not “restart when stuck”. If the hang happens 10 minutes after a restart, you wait another 23 hours and 50 minutes.

So a watchdog can be added on top: watch the clients connected via the server’s list port, and if a connected client’s name is no longer there, restart that process.

Multi-Language Jekyll Sites and SEO

Fri, 18 Sep 2026 11:40:00 +0000

Jekyll has no built-in support for multiple languages. When a site only has one or two languages, the most common shortcut is to branch with conditionals:

{% if page.url contains '/zh/' %}
  ...Chinese content...
{% else %}
  ...English content...
{% endif %}

With one or two languages this is tolerable. But every language you add means another level of nesting in every template, and the branches start to interleave with each other until nobody dares to touch them.

The better approach is to make language a first-class citizen: move the language list into config, let each page declare its own language, and have templates do nothing but look things up. This post covers that change, plus the multi-language SEO work you should do along the way.

Start with config

The core idea is to define the language list in _config.yml:

languages:
  - code: en
    label: English
    url: /
    locale: en
    hreflang: en
  - code: zh
    label: 中文
    url: /zh/
    locale: zh_CN
    hreflang: zh-CN
  - code: ja
    label: 日本語
    url: /ja/
    locale: ja
    hreflang: ja
  - code: ar
    label: العربية
    url: /ar/
    locale: ar
    hreflang: ar
    rtl: true

Then each page declares its language in the front matter:

---
layout: page
title: ダウンロード
lang: ja
---

In templates, the if/else is replaced by a lookup:

{% assign cur = site.languages | where: "code", page.lang | first %}

The benefit is that adding a language means changing one config entry and adding one directory — no template changes at all.

If you don’t want to hand-write lang in every file, set it in bulk per directory with defaults:

defaults:
  - scope:
      path: "zh"
    values:
      locale: "zh_CN"
      lang: "zh"
  - scope:
      path: "ja"
    values:
      locale: "ja"
      lang: "ja"

`locale` and `hreflang` are two separate fields

Note that locale and hreflang are kept apart in the config above and cannot be merged into one. This is an easy detail to overlook:

locale is used for <html lang> and og:locale, and takes the underscore form (zh_CN)
hreflang is used for <link rel="alternate">, and takes the BCP 47 hyphen form (zh-CN)

Use the wrong format and either og:locale stops working or the hreflang is silently ignored by search engines — no error, they just act as if it weren’t there.

Two Liquid pitfalls

There are two problems you tend to run into when adding languages, and both have to do with how Liquid looks up values and passes arguments.

Pitfall 1: a directory and a file under `_data` are not equivalent

Jekyll data files can be laid out two ways, and they are accessed differently:

_data/text.yml         ← file, accessed as site.data.text
_data/zh/text.yml      ← directory, accessed as site.data.zh.text

That looks symmetrical, but if you write a generic site.data[lang].text, it holds for the directory form and fails for the file form — that would be site.data['en'], a key that simply doesn’t exist, so you get nil.

Liquid renders undefined variables as empty strings without complaining. The symptom is therefore a page with blank text where the links still work fine (the URLs usually come from somewhere else entirely), which makes it painful to track down.

So either use the directory form consistently (_data/en/, _data/zh/), or add a fallback:

{% assign t = site.data[lang].text %}
{% if t == nil %}{% assign t = site.data.text %}{% endif %}

Pitfall 2: `include` and `render` have different scopes

When writing multi-language templates you often need to pass the current language into an include, like this:

{% include nav.html lang=page.lang %}

Here you need to be aware that in Jekyll, include and render follow different scoping rules:

include shares scope — a variable assigned inside the include is still visible in the outer template, and in later sibling includes
render is isolated — it can’t see outer variables by default and only sees the arguments passed to it explicitly

The shared semantics of include are convenient sometimes, but they make it easy to write fragile code: one include depending on another include having run first and assigned some variable. That kind of code breaks when used on its own, breaks when you reorder the includes, and fails silently (Liquid renders undefined variables as empty strings).

So always pass values across includes as explicit arguments, never rely on leakage. If you want to enforce isolation, switch to render (requires Jekyll 4.x, and it requires the include file to live under _includes; it’s also faster).

The language chooser

With the language list in place, you can build a language switcher. The simplest form is a dropdown:

<select onchange="if(this.value)location.href=this.value">
  {% for cand in altlangs %}
    {% assign idx = forloop.index0 %}
    <option value="{{ cand }}"{% if cand == page.url %} selected{% endif %}>{{ altlabels[idx] }}</option>
  {% endfor %}
</select>

Here altlangs is the list of “URLs of this page in the other languages” and altlabels is the matching language name. How to compute them is below.

The key step is working out “the URL of this page in the other languages”.

The idea is: first compute the current page’s path relative to its own language root, then append it to the other language roots.

{% assign rest = page.url %}
{% unless cur.url == '/' %}
  {% assign rest = page.url | remove_first: cur.url | prepend: '/' %}
{% endunless %}

Stripping /zh/ off /zh/imagetrans/ gives /imagetrans/, and appending /ja/ to that gives /ja/imagetrans/. For the root language the prefix is /, so rest is just the original URL.

Don’t offer options for pages that don’t exist

Computing the URLs isn’t enough. If a language doesn’t have this page, it shouldn’t be offered as an option — otherwise clicking through lands on a 404.

So after getting the candidate URL you have to actually look it up:

{% assign found = site.pages | where: "url", cand | first %}
{% if found == nil %}{% assign found = site.documents | where: "url", cand | first %}{% endif %}

You have to check two places: regular pages live in site.pages, while post-like content (_posts and custom collections) lives in site.documents. Checking only site.pages means the chooser is missing options on post pages.

That gives you every language version of this page that actually exists. Only render the whole selector when there is more than one option.

A subtle failure mode

Consider this logic for determining the current language:

{% if l.code == lang %}{% assign is_cur = true %}{% endif %}

If page.lang comes back empty (say a batch of pages forgot to declare lang), then is_cur is false for every language, including the current one itself. The result is that the array may contain only the other languages, size > 1 doesn’t hold, and the entire selector disappears — not just one option missing.

To debug: search the page source for class="language-chooser". If it isn’t there, the array never exceeded one item, so first check whether page.lang is being picked up correctly.

SEO: hreflang

This is the single most important thing in multi-language SEO.

The problem is that /download/, /zh/download/ and /ja/download/ have different content but the same subject. Search engines don’t know they’re the same thing, so they may treat them as duplicate content, diluting each other’s weight, or index only one of them — which means Japanese users searching in Japanese land on the English page.

hreflang is how you declare “these pages are different language versions of the same content”:

<link rel="alternate" hreflang="en" href="https://example.com/download/" />
<link rel="alternate" hreflang="zh-CN" href="https://example.com/zh/download/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/download/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/download/" />

A few points:

It must be an absolute URL, not a relative path
Every language version must declare all the others, not just one side (if A points to B, B must point to A)
x-default points to the fallback version used when no language matches the user, usually the main site

In Jekyll, if site.url isn’t configured (so local preview still works), remember the fallback:

{% assign siteurl = site.url | default: 'https://example.com' %}

Reuse the chooser’s data

The chooser step already computed “which languages this page exists in”, and hreflang wants the same data. So it’s just a matter of collecting one more field in the same loop:

{% for l in site.languages %}
  ...
  {% if is_cur or found != nil %}
    {% assign altlangs = altlangs | push: cand %}
    {% assign altlabels = altlabels | push: l.label %}
    {% assign althreflangs = althreflangs | push: l.hreflang %}
  {% endif %}
{% endfor %}

Then output it in <head>:

{% if altlangs.size > 1 %}
  {% for cand in altlangs %}
    {% assign idx = forloop.index0 %}
  <link rel="alternate" hreflang="{{ althreflangs[idx] }}" href="{{ siteurl }}{{ cand }}" />
  {% endfor %}
  <link rel="alternate" hreflang="x-default" href="{{ siteurl }}{{ englishurl | default: '/' }}" />
{% endif %}

Reusing the same data has a bonus: you never emit hreflang pointing at a page that doesn’t exist. That matters, because a wrong hreflang is worse than no hreflang. If you declare that a page’s Japanese version is at a URL that doesn’t exist, search engines will consider the page’s configuration broken and may discard the correct signals along with the bad one.

Right-to-left languages

Arabic, Hebrew, Persian and Urdu are written right to left. When you add one of these, translating the content isn’t enough — the layout has to mirror too, or the interface feels wrong everywhere.

Step 1: declare the direction

The HTML dir attribute does this:

<html lang="ar" dir="rtl">

As with lang, don’t hard-code it in templates — put it in the language config:

  - code: ar
    label: العربية
    url: /ar/
    locale: ar
    hreflang: ar
    rtl: true

And output it from the field in the template:

<html lang="{{ cur.locale }}"{% if cur.rtl %} dir="rtl"{% endif %}>

This way, adding Hebrew later is just one more rtl: true line in the config, with no template changes.

Step 2: deal with physical direction properties in CSS

This is the biggest and most easily missed part of the RTL work.

dir="rtl" only affects text flow and some default alignment. It does not automatically flip styles that hard-code a direction, and almost every theme uses physical properties heavily:

ul       { margin-left: 2rem; }              /* list indent on the left */
blockquote { border-left: 2px solid #ccc; }  /* quote bar on the left */
th       { text-align: left; }               /* table headers left-aligned */

In an RTL page all of these stay exactly where they were, so list indentation ends up on the wrong side, the quote bar appears opposite the text, and table headers are aligned the wrong way.

There are two ways to fix it.

Option 1: switch to logical properties (the modern approach)

ul         { margin-inline-start: 2rem; }
blockquote { border-inline-start: 2px solid #ccc; }
th         { text-align: start; }

inline-start means “the start of the inline direction” — the left in LTR, automatically the right in RTL. This is the cleanest solution, but it requires going through every physical property in the theme and confirming browser support (newer properties like border-inline-start do nothing in old browsers).

Option 2: override in bulk with attribute selectors (less invasive)

Leave the original styles alone and append a set of overrides at the end of the stylesheet:

[dir="rtl"] ul {
    margin-left: 0;
    margin-right: 2rem;
}
[dir="rtl"] blockquote {
    padding-left: 0;
    padding-right: 1rem;
    border-left: 0;
    border-right: 2px solid #ccc;
}
[dir="rtl"] th {
    text-align: right;
}

This has an extra benefit: the selector is [dir="rtl"], not [lang="ar"], so it applies to all RTL languages at once. Adding Hebrew or Persian later needs no more CSS.

The cost is that the rules are now split across two places, so it’s easy to forget to update the overrides when you change the original styles. Which one to pick depends on whether you’re willing to touch the original theme — if it’s a third-party theme you want to keep upgradable, the second is more practical.

Step 3: keep code blocks left-to-right

This one is often overlooked, but skipping it directly hurts readability.

In an RTL page, if code blocks, URLs, file paths and command-line examples mirror along with everything else, they become nearly unreadable:

# after mirroring (illustrative)
--with-ssl https://example.com/path    →  the path reads backwards

The semantics of this content is “read left to right” regardless of the interface language. So pin it back to LTR:

[dir="rtl"] code,
[dir="rtl"] pre,
[dir="rtl"] kbd,
[dir="rtl"] samp {
    direction: ltr;
    text-align: left;
    unicode-bidi: embed;
}

All three properties matter, none can be dropped:

direction: ltr — declares the direction
text-align: left — alignment does not follow direction automatically, it has to be set separately
unicode-bidi: embed — makes this block its own bidirectional text scope, so it isn’t disturbed by the surrounding RTL context

The unicode-bidi line is especially easy to forget. Without it, mixed punctuation and digits inside code blocks can still get reordered.

Step 4: handle icons and directional symbols

Some characters carry direction in their meaning, and mirroring reverses it:

Arrows: → reads as “back” in an RTL context and should become ← for “forward”
Back/forward buttons: the icons usually need swapping
Progress bars, breadcrumbs: the starting point should visually be reversed

This isn’t something CSS can fix automatically — it has to be handled at the content level.

Conversely, some things should not be mirrored: clock icons, play/pause buttons, logos, numerals. Forcing a mirror on those is just confusing.

Step 5: check standalone pages

As mentioned earlier, standalone HTML pages that don’t go through a layout won’t inherit dir. The site’s root element, standalone tool pages and embedded small apps all need dir="rtl" set individually. This is the most commonly missed piece.

There’s an easy trap here that has nothing to do with RTL but always shows up alongside it.

og:locale uses a language_REGION format, where the region code is an ISO 3166 country code. Arabic as ar has no single region, and AR in ISO 3166 is Argentina — so ar_AR literally means “Arabic (Argentina)”, which is wrong. Use the language’s default region, ar_SA, or just write ar on its own.

The lesson from this trap: don’t guess region codes by intuition, especially for languages spanning many countries like ar, en, es and pt. en_US and en_GB are different regions, as are es_ES and es_MX, and which one to use depends on who your actual target users are.

Result and checks

After the change, every page outputs tags like these:

<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="zh-CN" href="https://example.com/zh/" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

To check, you can look at the page source directly, or run the live pages through Google’s Rich Results Test or a dedicated hreflang validator.

One thing that’s easy to miss: this template only covers pages that go through a layout. If the site has fully hand-written HTML pages that bypass the default layout, they won’t get these tags automatically and have to be handled separately.

A few smaller points

The sitemap needs no attention. If you’re using jekyll-sitemap, newly added language pages are picked up automatically with no manual maintenance, and the sitemap it generates carries hreflang information itself.

<html lang> has to be correct. This uses the locale field — don’t mix up the format with hreflang. RTL languages also need dir output alongside it, see above.

When the content isn’t ready, prefer leaving it empty. If a language’s translations aren’t done yet, the corresponding listing pages (blog, tags) should show an empty list rather than being padded out with content from another language — that just shows users a pile of headlines they can’t read, and the bounce rate ends up dragging down that directory’s weight. Add content once the translation exists; the template will display it automatically.

Machine-translated pages should be labelled. If a language is machine-translated, flag it in the config, show a notice bar on the page and link to the source language. It’s honest, and it stops users from misjudging the quality of the translation. The implementation is simple: one more field in the config and a check in the template.

Summary: Make languages config data and let templates do nothing but look things up. The language chooser and hreflang reuse the same computation of “which language versions of this page exist” — so adding a language means touching only the config and the content, never the templates. RTL languages take one extra step: mark rtl: true in the config, then add a set of [dir="rtl"] selector overrides, and every right-to-left language from then on shares them.

Arabic and Other Bidirectional Text Support in an OCR Tool

Thu, 17 Sep 2026 07:30:00 +0000

Arabic, Hebrew and Persian are written from right to left, while the Arabic numerals and Latin words mixed into them are read the normal left-to-right way. That is why they are called bidirectional text. Furthermore, the actual glyphs displayed for Arabic characters depend on the context — that is, the surrounding characters — resulting in changes such as ligatures and overlaps. This is known as complex text. When image OCR and translation software runs into these languages, it has to deal with an extra set of problems: how the interface displays the text, how to restore the character order of the OCR output, how to join words into lines in the correct order, and how to lay text out in reading order when exporting a PDF.

This article describes how ImageTrans handles these.

Interface display and text rendering

A JavaFX Node has a nodeOrientation property. Once you set it to RIGHT_TO_LEFT, JavaFX takes care of text alignment, cursor movement direction, and which side punctuation falls on, with no manual intervention needed.

ImageTrans sets this property on every control that displays bidirectional text, including the source text box, the target text box, and the typesetting engine.

Besides display, there is also a project setting for right-to-left reading, which affects ordering.

In an Arabic paragraph, the first word is at the far right. If we sort the usual way, from smallest to largest X coordinate, the reading order of the whole paragraph comes out completely reversed. So this switch is passed to several modules involved in sorting and merging:

Text box sorting
In-line box sorting
Panel detection
Box merging

Character handling in OCR

ImageTrans uses the PaddleOCR family of models (integrated through RapidOCR). When these models recognize Arabic, what they output is in visual order — they scan the image pixels from left to right.

Visual order means the actual writing order of the letters is reversed, but digits, which are already laid out from left to right visually, come out in the correct order.

So a reversal is needed, one that preserves digit runs:

A pure digit string: return it as is
Everything else: reverse the whole string first, then flip each run of consecutive digits back

For example, م٢٠٢٦ should be restored to ٢٠٢٦م.

At the same time, a bracket mirroring pass swaps left and right brackets.

Other OCR engines, however, do not need this.

Joining words into lines: right to left

What OCR produces is a pile of word boxes, which first have to be merged into lines and then into paragraphs.

Merging works by starting from a seed box and repeatedly swallowing adjacent boxes in some direction. Which direction to try first is reversed for Arabic:

growRightFirstRound = True              ' try right first by default
If right2left And horizontal Then
    growRightFirstRound = False         ' for Arabic, try left first
End If

It first gathers the words of the same line going left; when this round can no longer grow, it tries the other direction; when neither direction can grow, the line is finished.

But the merge direction alone is not enough. There is one kind of mixed-script case that needs separate handling.

An Arabic line merges from right to left, and that order is correct for Arabic words, but Latin text embedded in the line must stay left to right — otherwise a hello world comes out of the merge as world hello.

So when the end of the first box carries two or more non-Arabic letters and the second box is not an Arabic word either, the two boxes are taken to belong to the same LTR text run and their order needs to be swapped. In implementation, the tail segment of the first box is cut off and appended to the second box:

source1 = source1 without the tail  +  " "  +  source2  +  tail
source2 = ""

For instance, if the first box is world and the second is hello, after processing they are restored to hello world.

Exporting PDF: shape and reverse

This is the hardest step.

PDF itself does no complex text layout. When PDFBox’s showText gets a string, it looks up each Unicode code point in the font’s cmap one by one and draws the glyph it finds. It does not handle Arabic contextual shaping — the fact that the same letter has a different shape at the beginning, middle or end of a word, or standing alone. PDFBox will not do that for you.

So ImageTrans does two steps of its own.

The first step is shape: replace each letter with the variant it takes at its current position. Unicode has an “Arabic Presentation Forms” block (U+FE70–FEFF) set aside for exactly these variant glyphs. For example, ت standing alone is FE95, at the beginning of a word it is FE97, in the middle FE98, and at the end FE96. The decision rests on whether the neighbouring letters can join — letters such as ا, د and ر can only join to the preceding letter, never to the following one.

The second step is reverse: the product of the previous step is a string of “glyph codes” rather than “characters”. Character order is logical order, whereas glyph code order has to be visual order — the order in which they are drawn on the page. So the whole string is turned around, so that drawing it from left to right comes out right.

The reversal has a pitfall: digits must not be reversed along with it. So this is not a simple one-step reversal but a per-word process, splitting on spaces:

Pure digit words: put back as they were
Arabic words: keep, but flip each run of consecutive digits inside the word
Other words (Latin words and so on): collect them into a group and reverse the group as a whole

Finally the brackets are mirrored once more and the direction control characters are stripped, and only then is it handed to PDFBox to draw.

Font requirements

This approach depends on the font carrying the presentation form glyphs in U+FE80–FEFC. Common system fonts such as Arial, Tahoma and Segoe UI have them (for historical reasons, for compatibility with old software). But some fonts do not, such as Windows’ own Arabic Typesetting, which will simply throw an error on export.

Searchability

There is an unexpected benefit: although what is stored in the PDF is presentation form glyphs, what gets copied out is ordinary Arabic text.

The reason is that text extraction applies NFKC normalization to each word, and NFKC happens to compatibility-decompose U+FE70–FEFF back into the base letters. This is standard behaviour, not something specific to any one library, so the same holds in other PDF readers. So the exported PDF both displays correctly and can be copied and searched.

Known limitations

The font must contain the presentation form glyphs (U+FE80–FEFC), otherwise the export will fail. If your font runs into this problem, just switch to one with full coverage.
If the source text carries diacritics (harakat), they enter the text layer along with everything else. Searching may then require including the diacritics to match exactly; the exact behaviour depends on the reader’s implementation.
Ligatures (such as لا) are currently assembled from two joined glyphs. The visual result is close, and extraction restores them correctly as two letters.

Bidirectional and Complex Text List

The following table combines bidirectionality and complexity, marking each dimension with “Yes/No”.

Language/Script	Bidirectional Text (RTL/LTR mixing)	Complex Text (contextual shaping/reordering)	Main Region	Key Characteristics
Arabic	Yes	Yes	Middle East, North Africa	RTL direction; letters take initial/medial/final/isolated forms, with ligatures
Hebrew	Yes	Yes	Israel	RTL direction; vowel marks (niqqud) require positioning, often mixed with English
Persian (Farsi)	Yes	Yes	Iran	Arabic script variant, RTL, contextual shaping
Urdu	Yes	Yes	Pakistan, India	Arabic script, RTL, contextual shaping
Uyghur	Yes	Yes	Xinjiang, China	Arabic script, RTL, contextual shaping
Syriac	Yes	Yes	Parts of the Middle East	RTL; complex ligatures and vowel marks
Dhivehi (Thaana)	Yes	No	Maldives	RTL direction; glyphs are largely independent, no complex shaping
Yiddish	Yes	Yes	Global Jewish communities	Written in Hebrew script, RTL; vowel mark positioning
Kurdish	Yes	Yes	Iraq, Syria, etc.	Some dialects use Arabic script, RTL, contextual shaping
Sindhi	Yes	Yes	Pakistan, India	Arabic script, RTL, contextual shaping
Hindi (Devanagari)	No	Yes	India	LTR; consonant clusters, vowel sign reordering
Bengali	No	Yes	Bangladesh, India	LTR; consonant clusters and shaping rules
Tamil	No	Yes	South India, Sri Lanka	LTR; consonant-vowel combinations and ligatures
Thai	No	Yes	Thailand	LTR; stacked vowels, tone mark positioning
Tibetan	No	Yes	Tibet, Qinghai, etc., China	LTR; stacked consonants, vowel sign shaping
Mongolian (Traditional)	No	Yes	Inner Mongolia (China), Mongolia	Vertical writing; initial/medial/final shaping (direction differs from RTL, it is vertical)
Khmer	No	Yes	Cambodia	LTR; complex consonant clusters and vowel reordering
Burmese	No	Yes	Myanmar	LTR; complex shaping similar to Khmer
English, Chinese, etc.	No	No	Global	Basic LTR, characters and glyphs largely one-to-one

Key Points

Dedicated shaping libraries like HarfBuzz and bidirectional algorithm libraries can support the processing of various languages. Here are some key points.

Bidirectional ⊂ Complex, but not fully overlapping: Arabic, Hebrew, etc. are both bidirectional and complex; Dhivehi is bidirectional but not complex; Tibetan, Thai are complex but not bidirectional.
Scope of HarfBuzz: All languages marked “Complex = Yes” can receive shaping support from HarfBuzz (glyph selection, ligatures, positioning).
Scope of Bidi algorithms: All languages marked “Bidirectional = Yes” require additional Bidi algorithms (such as ICU, FriBidi) for direction segmentation; HarfBuzz itself does not do this.
Special case of Mongolian: Traditional Mongolian is written vertically, and its direction is neither standard LTR nor RTL, but it is still complex text, and HarfBuzz also supports its contextual shaping.

Use a Self-Hosted ImageTrans Server with a Self-Signed Certificate on iOS

Wed, 16 Sep 2026 12:37:50 +0000

In a previous post, I explained how to use the Orion Browser on an iPhone together with an ImageTrans server and the ImageTrans browser extension to translate images on web pages.

This post covers the actual setup. Here is what you need to do.

On your computer:

In ImageTrans, go to Preferences - Server and generate a self-signed certificate. Make sure to fill in the correct LAN address of your computer.
Start the local server from the Server menu.
Click the LAN link in the server window to show a QR code, then scan it with your phone to open the server. If the IP is wrong, find the correct LAN IP yourself and enter the address manually, for example https://192.168.0.169:51043.

On your phone:

Once the page is open, find the line that says Install self-signed cert and click it to download the certificate.
Open Settings. You will see a “Profile Downloaded” option. Open it and install the downloaded certificate.

After that, the installed certificate will appear under VPN & Device Management.
Next, go to Settings - General - About - Certificate Trust Settings and turn on trust for this certificate.
Open Orion Browser, go to the ImageTrans extension settings, and set the server address to the LAN IP address of your computer, for example https://192.168.0.169:51043. Replace 192.168.0.169 with your own IP. It is usually the address shown in the server’s QR code; if it is wrong, find the correct IP yourself.
Choose ImageTrans as the translation method, and you can start translating.

You can use the intranet penetration service provided by ngrok to perform translation on your home computer when you are outside. Since ngrok provides an HTTPS certificate, the certificate installation steps above can also be skipped.

How to Translate Japanese Manga Sound Effects

Sun, 13 Sep 2026 08:12:50 +0000

Japanese makes heavy use of onomatopoeia and mimetic words — they make the language vivid, but they also pose plenty of challenges for translators.

Below we list Japanese onomatopoeia and mimetic words by category, together with reference translations in both Chinese and English.

Common Onomatopoeia and Mimetic Words

1. 擬音語 (Giongo) — Imitating Real Sounds

Animal Calls

Japanese	Reading	Chinese	English
ワンワン	wanwan	汪汪	woof woof
ニャーニャー	nyānyā	喵喵	meow meow
モーモー	mōmō	哞哞	moo moo
コケコッコー	kokekokkō	咯咯咯	cock-a-doodle-doo
ケロケロ	kerokero	呱呱	ribbit ribbit
チューチュー	chūchū	吱吱	squeak squeak
ヒヒーン	hihīn	咴咴	neigh

Nature and Weather

Japanese	Reading	Chinese	English
ザーザー	zāzā	哗哗（大雨）	pouring
シトシト	shitoshiro	淅淅沥沥	drizzling
ゴロゴロ	gorogoro	轰隆隆	rumble
ピカピカ	pikapika	一闪一闪	flash / sparkle
ヒュー	hyū	呼——（风声）	whoosh
ポツポツ	potsupotsu	滴滴答答	pitter-patter
パラパラ	parapara	噼里啪啦（小雨）	sprinkling

Objects and Actions

Japanese	Reading	Chinese	English
バン	ban	砰	bang
ドカーン	dokān	轰	boom
ガシャーン	gashān	哗啦（碎裂）	crash / smash
ドンドン	dondon	咚咚	thump thump
カチカチ	kachikachi	咔哒咔哒	tick-tock / clatter
シュッ	shu	嗖	swish
パチパチ	pachipachi	噼啪 / 啪啪（鼓掌）	crackle / clap
ゴトゴト	gotogoto	咕咚咕咚	rattle
ガタガタ	gatagata	嘎吱嘎吱 / 哐当	clatter / rattle

2. 擬態語 (Gitaigo) — Describing States and Appearances

Visual States

Japanese	Reading	Chinese	English
キラキラ	kirakira	闪闪发光	sparkle / glitter
ピカピカ	pikapika	亮晶晶	shiny / gleaming
フワフワ	fuwafuwa	软绵绵 / 蓬松	fluffy / soft
ツルツル	tsurutsuru	滑溜溜	smooth / slippery
ザラザラ	zarazara	粗糙	rough / gritty
ベトベト	betobeto	黏糊糊	sticky
グチャグチャ	guchagucha	乱七八糟 / 黏糊糊	messy / squishy
ボロボロ	boroboro	破破烂烂	worn-out / tattered
ツヤツヤ	tsuyatsuya	油光发亮	glossy
カラカラ	karakara	干巴巴	dry / parched

Manner and Movement

Japanese	Reading	Chinese	English
ゆっくり	yukkuri	慢慢地	slowly
そっと	sotto	轻轻地 / 悄悄地	gently / quietly
じっと	jitto	一动不动 / 盯着	still / staring
ぐっすり	gussuri	酣睡	soundly
ふらふら	furafura	摇摇晃晃 / 晕乎乎	dizzy / wobbly
ぶらぶら	burabura	溜达 / 闲逛	strolling / wandering
ゴロゴロ	gorogoro	懒洋洋地躺	lazing around
パクパク	pakupaku	大口大口（吃）	munching
ペラペラ	perapera	流利（说话）	fluently
ドサドサ	dosadosa	哗啦哗啦（倒下）	thudding

3. 擬情語 (Gijōgo) — Describing Feelings and Emotions

Japanese	Reading	Chinese	English
ドキドキ	dokidoki	扑通扑通 / 心怦怦跳	thump thump
ワクワク	wakuwaku	兴奋不已	excited / thrilled
イライラ	iraira	烦躁 / 心急火燎	irritated / frustrated
ムカムカ	mukamuka	恶心 / 火冒三丈	annoyed / queasy
ウキウキ	ukiuki	兴高采烈	cheerful / buoyant
ハラハラ	harahara	提心吊胆	anxious / on edge
グスン	gusun	抽泣 / 吸鼻子	sniffle
ニコニコ	nikoniko	笑眯眯	smiling
クヨクヨ	kuyokuyo	闷闷不乐 / 纠结	moping / brooding
ズキズキ	zukizuki	一阵阵刺痛	throbbing
ソワソワ	sowasowa	坐立不安	restless / fidgety
ガッカリ	gakkari	失望 / 泄气	disappointed

Translation Methods

Japanese has an enormous number of onomatopoeic and mimetic words, and many of them have no ready-made equivalent in Chinese or English. Translators therefore usually fall back on two core strategies: replacing them with an onomatopoeic word, or rendering them descriptively.

1. Replacing with an Onomatopoeic Word

Find an onomatopoeic word in the target language that matches the original. There are two ways to do this.

1.1 Use an Existing Onomatopoeic Word in the Target Language

If the target language has an onomatopoeic word close in meaning and feel, simply substitute it.

Japanese	Chinese	English
ドキドキ	扑通扑通	Thump thump / Ba-dump
バン	砰！	BAM!
ドカーン	轰！	BOOM!
シュッ	嗖！	Swish
ワンワン	汪汪	Woof woof
ニャーニャー	喵喵	Meow meow
ザーザー	哗哗	Pouring
ガシャーン	哗啦！	Crash!

1.2 Transliteration (Romaji) Plus a Gloss

If no suitable onomatopoeic word exists in the target language, or you want to keep the Japanese flavor, you can keep the romaji transliteration and add a gloss to convey the meaning. This approach is very common in fan translations.

Japanese	Chinese	English
ドキドキ	多基多基（心跳声）	Doki doki (heartbeat)
ギャー	嘎——！（惨叫）	Gyaaah! (scream)
ワクワク	哇库哇库（兴奋）	Waku waku (excitement)

2. Rendering Descriptively

If there is no matching onomatopoeic word and a transliteration would only get in the way of understanding, describe the sound, state or action in ordinary words. This is the usual approach for gitaigo and gijōgo.

Japanese	Chinese	English
しっとり	轻轻地 / 柔和地	softly
じっと	一动不动地盯着	staring intently
そっと	悄悄地 / 轻轻地	quietly / gently
ぐっすり	沉沉地（睡着）	soundly
シーン	一片寂静	silence
ニコニコ	笑眯眯	smiling
ワクワク	兴奋不已	excited

A Real Example

Now that we have seen the examples above, let’s translate an actual image, taken from volume 18 of Detective Conan.

Sound effect	Position	Chinese	English	Approach
ガラ	Top right	哗啦 / 嘎啦	Clack / Rattle	Onomatopoeic replacement
ワー	Middle panel	哇——！	Waah!	Onomatopoeic replacement
スタ (×3)	Bottom left	嗒、嗒、嗒	Tap, tap, tap	Onomatopoeic replacement

In practice you’ll find that these are not always familiar four-kana sound effects — the author builds them on common expressions. That is when you have to translate flexibly.

Typesetting the Result

Below we use the computer-aided comic translation software ImageTrans to remove the text from the original image and put the translation back in.

The cleaned image with the text removed (using Lama Inpaint):

Our English version:

The official English translation:

I’ve included the official translation here as well. As you can see, it translates the sound effects too, though the words it uses seem to be made up.

How to Determine the Reading Order of Text in an Image

Sun, 13 Sep 2026 03:38:50 +0000

Text in an image has to go through OCR before it can be extracted. After that, it usually still needs to be sorted into reading order. PDFs have a similar need: even though the text can be copied, it takes sensible ordering by the PDF viewer to support selecting, copying and searching continuous runs of text. This article mainly demonstrates how the computer-aided image translation software ImageTrans handles the text order in various kinds of images.

For ordinary paragraph text, where lines are simply stacked one after the other, things are easy: just sort by the Y coordinate.

For vertical text such as Japanese light novels, we instead sort by the X coordinate, and from right to left.

But real-world images are often far more varied.

Japanese manga, for example, requires determining the reading order of the panels first, and then the reading order of the text. This needs ImageTrans’s panel detection feature.

Academic papers are another case. They require layout analysis to deal with two-column layouts, figures and tables, and other page elements. Layout analysis models such as PaddleOCR’s PPDocLayout v3 are needed here. This model comes with its own reading order detection, though not every result is correct, and occasionally you have to fix it manually in the software.

If the layout detection method you choose does not support reading order detection, we need to use another sorting method, such as XYCut.

There are also many complex images, such as the infographic below, in which the listed items are ordered clockwise. Only a vision-capable large language model can handle this.

But since large language models cannot return coordinates directly, we also need a suitable prompt that matches the order they give with the text at the corresponding coordinates.

How to Detect Rotated Text in an Image

Sun, 13 Sep 2026 03:38:50 +0000

Text in an image may be tilted. Sometimes this is a deliberate design choice, and sometimes it happens because a document was not placed straight when it was scanned.

Most OCR engines today can handle rotated text. PaddleOCR, for example, uses the DB algorithm to produce a binary image, and from that image we can get each line of text together with the coordinates of its four corner points and its rotation information.

The computer-aided image translation software ImageTrans supports all kinds of OCR that handle rotated text.

The interface:

The binary image:

Image source: https://ac.qq.com/ComicView/index/id/547921/cid/1

Knowing the rotation angle is useful in more than one way: it can be used for document deskewing, and for restoring the rotation angle when translating an image.

The text in the example image, however, is distorted by a perspective transformation, so for real translation work it is still better to edit the original PSD file. ImageTrans can export the recognized text to PSD, or modify the text in a PSD directly.

OCR engines with rotation support in ImageTrans:

WinRT (the OCR built into Windows 10 and later)
rapid
PaddleOCR
mangaTranslator
macOCR (the OCR built into macOS)
oneocr (the OCR built into the Windows 11 Snipping Tool)

90-degree rotation

One kind of rotation is special: a 90-degree rotation. When Western letters are set vertically, the text has to be rotated 90 degrees, and its angle can no longer be calculated simply from the coordinates of the four corner points. You can detect it with an orientation detection model, or just work it out from the aspect ratio: if the height divided by the width is greater than, say, 1.2, treat it as a 90-degree rotation.

Turn Scanned Documents into Searchable PDFs with a Text Layer

Wed, 02 Sep 2026 13:19:50 +0000

Scanned documents are usually single-layer, pure-image PDFs whose text cannot be selected, copied or searched. In this case, we can create a two-layer PDF, by putting a hidden text layer over the images, so that when the PDF is opened in a PDF viewer, the text inside it can be searched and copied.

For example, the PDF below shows a part of the Japanese light novel Mushoku Tensei (source). The text inside is vertical, read from right to left, and has already been extracted and turned into a two-layer PDF.

Let me explain how this is done step by step. We need ImageTrans, an OCR software.

Open ImageTrans, create a new project, and import the PDF or images.
Choose an OCR engine, such as PaddleOCR (named rapid in ImageTrans), to recognize the text. If the recognition result is not accurate, we can first use PaddleOCR or other methods to locate the text, and then use large models such as PaddleOCR-VL and minerU, or a dedicated vertical-up Japanese model such as mit48px ctc, to recognize the text.
Sort the recognized text according to the reading order. Here we just need to enable right-to-left reading mode and sort by the X coordinate in the project settings. If the layout is complex, e.g., with multiple columns, we can run document layout analysis with software like minerU and PPDocLayout before sorting.
Detect which text is horizontal and which text is vertical. We need to define two font styles in the project settings, one for horizontal text and one for vertical text. Then run the “Detect text direction and apply the corresponding style” workflow in the custom workflow.
In the menu bar, click Export -> Raster PDF. Use the original images, add a text layer with the source text, and choose a font that contains Japanese characters, such as C:\Windows\Fonts\arial unicode ms.ttf on Windows, a font that covers nearly all languages.

After saving, we get a PDF like the one above. The software will automatically work out an appropriate font size so that the text in the text layer fits the text in the images as well as possible.

Open it in Edge, and the text can be correctly selected, copied and searched.

The ImageTrans interface:

ImageTrans can also further translate the images, giving us the following Chinese searchable two-layer PDF.

About Adding a Vertical Text Layer

PDF’s native support for vertical text is weak. When creating the text layer, we need to add characters one by one in reading order. I have tried it, and common PDF viewers can all display vertical text added in this way.

How ImageTrans Optimizes Processing Speed and AI Models

Tue, 01 Sep 2026 12:08:50 +0000

ImageTrans is only 400 MB in size, yet it bundles PaddleOCR supporting over a hundred languages, a dedicated Japanese manga OCR, the mit48px_ctc OCR model with color recognition, YOLO text/bubble detection models, and the inpainting model Lama Inpaint. No GPU is required — it fully utilizes the CPU, and translating an image usually takes under 10 seconds.

Below are some of the optimization methods used.

Model Quantization

Take the manga-ocr model: the original FP32 version is about 400 MB, while the int8-quantized version is only about 100 MB, with virtually no loss in recognition performance.

Lama inpaint and mit48px ctc both use quantized versions.

Splitting the Transformer Model

manga-ocr is a Transformer model. It is split into encoder and decoder versions, allowing the encoder’s output to be reused and improving processing performance.

Multiprocessing

When processing many images, multiple processes can be used to fully utilize the CPU.

GPU/NPU Acceleration

If the device has a GPU or NPU, it can also be used to accelerate computation.

On Apple devices, models can be converted to mlx or coreml versions, and processing is very fast. ImageTrans provides a coreml version of Lama Inpaint and an mlx version of PPDocLayout v3. It also supports using Pytorch with mps enabled to accelerate OCR with Metal.

On Windows, if you have an Nvidia graphics card, you can also use the Pytorch versions of OCR and Lama inpaint to offload computation.

Performance Testing

Below are the results of translating various images on a MinisForum 760 Plus (AMD Ryzen 5 7640HS).

Black and White Manga

Original:

Translated:

Processing time:

{
    "workflows": [
        {

            "duration_ms": 4323,
            "start_time": "08\/31\/2026 20:58:58",
            "name": "default",
            "steps": [
                {
                    "duration_ms": 2344,
                    "action": "Text detection"
                },
                {
                    "duration_ms": 39,
                    "action": "Merge areas"
                },
                {
                    "duration_ms": 14,
                    "action": "Sort"
                },
                {
                    "duration_ms": 1437,
                    "action": "Translate"
                },
                {
                    "duration_ms": 489,
                    "action": "Generate translated images"
                }
            ]
        }
    ]
}

Color CG

Original:

Translated:

Processing time:

{
    "workflows": [
        {
            "duration_ms": 8703,
            "start_time": "08\/31\/2026 20:48:47",
            "name": "default",
            "steps": [
                {
                    "duration_ms": 236,
                    "action": "Text detection"
                },
                {
                    "duration_ms": 1575,
                    "action": "Generate masks and text-removed images for all images"
                },
                {
                    "duration_ms": 16,
                    "action": "Shrink areas"
                },
                {
                    "duration_ms": 3815,
                    "action": "Text recognition"
                },
                {
                    "duration_ms": 1,
                    "action": "Set stroke color based on text color depth"
                },
                {
                    "duration_ms": 72,
                    "action": "Match style based on stroke color"
                },
                {
                    "duration_ms": 55,
                    "action": "Merge areas"
                },
                {
                    "duration_ms": 22,
                    "action": "Sort"
                },
                {
                    "duration_ms": 1759,
                    "action": "Translate"
                },
                {
                    "duration_ms": 1152,
                    "action": "Generate translated images"
                }
            ]
        }
    ]
}

Chinese Manhua

Original:

Translated:

Processing time:

{
    "workflows": [
        {
            "duration_ms": 3298,
            "start_time": "08\/31\/2026 21:05:34",
            "name": "default",
            "steps": [
                {
                    "duration_ms": 1024,
                    "action": "Text detection"
                },
                {
                    "duration_ms": 0,
                    "action": "Remove areas without source text from all images"
                },
                {
                    "duration_ms": 55,
                    "action": "Merge areas"
                },
                {
                    "duration_ms": 14,
                    "action": "Sort"
                },
                {
                    "duration_ms": 1736,
                    "action": "Translate"
                },
                {
                    "duration_ms": 468,
                    "action": "Generate translated images"
                }
            ]
        }
    ]
}

BasicCAT — Computer-Aided Translation (CAT) Tools

9 Manga Translation Tools Tested and Compared: AI Translation Plus Manual Editing, Which One Fits You

What Manga Translation Tools Are For, and How to Judge Them

Technical Details Behind Manga Translation Tools

Text Recognition

Text Removal

Text Translation

Lettering

Technology Stacks

Basic Information on the Nine Manga Translation Tools

The Tools, One by One

ImageTrans

BallonsTranslator

Comic-Translate

Koharu

Manga-Translator-UI

Saber Translator

Nekotranslator

ComiTrans

Dango Translator

Conclusion

Improving the Availability of the ImageTrans Remote Translation Service

Dispatching on the server

Process isolation on the client

Problems found

Workarounds

Multi-Language Jekyll Sites and SEO

Start with config

locale and hreflang are two separate fields

Two Liquid pitfalls

Pitfall 1: a directory and a file under _data are not equivalent

Pitfall 2: include and render have different scopes

The language chooser

Don’t offer options for pages that don’t exist

A subtle failure mode

SEO: hreflang

Reuse the chooser’s data

Right-to-left languages

Step 1: declare the direction

Step 2: deal with physical direction properties in CSS

Step 3: keep code blocks left-to-right

Step 4: handle icons and directional symbols

Step 5: check standalone pages

A related side effect: hreflang and og:locale

Result and checks

A few smaller points

Arabic and Other Bidirectional Text Support in an OCR Tool

Interface display and text rendering

Character handling in OCR

Joining words into lines: right to left

Exporting PDF: shape and reverse

Font requirements

Searchability

Known limitations

Bidirectional and Complex Text List

Key Points

Use a Self-Hosted ImageTrans Server with a Self-Signed Certificate on iOS

External Network Sharing

How to Translate Japanese Manga Sound Effects

Common Onomatopoeia and Mimetic Words

1. 擬音語 (Giongo) — Imitating Real Sounds

Animal Calls

Nature and Weather

Objects and Actions

2. 擬態語 (Gitaigo) — Describing States and Appearances

Visual States

Manner and Movement

3. 擬情語 (Gijōgo) — Describing Feelings and Emotions

Translation Methods

1. Replacing with an Onomatopoeic Word

1.1 Use an Existing Onomatopoeic Word in the Target Language

1.2 Transliteration (Romaji) Plus a Gloss

2. Rendering Descriptively

A Real Example

Typesetting the Result

How to Determine the Reading Order of Text in an Image

How to Detect Rotated Text in an Image

90-degree rotation

Turn Scanned Documents into Searchable PDFs with a Text Layer

About Adding a Vertical Text Layer

`locale` and `hreflang` are two separate fields

Pitfall 1: a directory and a file under `_data` are not equivalent

Pitfall 2: `include` and `render` have different scopes