It started with an InDesign manual going from English into Traditional Chinese: 1,139 segments and 22 minutes, twelve of them spent in a quality-check pass that the file’s settings said was switched off. Settings that are ignored are worse than settings that do not exist, so we went looking.
Two engines, one name
Fily has two ways to run a file. The current pipeline, which our CAT formats, Word and PDF moved to over the summer, has its own translation loop, its own checks and respects every setting in the profile. The older path is the one everything ran on before that.
Eleven formats had been given the new pipeline’s name and its settings file, but never its loop: InDesign, PowerPoint, HTML, Markdown, plain text, JSON, subtitles, gettext PO, XLIFF 2.0 and two flavors of Excel. With no loop of their own, they fell back to the old one. The old one runs its quality pass unconditionally, so the “off” switch in the profile did nothing.
We moved the current pipeline’s loop into a shared runner and pointed all eleven formats at it. Each format keeps its own parser and its own way of putting the file back together; what changed is everything in between. Then we ran every format through it, from a three-line text file to a 10 MB PowerPoint, and checked that each came back valid and intact.
Then it got slower
On the current pipeline, the InDesign job took 24 minutes. The log explained why: almost every chunk was being retried, because almost every segment was flagged “number changed”.
The check compares the numbers in the source with the numbers in the translation. It found numbers using word boundaries, and in Chinese, Japanese and Korean there are no spaces between a number and the characters around it. In “2004年” or “第19頁”, the check found no number at all, concluded the translation had lost it, and asked for the whole chunk again.
This was not specific to InDesign. Every format on the current pipeline did it for every CJK job, roughly doubling their time and cost. The output was correct, which is why nobody noticed: a retry that produces the same good answer looks like nothing at all.
The check now finds numbers by what surrounds them, not by word boundaries. We ran it against our existing Latin-script test cases and all 22 behaved exactly as before.
The result
- The InDesign manual: 22 minutes before, 11 minutes after, with zero retries.
- It came back with every one of its 1,268 text runs; the old path had been dropping a couple.
- The quality pass runs when the profile says it runs.
- Chinese, Japanese and Korean jobs in every current-pipeline format no longer pay for work twice.
Two quiet bugs, each invisible on its own because the files came back right. We found both by asking why a correct job was slow.
Want this in your workflow? Try Fily with one file — no card, no demo form.