The problem
Deshons sells ground support equipment worldwide — airframers, airlines and MRO providers across several continents. Every unit ships with documentation, and that documentation has to exist in the language of the people who will use it.
Translating it internally is slow, and it competes for time with engineering. Translating it generically is worse. Off-the-shelf machine translation handles ordinary prose well and specialist vocabulary badly: it renders a hydraulics term into something fluent, confident and wrong.
That failure mode is the dangerous one. An obvious error gets caught. A plausible mistranslation of a pressure rating, a fitting type or a servicing instruction reads perfectly well and passes review — in documentation for equipment that gets connected to aircraft.
What we did
We built a translation system around a model tuned on Deshons’ own technical vocabulary rather than general language: the terms, part nomenclature and phrasing their documentation actually uses.
The point was consistency as much as speed. The same component should be named the same way in every document, in every language — which is exactly what generic translation does not guarantee, because it treats each sentence as an independent problem.
What made it hard
Domain vocabulary is not a glossary you can bolt on. It is thousands of small decisions about how this company describes its own products, most of them never written down — held in the heads of the people who have produced the documentation for years.
Getting that into a model means extracting tacit knowledge and making it explicit and reviewable, then proving the output is trustworthy to the engineers whose names are effectively on the documents. Which is the recurring shape of this work: the technology is the straightforward part, and earning the right to be trusted with the output is not.