API Documentation Translation: What to Skip

Quick answer — Translate the guides, concepts and error explanations. Leave endpoint names, parameters, code samples and the reference tables in English, because developers search and copy those in the original.

Vitra.ai Universe ships product and customer content in every language.

Developers read documentation differently

A developer looking for an endpoint is not reading. They are scanning for a symbol they already half-know, then copying a code block. Translating the symbol breaks that. Translating the prose around it helps.

That split is the whole decision, and getting it wrong in either direction wastes money — translating everything produces documentation nobody trusts, translating nothing leaves concepts unexplained for the majority of the world's developers who do not read English comfortably.

What to translate and what to leave

Code comments are the useful middle. Translating the comment inside a sample while leaving the code untouched gives a reader the explanation without breaking copy-paste, and it is the single highest-value thing in this list.

Error messages are the exception worth funding

A developer hitting an unfamiliar error searches the exact string, so the string itself should stay in English and be searchable.

The explanation next to it should not. That is where a reader in another language actually loses time, and it is covered further in error message translation.

Do not translate what you cannot maintain

API documentation changes with every version, and stale translated docs are worse than none — a developer following an outdated Japanese guide files a bug against behaviour that changed two releases ago.

So either wire it to the release the way release notes are wired, with segment memory keeping the cost proportional to the change, or translate only the stable conceptual pages that do not move.

Mark the version and date on every translated page. A developer who can see the page is three versions behind can decide for themselves; one who cannot, cannot.

Run quality control with a do-not-translate list covering every symbol, or the first pass will helpfully translate your parameter names.

FAQ

Should API reference documentation be translated? Mostly not. Endpoint names, parameters, code samples, enum values and status codes stay in English because developers search and copy them. Guides, concepts and error explanations are worth translating.

What about code samples? Leave the code and translate the comments inside it. That gives a reader the explanation without breaking copy-paste, and it is the highest-value change in most API documentation.

Should error strings be translated? The string itself should stay in English so it remains searchable. The explanation beside it should be translated, because that is where a non-English reader actually loses time.

What is the risk of translating API docs? Going stale. Documentation changes every version, and an outdated translated guide leads developers to file bugs against behaviour that already changed. Mark version and date on every translated page.