Software & training
Software Documentation Translation Services
We translate software documentation inside your repository, from Markdown help centers to DITA libraries, without breaking a placeholder or a build. Admin guides, knowledge bases, and release notes stay in sync with your sprint cadence in more than 40 languages.
We work in Git with branches, pull requests, and CI checks, so translated Markdown and AsciiDoc ship through the same pipeline as your English source.
Variables such as {0}, %s, and ${name} are locked before translation and machine-verified after it, so localized files never fail a build.
Diff-based updates and translation memory mean each sprint you pay only for what changed, and version 4.2 reads exactly like version 4.1.
Software documentation translation is documentation in motion
A press brake manual gets revised once a year. Your knowledge base changed twice last week. That difference defines everything about software documentation translation: the content is never finished, it lives in a repository rather than a binder, and it ships on the same schedule as the product it describes. An agency that treats your docs like a static PDF will always be one release behind, and users notice. Nothing erodes trust in a product faster than a help article that describes buttons that no longer exist.
Techniwords has been translating technical content for 15 years, and we watched this shift happen. We started with boxed-software manuals delivered as FrameMaker files. Today most of our software clients hand us a Git URL and a style guide. The translation problem changed with the tooling: instead of one large project per year, teams need a continuous flow of small, fast, consistent updates across a dozen languages, with terminology that never drifts between the interface, the docs, and the marketing site.
That is the service this page describes. We translate admin guides, knowledge bases, onboarding flows, in-app help, README files, changelogs, and error message catalogs for software companies selling into international markets, and for international vendors bringing their products to American users. If your product also ships with classroom or video content, we handle translating the training material that goes with your software under the same terminology base, so a feature is never called two different things in two different assets.
Docs-as-code: we translate inside your repo, not around it
Most localization vendors ask you to export your content, send it over, and paste the result back. With a docs-as-code setup, that workflow is a liability. Every export loses front matter, every paste risks mangled syntax, and nobody can trace which commit a translation corresponds to. We work the way your writers do: clone, branch, translate, open a pull request. Your reviewers see clean diffs, your CI runs its checks, and the merge history records exactly what was translated and when.
In practice, our engineers set up a parsing profile for your repository during onboarding. It tells our translation environment what is translatable text and what is structure: Markdown and MDX syntax, YAML front matter keys, Jinja or Liquid tags, admonition markers, code fences. Translators see protected tokens they cannot edit and clean sentences they can. Nothing else. A translator working on your Docusaurus site cannot accidentally delete a heading anchor or rename a slug that fifty other pages link to.
This matters most for the software and IT companies we work with, where documentation teams are small and release trains do not stop. When the workflow lives in Git, localization stops being a quarterly project someone has to manage and becomes a step in the pipeline, like linting. Several clients trigger our work automatically: a label on a merged PR opens a translation request on our side, and translated commits come back within the agreed turnaround.
DITA, structured authoring, and the economics of reuse
Enterprise documentation teams often write in DITA or another structured XML vocabulary precisely because content gets reused: one topic about configuring SSO appears in the admin guide, the quick start, and the API portal. Translation should follow the same logic. We translate at the topic level, respect conref and keyref mechanisms, and never flatten your architecture into linear files. A segment translated once is reused everywhere it appears, which is where the savings come from: on mature DITA projects, 40-60% of the content of a new release is typically recovered from memory at reduced or zero cost.
Structured content also imposes discipline that pays off in translation. Because DITA separates content from formatting, there is no desktop publishing rework at the end: the translated XML flows back through your existing pipeline and outputs HTML, PDF, or in-product help automatically. Our deliverable is valid XML, checked against your DTD or schema before we hand it back, with every attribute, ID, and processing instruction intact.
Teams migrating from unstructured formats often ask us to align legacy translations during the move. We rebuild translation memories from your old bilingual files, clean the terminology, and map everything to the new topic structure, so the migration does not mean paying to retranslate ten years of content. It is the same philosophy we apply to user manual translation for hardware products: protect the client's past investment, then make every future update cheaper than the last.
Placeholders, variables, and the art of not breaking the build
Software documentation is full of text that must survive translation byte for byte: printf tokens like %s and %d, positional placeholders like {0}, ICU MessageFormat plural blocks, environment variables, CLI commands, file paths, and inline code spans. A translator who rearranges a sentence and drops a closing brace does not produce a bad translation. They produce a broken build, or worse, a page that renders a raw variable name to the end user.
Our defense has three layers. First, tokens are locked at parsing time, so they cannot be edited or deleted, only moved, which is often required: German and Japanese syntax legitimately place a {productName} in a different position than English does. Second, automated QA compares source and target token inventories on every segment and blocks delivery while any mismatch remains. Third, for clients with a build pipeline, we run the translated files through it before the pull request is opened, so problems surface on our side rather than yours.
One character can take down a page. A single unescaped curly brace in an MDX file does not degrade gracefully: it throws a compile error and the entire page fails to render. This is why our token QA treats every brace, backtick, and angle bracket as an inventory item to be reconciled, not as punctuation.
The same rigor applies upstream of the docs. Interface strings and documentation must use identical wording, which is why many clients pair this service with our software UI localization service: one terminology base feeds both, and the doc that says Click Save never faces a button that reads Submit.
Screenshots, UI references, and keeping documentation honest
Documentation earns trust visually. If a Japanese user reads a Japanese article illustrated with English screenshots, the message is that the localization is cosmetic. We manage screenshot localization as part of the documentation workflow: your team or ours captures the localized interface, and our editors verify that every callout, caption, and reference in the text matches what the image shows. Where automated capture frameworks exist, we plug into them; where they do not, we work from a staged environment with test accounts.
Sequencing matters here. The interface must be localized before the documentation that depicts it, so we schedule UI strings first, then docs, then captures, then a final consistency pass. When a product area ships in English only, we apply a documented convention instead of guessing: the English label appears in the text, followed by a translation in parentheses on first mention. Readers always know exactly what to look for on screen.
This consistency pass is also where we catch drift between releases. Menu items get renamed, settings move between tabs, and a doc set translated over three years accumulates references to interface elements that no longer exist. Our reviewers flag these against the current UI export, which regularly surfaces outdated references in the English source too. Several clients treat our localization QA reports as a free audit of their source documentation, and more than one stale English article has been fixed because a translator asked where a button went.
Release notes, changelogs, and continuous localization
Release notes are the sharp end of the cadence problem. They are written days or hours before a release, they are visible to every customer, and they are stale two weeks later. For clients on a subscription workflow we commit to fixed turnarounds, typically 24-48 hours for release notes in up to ten languages, with a named team that already knows the product. No re-briefing, no terminology questions we asked and settled six months ago.
Between releases, translation memory does the accounting. When 8% of your help center changed this sprint, you pay for that 8%, not for a full re-translation, and repeated or lightly edited sentences are billed at reduced rates. Over a year, clients releasing every two weeks typically see their per-release localization cost fall sharply as the memory matures. The economics only work if the memory is maintained with care: we deduplicate, fix source-side inconsistencies, and version memories by product line so that legacy phrasing never contaminates a new product.
Deprecation and migration notices deserve a special mention. When you sunset an API version or change default behavior, the localized notice must be unambiguous in every market, because the support tickets arrive in every market too. We route these through senior technical translators, the same profile we assign to API documentation translation, where a vague sentence costs developer hours rather than clicks.
Formats we handle, and what we protect in each
Every format in a modern docs stack has its own failure modes. This table summarizes the ones we process daily and the elements our parsing profiles lock down.
| Format | Typical use | What we protect |
|---|---|---|
| Markdown / MDX | Docusaurus, GitBook, Hugo, MkDocs sites | Front matter, JSX components, code fences, heading anchors, link targets |
| DITA / XML | Enterprise help systems, single-sourced guides | Element structure, conref and keyref, IDs, attributes, DTD validity |
| YAML / JSON | String catalogs, structured content, config-driven docs | Keys, nesting, escaping, placeholders, comment lines |
| reStructuredText | Sphinx documentation for Python ecosystems | Directives, roles, cross-references, literal blocks |
| HTML / help systems | Legacy WebHelp, CHM conversions, Zendesk exports | Tag integrity, inline styling, embedded scripts, anchor links |
| PO / XLIFF | gettext catalogs, exchange formats from your TMS | msgid integrity, plural forms, state attributes, context notes |
If your stack is not in the table, it has probably still crossed our desks: AsciiDoc, LaTeX, Confluence exports, and homegrown JSON schemas all have solutions. Send a sample with your quote request and we will return a parsing plan along with the price. You can browse the full list of technical documents we translate if your project mixes software docs with hardware or compliance content, which is common for connected devices.
A process aligned with ISO 17100, tuned for software teams
Speed never excuses skipping review. Every file we deliver has passed through an ISO 17100-compliant process: translation by a certified translator who works in software daily, then independent revision by a second linguist against the source, then automated QA on tokens, numbers, and terminology. Techniwords is a member of both the American Translators Association and GALA, and our project managers run localization programs from our base in Texas for clients across the US and their users everywhere else.
A recent example shows what the workflow looks like under load. A developer tools company came to us with 1,400 Markdown topics, a two-week release cycle, and a launch commitment in Japanese and German. We built the parsing profile in the first week, translated the backlog in six, and moved to continuous mode. Nightly pseudo-builds caught 23 broken cross-references before any merge, all of them traced to inconsistencies already present in the English source. Eight months in, their per-sprint localization turnaround is under three business days, and their Japanese support ticket volume on documentation topics has dropped measurably. For markets like Japan where localized developer content directly affects adoption, pairing docs with Japanese technical translation by engineers-turned-linguists is what makes the difference between content that exists and content that gets read.
Pricing follows the repository, not the page count. After analyzing your files against memory, we quote per weighted word, with new text, fuzzy matches, and repetitions each at their own rate, and the quote itemizes all three so you can see exactly where the money goes. Most clients start with a paid pilot on one doc set, measure the result, then scale. To see how we would set up your repository, request a quote and include a link or a sample export.
Software documentation translation: frequent questions
Can you work directly in our Git repository with Markdown files?
Yes, and it is our preferred setup. You grant our team access to the repository or a fork, we create a localization branch, translate the Markdown or MDX source with structure protected, and deliver through a pull request your team reviews like any other. Front matter, code fences, and link anchors are locked during translation. If direct access is not possible for security reasons, we work from scheduled exports and return commit-ready files, keeping the same diff-based accounting so you still pay only for changed content.
How do you keep up with a release every two weeks?
Through continuous localization rather than project-based work. A standing team is assigned to your account, terminology and style decisions are settled once and stored, and each sprint we translate only the diff against the previous release. Turnarounds are contractual, typically 24-72 hours depending on volume and language count. Clients who label a merged pull request for translation usually see localized commits come back before their next sprint planning. The first cycle takes the longest; by the third, the process runs without meetings.
What happens if a placeholder gets broken in translation?
It gets caught before delivery. Placeholders such as {0}, %s, and ${variable} are locked as non-editable tokens in our translation environment, and an automated check reconciles the token inventory of every source and target segment. A file with a missing, duplicated, or malformed token cannot pass our QA gate. For clients who share their build pipeline, we additionally compile the translated docs before opening the pull request. In 15 years we have learned that the cheapest place to catch a broken variable is before it leaves our hands.
How do you keep the documentation consistent with the translated interface?
Both are driven from the same terminology base. When we localize your UI strings, every label becomes a term record; when we translate documentation, translators see those records as mandatory terminology, and automated QA flags any deviation. If another vendor handles your UI, we import their string files as reference material instead. On each release we also run a consistency pass against the current UI export, which catches renamed menus and moved settings, including some that the English documentation had missed.
Do you translate DITA projects, and does reuse actually save money?
We translate DITA daily, at topic level, with conref, keyref, IDs, and attributes preserved and the output validated against your DTD before delivery. The savings from reuse are real and measurable: a segment translated once is recovered from memory every time it reappears, and on mature projects 40-60% of a new release typically comes back as full or fuzzy matches billed at reduced rates. Your quote itemizes new words, matches, and repetitions separately, so the reuse discount is visible rather than theoretical.
How much does software documentation translation cost?
Pricing is per weighted word after analysis against translation memory. New text is billed at the full rate for the language pair, fuzzy matches at a reduced rate, and repetitions at a small processing rate. A first project with no memory costs the most; costs then fall as the memory matures, which is significant for products releasing frequently. Engineering work such as building a parsing profile for an unusual format is quoted once, at setup. Send a repository link or sample export for an itemized quote within one business hour.