Following up on my experience with bidirectionality in Kagi Translate, here is a short guide for translating English + Hebrew texts into French + Hebrew, without modifying the Hebrew (Ashuri) phrases. Having both RTL and LTR in the same text requires very specific processing before running it through Kagi Translate. Creating a translation pipeline simplifies the process and makes the resulting translations more reliable!
Translating mixed English/French + Hebrew (RTL) texts with Kagi Translate — a proven semi-automated pipeline.
The problem : Kagi Translate is excellent for English → French translation. But when the source text contains Hebrew phrases, a directionality problem arises: the engine reverses the word order of the phrase, and sometimes even the letter order within words. French and English are written left-to-right (LTR), Hebrew right-to-left (RTL) — this directional collision produces unusable results if the Hebrew goes through the translation engine.
The solution: never let the Hebrew go through the engine
The principle is simple: extract the Hebrew phrases from the text, replace them with placeholder tags, translate the tagged text, then re-inject the original Hebrew — untranslated, in biblical script (ashuri) — into the final document.
The pipeline, step by step :
1. Splitting — the source file is segmented into blocks of fewer than 18,000 characters (a safety margin below the Kagi Translate limit), preferably cutting between paragraphs.
2. RTL detection — each block is scanned using the Hebrew Unicode range (U+0590–U+05FF) to locate phrases.
3. Tagging — phrases are logged in a lookup table and replaced with unique per-block tags (e.g. [HEB_B03_01]).
4. Export to Kagi Translate — the tagged block is prepared for submission (this step can be automated).
5. Manual copy-paste retrieval — the user copies the translated text from Kagi Translate and pastes it into the application. This is the key point: automating retrieval is forbidden by Kagi, on pain of account exclusion. Only the official Kagi API allows full automation.
6. Re-injection — tags are replaced with the original Hebrew phrases.
7. Iteration — next block, until the last one.
8. Final export — the document is generated as .docx.
Measured results
This pipeline is highly reliable:
• Hebrew phrases are preserved exactly as-is (since they never go through the engine);
• English → French translations are of high quality;
• relative to the total word count, rework is below 100 ppm (translated words).
Only human proofreading can eliminate this residual error rate — roughly 1 word to fix per 10,000.
Golden rules for a successful development
Work in project mode, never "all at once"
This is the most important lesson from this experience. A coding AI (VS Code + Copilot or equivalent) will readily offer to generate the whole program in one shot — and it does it very badly. Proceed like building an ocean liner: block by block, validating each step before moving to the next. One validated splitting module, then one validated RTL detection module, then tagging, and so on.
Semi-automation only
• ✅ Allowed: automating preparation (splitting, detection, tagging), re-injection, and final export.
• ✅ Allowed: retrieving the translated text via the user's manual copy-paste.
• ❌ Forbidden: automating data retrieval from the Kagi Translate interface (scraping), on pain of exclusion.
• ✅ Allowed: full automation through the official Kagi API — but it costs API credits, hence the value of manual copy-paste for standard subscription use.
Recommended environment
• Visual Studio Code with a coding-specialized AI (this pipeline took 2 days to build in that environment);
• Python for local file processing;
• Hebrew remains in ashuri script (untranslated) in the final document — make sure the .docx rendering correctly preserves RTL directionality.
