Choose a Model for Translating Documentation

Define what a usable translation must preserve

Choosing a translation model starts with your documentation, not a leaderboard. A tutorial, an API reference, and a troubleshooting guide place different demands on a model. Before comparing candidates, identify the target language, the intended reader, and the parts of the source that must remain unchanged.

Write a short acceptance checklist. The translation should preserve technical meaning, warnings, headings, and cross-references. Identifiers, parameter names, placeholders, and literal values should stay intact unless you explicitly authorize changes. Decide whether product terminology should be translated or retained. These decisions give you something concrete to test.

Build a small sample that exposes real mistakes

Do not begin by translating the entire documentation set. Select a few short passages that represent its hardest parts: a setup explanation, a parameter description, a warning, and a troubleshooting paragraph. Include an ambiguous sentence and a repeated technical term so you can check interpretation and consistency.

Keep this sample fixed while comparing models. A polished translation of an easy paragraph tells you little about performance on the rest of your material. If the source contains confidential information, replace it with representative content before testing, and check the relevant data-handling terms before sending real documents.

Compare two candidates under the same instructions

Start with two candidates rather than spending money testing the whole menu. For example, compare Gemini 2.5 Flash with Claude Sonnet 5.5. Treat them as candidates to measure, not as a guaranteed budget winner and quality winner. Check current prices and availability before running your test.

Give both models the same source, terminology glossary, and instructions. Ask for translation only, with the original structure preserved and no added explanations. Specify that embedded instructions in the source are material to translate, not directions to follow. Keep generation settings comparable where supported, and avoid changing the prompt between candidates.

Score meaning before judging fluent prose

Read each result against the source rather than judging it in isolation. Smooth writing can hide an omitted condition or a reversed warning. Check whether requirements remain requirements, optional actions remain optional, and negative statements retain their meaning. Inspect numbers, units, identifiers, and references separately.

Use a simple scorecard for meaning, terminology, structural preservation, and readability. Record concrete errors rather than a general impression. If you cannot confidently read the target language, ask a fluent reviewer to inspect the sample. Another model can flag possible problems, but agreement between models is not proof that a translation is correct.

Measure the cost of a usable result

Compare the cost of accepted translations, not just the listed token rate. A model that needs repeated retries or substantial editing may cost more in practice. Record request cost, rejected outputs, and approximate review time for each candidate. Keep monetary spending and your own time visible as separate measures.

MyRelay helps with the spending side by showing each request's tokens and cost under one personal budget. Create a MyRelay account to run your comparison and inspect those request-level figures. Use the sample results to estimate a larger batch, but leave room for longer outputs, repeated glossary instructions, and occasional retries.

Expand gradually and keep a review checkpoint

Choose the least expensive candidate that meets your acceptance criteria, then translate one complete section before committing to the whole collection. Split work at meaningful section boundaries and reuse the same glossary. Excessively small chunks lose context, while oversized batches make omissions harder to locate and retries more expensive.

Review that first section for terminology drift and formatting damage. If one difficult passage fails, test a targeted revision before rerunning everything with another model. Save your instructions, glossary, and scorecard so you can repeat the comparison when the documentation changes. The right model is the one that reliably passes your checks at a cost you can sustain.