Solutions
We handle the documentation, not the interface strings.
Software companies localise two different things: the product itself, and the documentation around it. The first is a string problem with its own tooling. The second is a document problem, and it is the one we take.
What makes these documents hard
Four reasons documentation localisation stalls.
Manuals are long and repetitive
The same warning appears in twelve places and has to read identically in all of them. That is a glossary problem, not a translation problem.
Screenshots and diagrams
Documentation is full of images with text in them. Whether they need handling is worth scoping rather than assuming.
Version drift
Documentation is updated constantly. A translation process that cannot keep up becomes a backlog nobody clears.
Formatting conventions
Numbered procedures, callout boxes, tables of parameters — the conventions carry meaning and have to survive.
The documents we get
The document types that come up most in this category.
User and admin guides
Long, structured, heavily numbered, full of procedures.
Release notes and changelogs
Short, frequent, and the case where turnaround expectations are sharpest.
Help content and knowledge base articles
Written in an authoring tool, exported as documents, frequently updated.
Datasheets and API reference documents
Tables of parameters and return values where structure is the content.
Terminology and consistency
Product terminology is the whole game here.
Software documentation lives or dies on consistency: a feature called one thing in the interface and another in the manual is a support ticket. Your term list is the mechanism that prevents it — TXT, CSV or XLSX, up to 2000 terms, applied during translation.
We do not translate interface strings. Resource files, keys and in-product content are a different pipeline and belong with the tooling built for that job.
What we take is the documentation layer: manuals, guides, notes and reference documents in PDF, Office formats and images.
How the work runs
Four steps, same pipeline for every industry.
- 01
You send one real document
The awkward one if you have it. It is evaluated on the same path your production work would take.
- 02
We run it end to end
Inspection, per-page routing, translation with your terminology applied, independent review, visual verification.
- 03
You judge the returned file
Layout, terminology, the pages that normally break. That is the evaluation.
- 04
Scope is agreed separately
Volume, language pairs, turnaround and integration. The sample tells you whether to have that conversation at all.
Questions
Do you translate interface strings?
No. Resource files and in-product content are a different pipeline and belong with software localisation tooling. We take the documentation.
What about screenshots with English text in them?
Text inside an image is handled through the image path rather than the document's text layer. Tell us if your documentation relies on it and we will scope it.
Can you keep a feature name consistent across a manual?
Yes — that is what glossary enforcement is for. Your term list is applied during translation, up to 2000 terms.
How do you handle frequent release notes?
Volume and cadence are part of scoping rather than something we publish turnaround figures for. Tell us your rhythm and we will say what is workable.
Do you integrate with our docs pipeline?
That depends on what your pipeline can call. Integration is scoped per engagement — tell us what your system does.
Send us a manual with numbered procedures in it.
Procedures, callouts and parameter tables are where documentation translation usually falls apart. One real file will show you whether it does.
- No signup, no self-service portal — you send a file, we run it.
- You get the finished document back, not a screenshot of one.
- If it is not good enough, you have lost nothing.