fix: compare unchanged translation against translate_input.unicode
post_translate_paragraph compares the translated string with the TranslateInput object:
if translated_text == translate_input:
A str never equals a TranslateInput, so the unchanged-output branch is unreachable even when the translator returns translate_input.unicode verbatim. The paragraph is then re-typeset through parse_translate_output, dropping its original layout objects, and set_placeholder_full_match() is never called on the LLM tracker.
This is the direct type mismatch described in #610.
Fix: compare against the string payload (translate_input.unicode), consistent with the surrounding code in the same file (pre_translate_paragraph sets text = translate_input.unicode).
Verification — extracted TranslateInput and post_translate_paragraph from the patched file and ran both conditions against a stub tracker/paragraph:
- old condition, output == input → returns
True, layout rebuilt (the unreachable-branch bug) - new condition, output == input → returns
False, layout preserved - new condition, output != input → returns
True(unchanged behaviour)
ruff check, ruff format --check and py_compile pass on the modified file.
Refs #610
Summary by cubic
Fixes the unchanged-output branch in post_translate_paragraph so verbatim translations preserve the original layout instead of being re-typeset.
Previously the branch compared a str against a TranslateInput object, so it was unreachable even when the translator returned the input unchanged. The comparison now targets translate_input.unicode, matching how pre_translate_paragraph extracts the string, which also lets the LLM tracker's set_placeholder_full_match() fire correctly.