Root cause of 24-min translation: frontend default chunk_size was 1000
(upstream xunbu default), producing 78 requests for the client's WI
document (verified by running segments2json_chunks on the real file:
1000 -> 78 chunks, matches server log's '75 requests').
- index.html: default chunk_size 1000 -> 6000 (78 -> 13 requests, 6x
fewer). 6000 is safe vs qwen3.6-plus 8-16K output limit, and gives
the LLM MORE context (better terminology consistency). Slider range
already allows up to 12000.
- segments_agent.py: log segment count / total chars / chunk_size /
expected request count after chunking, so 'slow translation' reports
can be diagnosed instantly (doc structure vs chunk size vs API latency).
Two changes to finish off the slow-translation issue:
1. agent.py: log the resolved thinking config at Agent init. Lets
operators confirm from task logs that the thinking-disable fix is
actually running (e.g. 'field=extra_body, applied_value={enable_thinking: False}')
— critical for distinguishing 'fix not deployed' from 'fix not enough'.
2. segments_agent.py: when the whole chunk returns identical to source,
skip the retry if the source has fewer than two 4+ letter English
words. Technical docs (this client's WI/PRD docs) have many chunks
that are pure codes/numbers/abbreviations (FRM-QAD-SQM-018, HNB-020,
V1.0) — LLM correctly returns them unchanged, but the old code
retried 3x. 4-letter threshold avoids matching 3-letter abbrevs
like FRM/QAD/HNB.
_add_thinking_mode set data["extra_body"]={"enable_thinking": False},
but extra_body is an OpenAI Python SDK convention that gets unwrapped
to top-level by the SDK. This project sends requests via httpx, so
extra_body was sent as a literal nested key that DashScope ignores —
qwen3.6-plus kept thinking ON, wasting 96% of output tokens on
reasoning (measured: 0.54K reasoning / 0.56K output) and inflating
a 3-min translation to 24-min.
Fix: when the field is extra_body (aliyuncs/google providers), merge
its dict into the top-level request body instead of nesting it.
qwen3.6-plus on DashScope uses extended thinking by default, causing
filename translation to timeout at 10s (reasoning tokens add latency).
- enable_thinking: false → skip CoT for this simple one-word task
- timeout: 10 → 30s as safety net for slower environments
- _translate_filename_stem: add success/failure logging, include
glossary terms in prompt for accurate proper noun translation
- task_state: store translated_filename_stem after translation
- status API: return translated_filename_stem to frontend
- printPdf: accept stem param, set document.title directly instead
of fragile Content-Disposition header parsing
- Both printPdf call sites now pass task.translatedStem
Mineru/Docling PDF parsing requires tokens or heavy deps not available
on client server. Remove the option from dropdown, default to docx,
and stop auto-selecting markdown_based for unrecognized file types.
Previous regex matched 'UTF-8' as filename when Content-Disposition
used extended notation. Now try filename*=UTF-8''<percent-encoded>
first, then fall back to plain filename="...".
Chrome/Edge uses parent page title (not iframe title) when printing
to PDF. Temporarily swap document.title to translated stem before
print(), restore it 1s later after dialog opens.
Read Content-Disposition filename from the HTML download response,
strip the extension, inject it as <title> before printing. Browser
uses <title> as the filename when saving to PDF.
Add _translate_filename_stem() which calls the configured LLM to
translate the filename stem before building the export map. Result:
磨粉.pdf translated to English → grinding.pdf (instead of 磨粉_translated.pdf).
Falls back to original stem on any API error with zero impact on translation flow.
