Hi DEV!
Pasting a document into a translation site works right up until the formatting matters. Then you get a wall of text back and rebuild the layout by hand. And if the document is a contract or a medical letter, you have just uploaded it to somebody else's server to save yourself ten minutes.
LingoGeek translates the file rather than the text:
- .docx comes back as .docx, with headings, tables and lists intact
- PDFs keep their layout
- SRT and VTT subtitles keep their timings and cue numbers
- Everything runs locally, nothing is uploaded, no per word charge
Why I built it
The translation quality problem is basically solved by open models now. The remaining problem is plumbing: getting the translated strings back into the document structure they came from without wrecking it. That is unglamorous work and it is the whole product.
Subtitles were the easiest, they are already segmented for you. Word documents were the fiddliest, because a single sentence can be split across several runs with different formatting, and you have to translate the sentence but reapply the runs.
Tech stack
- Python, packaged as a desktop app
- pywebview 5.3.2 for the shell, with fastapi 0.115.6 and uvicorn 0.32.1 behind it
- ctranslate2 4.5.0 and sentencepiece 0.2.0 for inference
- python-docx 1.1.2 and pypdf 5.1.0 for the document handling
- pydantic 2.10.4 for the request models
Running a local FastAPI server behind a webview is an odd shape for a desktop app, but it meant the translation pipeline stayed a normal Python service I could test without a UI.
Honest caveat
The installer is not code signed yet, so SmartScreen may warn on first run. Complex PDF layouts are still the weak spot, multi column academic papers in particular.
Links
- Site: https://techygeekshome.info/lingogeek/
- Source: https://github.com/techygeekshome/LingoGeek
- Video: https://youtu.be/hOF9UWpFFd8
Which language pairs do you actually need? That is what decides what I bundle next.
Top comments (0)