The AI translation workflow, from glossary to delivery

How many stations the real workflow has

Five stations, and not one of them is translating in the old sense. First a glossary and a short brief about the job get closed. Then a machine pass runs, constrained by that glossary. Then a human sits down with the output and decides. Then the whole document is checked for consistency. Then delivery, with a glossary that is now one entry bigger.

The third station has a name, post-editing, and it is not a new coinage. There is an international standard for it, ISO 18587:2017, titled Translation services, post-editing of machine translation output, requirements, and its own scope covers full human post-editing of machine output plus the competences of the post-editor. Anyone who thinks this is a shortcut somebody invented last year is looking at a profession that has had written requirements since 2017.

Why does the order matter? Because four of the five stations sit outside the translating itself. And the usual shape of the job going wrong is exactly this: someone hands the text to a model, reads the output, likes it, and halfway through discovers that one term has to change everywhere. At that moment you are not building a glossary any more. You are repairing.

Close the glossary before you translate, not after

A glossary has three kinds of row and each needs separate thought. The first is a term with a settled equivalent that you only have to remember. The second is a term with two live equivalents, where you pick one and hold it to the end of the document. The third is a word that does not get translated at all.

The third kind is where the work limps, because that list is never as short as you assume. We counted it on this very learning section: in the Persian text of 150 lesson files, outside code blocks and prompt recipes, 4,192 Latin-script tokens were sitting inside Persian sentences; 1,055 of them distinct, and 561 of those appeared exactly once. More than half the list is a tail seen a single time and never again.

That shape does not make the job easier; it tells you where to look. The head of the list, the ten that keep repeating, announces itself and nobody forgets it. What gets dropped is the tail: a product name, a file format, a legal name that occurs once in the whole document and, precisely for that reason, has no memory behind it.

So the glossary gets closed by reading the source once, not by remembering. And when the client has earlier documents, you take the list out of those rather than out of your own head. This is the one place in the whole workflow where an hour spent saves several hours at the stations after it.

Light or full post-editing: which one did you sell

There are two kinds of post-editing and the difference between them is commercial, not technical. In the light kind you catch only the errors that change the meaning and you leave style alone; the output is correct, it smells of the machine, and for a text that merely has to be understood that is enough. In the full kind the output has to come out as though a human wrote it from the start: tone, register, sentence shape, all of it.

The scope of ISO 18587 is closed around the full kind. So when somebody says their work follows that standard, they are talking about the heaviest version and not the lightest. Which of the two you are selling has to be settled with the client before you start; it is the step that almost always gets skipped and comes back later as "this still reads like a machine".

And here the economics of the job change, without our needing to hand you a number. Translating from scratch, you were selling time for producing text. In post-editing, producing text has become nearly free and what you sell is judgment: whether this equivalent is right, whether this sentence carries the same meaning in this context, whether this figure came from the source or the model produced it. Anyone who does not accept that sells post-editing at a discount and takes less money for not typing, while the hardest part of the work is still exactly where it was.

Post-edit segment by segment, not paragraph by paragraph

Do not read the machine output as flowing text. Read it in pairs: source sentence, target sentence, decision. The reason is that flowing text carries you along; the reader's mind guesses the next sentence from the previous one and sees what it expected to see. With the target sentence sitting next to the source sentence, that guessing is not possible.

So ask the model for paired output rather than continuous paragraphs. Continuous text cannot be post-edited; it can only be read again, which is a different job.

You also need one check that the human eye cannot do: that a term is rendered the same way everywhere in the document. That work is purely mechanical and it is the best thing to hand to a cheap fast model. In a fresh conversation, not the one where the translating happened:

You have a target text and its glossary.

Glossary, each row as "source term = chosen form":
{glossary}

Target text:
{target text}

For every glossary row, find each place in the target text where that term should appear and write which form was used. Report only the rows that have more than one form, and give the sentence number of each form. Do not choose any form and do not change the text.

This check catches consistency and not correctness; if you rendered a term the same wrong way everywhere, this pass says nothing at all. Quality control in the full sense is a separate job and the lesson on translation quality control in this same path deals with it.

When the text sits inside tags and placeholders

A real document is rarely plain text. It is HTML with its tags, or a software file with placeholders like {name} and %s, or a subtitle file with timings, or a spreadsheet where every cell is a separate string. And when a language model sees something like that it does not merely translate; it helps. It moves a tag, translates an attribute inside a tag, renders a placeholder into the target language, and writes the time format more tidily.

None of these things raise an error, which is what makes them dangerous. A missing tag skews the page and somebody sees it the same day. A translated placeholder skews nothing; it only makes the software print the word {name} where the user's name should be. And that one usually gets reported by the user, not by you.

The professional route is simple and older than language models: separate the structure from the text, give the machine the text alone, then put it back. Computer aided translation tools were built for exactly this, and that is their real value rather than the translation memory. If you have no tool and the job is small, the two column table is enough, provided the second column never sees any structure.

And if you have no choice but to hand over marked-up text directly, hold two rules. First, write every placeholder and every tag verbatim into that prompt's do-not-translate list. Second, after each pass, search the target yourself for all of them and compare the counts against the source. It takes thirty seconds and it is the only thing that finds this class of error before the user does.

Subtitles have rules of their own, from reading-speed limits to the mechanics of the file, and the lesson on subtitles deals with that technical layer.

What exactly to look at before you deliver

A language model's error is fluent and does not announce itself, so the last look should not go to the overall quality of the text. It should go to the categories where the model breaks quietly. Four of them: numbers and units, proper names, dates, and negation.

Numbers and units, because the model rewrites the figure and in rewriting it sometimes rounds it or swaps the unit. Proper names, because any name that was not on the do-not-translate list is a candidate for being translated. Dates, because date formats are not the same across languages and the conversion opens another place to be wrong. And negation, which is the dangerous one: a "must not" that becomes a "must" makes a sentence that is perfectly fluent and exactly inverted.

One more look is needed that has nothing to do with the text: what left your machine. The client's document is not yours to decide the destination of, and by delivery time this question is meaningless; it has to have been answered before the machine pass. The next part of this lesson says what each of these services does with the text you hand it.