Technical translation depends on stable terminology.
When a product feature, API concept, hardware component, or process label appears many times, the translation should not improvise a new phrase every few paragraphs.
That is why glossary support matters before the translation starts.
What To Put In A Glossary
A useful glossary does not need to be large. Start with terms that are repeated, brand-sensitive, or easy to mistranslate.
Include:
- source term
- preferred target term
- terms that should not be translated
- forbidden translations
- short notes when context matters
For SaaS products, this often includes feature names, menu labels, plan names, product modules, and technical concepts.
Why Technical Documents Break Generic Translation
Generic translation tools often optimize sentence by sentence. Technical documents need document-level consistency.
Examples:
- the same UI label should stay the same
- API parameter names should not be translated
- product names should remain stable
- warnings should be clear and direct
- lists and headings should remain usable
If the translated document will be handed to customers, support teams, or developers, inconsistent wording creates real support cost.
GoodTrans Workflow
From the Translate page, you can paste terminology notes or upload a glossary file. GoodTrans uses those preferences during the translation task and includes terminology-related review notes in the quality report.
The final Markdown file is suitable for documentation systems, static sites, help centers, and internal knowledge bases.
Review Before Publishing
AI translation can reduce the first-pass workload, but technical content should still be reviewed by someone who understands the product.
Use the quality report to prioritize review, then publish from the editable Markdown after your team has checked names, commands, code references, screenshots, and UI labels.
For volume planning, review credit packs before translating a documentation set.
