You can quality check an AI translation in 15 minutes. Not all of it, and not the way most people try. What fails is reading every segment with equal suspicion, or asking a model to "review this and tell me if it is good". What works is narrower and almost mechanical: a fixed checklist, a prompt built to a fixed structure, and a severity scale that turns "this sounds off" into something you can count, defend and hand to a client.
Everything in this walkthrough comes from our own courses. The checklist is the one our Master students use in the LQA session. The prompt structure is the four-part anatomy taught in From Post-Editor to AI Quality Specialist. The severity and penalty model is the TAUS DQF error typology we work with in the machine translation evaluation sessions. And the output in the section below comes from a real API call: two prompts run for this article on 21 September 2026, with the flaws in the output and the model's own stated limits written next to it.
Figure 1. Our LQA parameter list by block, as taught in the Master session: 7 accuracy checks, 6 linguistic conventions, 6 formatting and locale checks and 1 terminology check. Twenty checks in total, and the list is short on purpose: a checklist nobody finishes is not a checklist.
In This Article
- What 15 Minutes Can and Cannot Do
- Four Failures the Course Names
- The Checklist, Point by Point
- How to Ask: The Prompt and Its Structure
- The Assets That Stop the Error Coming Back
- How Errors Are Measured
- What the Numbers Can and Cannot Tell You
- What the Model Actually Returned
- The Error Report You Can Hand to a Client
- What AI Does Not Catch Well
- The 15-Minute Routine
- FAQ
- Courses and Further Reading
1. What 15 Minutes Can and Cannot Do
The first thing a quality specialist does is refuse to review everything equally. The four-pillar framework from our course puts 45% of the role into high-impact review, and the instruction inside that pillar is explicit: review critical product flows, high-traffic help pages and key campaigns, batch related strings together, and annotate every edit with a reason. Fifteen minutes of that beats three hours of reading every segment with the same level of attention.
Sampling makes the arithmetic realistic. In the AI LQA session with ContentQuo we use the rule of thumb that 10% of a 10,000-word job, so 1,000 words, still gives meaningful quality insights. Fifteen minutes is roughly one pass over a sample that size.
What you get in 15 minutes: a list of errors with categories and severities, a verdict you can defend, and the input you need to fix the system that produced the output rather than this one string. What you do not get: full coverage, a guarantee on the segments you did not look at, and any real validation of target-language idiom if you are working without a glossary or style guide. Say that out loud in the report. Clients forgive a stated limit and do not forgive a silent one.
The work is paid work, and you can check that on our own numbers. On the TranslaStars job board, read on 21 September 2026, of 1,204 open offers, 48 are classified as QA / Reviewer and 31 sit in the QA and review function; among the top skills, review appears in 289 adverts and terminology in 274, more than any other tool skill on the board. Quality is not a hypothetical corner of this industry.
2. Four Failures the Course Names, With the Examples
The session that opens From Post-Editor to AI Quality Specialist builds its whole argument on one idea: AI does not fail at random. It fails in predictable patterns, and naming the pattern is worth more than fixing the string, because the name tells you where the fix lives. These are the four, with the examples Nicola Calabrese uses in class.
| Pattern | What happens | Where the fix lives |
|---|---|---|
| Tone and register drift | A B2B SaaS line, "Hey, ready to send your first message?", comes back from German as "Greetings, are you prepared to dispatch your initial communication?". No grammar error, a register error: technically correct, brand-wrong. | The style brief |
| Over-literal output | "Found a bug? Report it here." becomes "Found an insect?" in Italian, because the model took the literal sense of a technical term. | The glossary |
| Context blindness | The button label "Open draft" turns into "Open the draft document" in German: a two-word label read as prose and expanded into a sentence that no longer fits the button. | Context metadata |
| Brand terminology | "Invite your team to your workspace" becomes "to your account" in Japanese, because the glossary never locked "workspace" as a preferred term. | The glossary, again, but locked this time |
The practical consequence is uncomfortable for the way most people review AI output. None of those four errors is best fixed in the segment where you find it. Three of them are fixed upstream, in an asset, and the fourth is fixed by giving the model the context it was missing. Reviewing strings one by one is reactive. Naming the pattern and repairing the asset is what the course calls fixing every future segment instead of one.
3. The Checklist, Point by Point
This is the parameter list our Master students work with, and it has twenty checks in four blocks: seven in accuracy, six in linguistic conventions, six in formatting and locale, and one in terminology. The table below shows the eight that catch most of the damage, which is the version you can finish in fifteen minutes.
| Check | What you are looking for | Course block |
|---|---|---|
| 1. Accuracy | Does the target say what the source says, or has the meaning moved? Includes mistranslation (incorrect meaning) and untranslated text left in the source language. | Accuracy |
| 2. Omissions and additions | Content missing from the translation, and content that is present in the translation but not in the source. Also repetition, text pasted twice, and incorrect cross-references. | Accuracy |
| 3. Terminology | Non-compliance with the glossary: preferred terms not used, forbidden terms used, do-not-translate items translated. | Terminology |
| 4. Register | Does it sound like the brand? Formal where the source is casual, or the other way round. Grammatical register, and the informal or formal address form in languages that make the distinction. | Linguistic conventions |
| 5. Numbers, dates and units | Number format, date format, currency format, units of measurement, and address format for the target locale. | Formatting and locale |
| 6. Tags and formatting | Broken or mismatched tags, placeholders, double spaces, markup that no longer matches, shortening or expansion that breaks a layout. | Formatting and locale |
| 7. Coherence | Inconsistency: the same term translated two ways, or one term used for two concepts. Also internal contradictions in the text. | Linguistic conventions |
| 8. Style and fluency | Punctuation, spelling, grammar, unidiomatic phrasing: grammatical but not something a native would write. | Linguistic conventions |
Two things make this list usable. First, every row is a decision, not a feeling: either the segment complies or it does not. Second, the rows the model is weakest at are marked in the material as needing the human: tags, casing, terminology and character display are exactly the items our machine translation evaluation session lists as "nuances and issues missed by the automatic scores".
4. How to Ask: The Prompt and Its Structure
Our courses teach the prompt as a quality document, not a search query. The anatomy has four parts, and the material is blunt about why: miss one and the model fills the gap with guesswork.
| Part | What it contains |
|---|---|
| Role | Who the model is for this job. "You are a professional translator for a B2B SaaS company." |
| Context | What is being translated and for whom. Audience, content type, where the string appears. |
| Constraints | Glossary, style, do-not-translate list. This is where the assets come in. |
| Examples | Two or three source and target pairs showing the output you want. |
The difference this makes is measurable, and the course demonstrates it with two real runs on the same sentence. With the prompt "Translate this to French", the model turned a casual trial reminder into "Greetings, your trial period expires in three days. Please select a subscription plan to continue." With the full prompt (role: UX writer for a casual SaaS product; audience: small-business owners; constraints: informal register, under 12 words, action-oriented; style example: "You're in. Let's go."), the same sentence came back as "Heads up - trial ends in 3 days. Pick a plan to stay." Same source, same model, two different products.
For the actual quality check, we do not ask for a rewrite. We use the LQA prompt from the Master session, which is short and specific, and we attach the parameter list and the glossary as files:
Perform linguistic quality assurance of the file "translation" against the source file "source text", the checklist with error types in the file "LQA parameters", and the glossary in the file "glossary". If you find errors, present a list of errors and grade them as major or minor based on your judgment as a professional translator. Reply "no errors" if the document is free of errors. Present your evaluation in the following table: Error category | Severity | Source text | Translation text | Error description. Review the whole translation against the source. List all errors that you find, including all glossary incompliance issues.
Four details in there are doing real work. The checklist is attached, so the model categorises instead of opining. The glossary is attached, so terminology becomes a check rather than a taste. The command to reply "no errors" gives you a clean signal instead of invented findings. And the fixed table means the output lands directly in your report.
5. The Assets That Stop the Error Coming Back
The course's answer to the four patterns is a toolkit of four assets, and it is worth knowing what each one is for, because they are not interchangeable. A glossary decides what the words mean. A style brief decides how the brand sounds. A prompt decides what the AI is told to do. An LQA framework decides how you measure it.
Two of the four are where most of the gains sit, and the course is specific about what they need to contain.
The glossary has to be a decision engine
- Context notes per term: when and where each term applies, not only what it means.
- Disambiguation rules: the same word with two meanings needs an explicit rule. The class example is "account" in a platform context against "account" in billing, which should not be the same target word.
- Do-not-translate list: brand names, product names, legal terms.
- Forbidden terms: competitors, deprecated names, anything the client never wants to see.
The word the course uses is a living glossary: it gets updated every time LQA finds a new pattern, so it grows with the project instead of going stale.
The style guide has to become an eight-line brief
A forty-page PDF written for human editors is not something a model can follow. It is full of rationale and brand philosophy and no structure the model can parse. The exercise in class is to extract the rules an AI can act on: audience, tone, forbidden phrasing, and two or three short examples. Same brand voice, in a format that actually survives the trip into the prompt.
The loop that keeps it honest
The LQA framework is not a report you deliver once. It is a feedback loop: LQA identifies a pattern, the pattern goes back to the glossary, the style brief or the prompt, you re-test with the AI, and LQA confirms the fix. Over time the model makes fewer errors, not because it got smarter, but because the assets got better. That sentence is the argument of the whole course, and it is also the honest reason to spend fifteen minutes on a sample rather than three hours on every segment.
6. How Errors Are Measured
Severity is what turns a list into a score. From Post-Editor to AI Quality Specialist works with three levels in class: minor, major and critical. The scoring model we use with clients in the MT evaluation sessions adds a fourth, preferential, taken from the TAUS DQF typology. These are the practical definitions:
| Level | Definition from the course |
|---|---|
| Preferential | A reviewer's choice or preferred style. Not an error: it is recorded, not counted. This band comes from the DQF typology, not from the three-level model used in class. |
| Minor | You notice it, but it does not change the meaning. A typo in a help-centre article you can still follow. |
| Major | It affects the meaning or the brand perception. The wrong product name, a key term replaced by something associated with a competitor, an off-brand register. |
| Critical | Legal, safety or serious consequences. A safety label mistranslated, or a promise the company cannot legally make. |
When a client needs a number rather than a list, we move to the model we work with in the MT evaluation sessions: the TAUS DQF error typology, which assigns penalty points by severity, sets a maximum number of penalty points per 1,000 words, and returns a PASS or FAIL. The template we use carries the industry benchmark band for that maximum at 2 to 20 penalty points per 1,000 words, and leaves the number itself to the client because it depends on the content type and the languages. The error categories in it are the ones you would expect: accuracy, fluency, terminology, style, design, locale convention and verity, each split into subcategories with a worked example, from an omitted negation in a dosage instruction to a date in the wrong format for the locale.
Two warnings that the material makes explicitly, and that most people get wrong:
- Thresholds are subjective. The MT evaluation session says it plainly: quality threshold values are subjective, so be consistent over time with the metrics you choose, and compare more than one.
- Weighted, not flat. Participants in the quality session described their own setups as MQM with client-adapted categories and adaptive weights, because not everything lands equally. A wrong product name and a stray comma are not the same event, and a scale that treats them as equal will push your client towards discounting the whole report.
7. What the Numbers Can and Cannot Tell You
The fifteen-minute routine above is human review. There is a second layer underneath it, and it comes from the machine translation evaluation sessions of the Master, taught by Andres Romero. It matters here because it is what tells you, before anyone reads a word, whether the output deserves a reviewer's morning at all.
Before reading: automatic evaluation
Automatic quality evaluation has no single standard, and the choice of metric decides what you can conclude. The material splits them in two families.
| Family | Metrics | What it gives you |
|---|---|---|
| Lexical, reference-based | BLEU, TER, ChrF | Overlap with a human reference. BLEU counts n-gram precision and higher is better; TER counts the edits needed to reach the reference (insertions, deletions, substitutions, shifts) and lower is better; ChrF does the same at character level. They compare strings, they do not understand meaning. |
| Semantic, reference-based | COMET, MetricX, BERTScore | Similarity in meaning rather than in words, which tolerates paraphrase and variation. COMET maps vector similarity to human judgements and is the one the material calls the preferred metric in the industry right now. MetricX runs the other way: lower is better, on a 0 to 25 range. |
| Reference-free | COMET-Kiwi, XCOMET-XL, GEMBA-DA | Quality estimation without a human reference, which is what you need before translation, not after. XCOMET-XL follows the MQM framework. GEMBA-DA is an LLM used as a judge. |
The threshold is the point
A score on its own says nothing. What makes it operational is a threshold: the number above or below which the output is good enough to use without post-editing. In the MTQE and APE sessions that threshold becomes a decision node in the workflow, an if/else that sends clean segments straight through and routes the rest to post-editing or to a human checkpoint. That is the whole economic argument of quality estimation, and it only works if the threshold was set against your content and your risk, not copied from a paper.
Three warnings from the material
- Lexical metrics do not measure meaning. BLEU and TER compare strings. A fluent, correct translation that chose different words can score badly, and a literal wrong one can score well.
- Automatic evaluation misses the nuances. Tags, casing, terminology, character display and locale formats are exactly the items the sessions list as issues the scores do not catch. That is why the checklist above still has a human on it.
- Beware of overfitting, in prompts as much as in models. A prompt tuned until it passes your test set can fail on real content. The test set has to be representative, cleaned, and large enough to mean something.
And the recommendation the sessions end on is not a tool: hybrid workflows are here to stay, assess where quality estimation and automatic post-editing actually add value in your pipeline, agree the quality level with the client before you promise "instant translation", and keep the linguist in the loop, because the feedback is what improves the system.
8. What the Model Actually Returned
Both runs below are real API calls, not illustrations. Model: deepseek-chat, temperature 0, sent on 21 September 2026 to the DeepSeek chat completions endpoint. Same five segments in both runs, and the segments are real AI outputs documented in our own course demos: a casual greeting rendered as formal corporate language in German, "bug" rendered as an insect in Italian, a two-word button label expanded into a sentence, the brand term "workspace" replaced by "account" in Japanese, and a trial reminder turned into a stiff French notice. The quoted output is verbatim, with the dashes in it normalised to hyphens.
Run A: the thin prompt
Prompt: "Compare the English text and the translation below and tell me if the translation is correct. Should you find any differences, list them according to translation error categories." No checklist, no glossary, no brand brief, no output format.
The model flagged all five segments as incorrect and got the diagnosis broadly right, in 17 free-text observations: register mismatch, "bug" read as an animal, an over-translated button label, the product term swapped. Three things about that output matter more than the diagnosis.
- No severity, no score, no verdict. Nothing in it can be totalled, compared with a threshold or handed to a client as a number.
- The categories are improvised per segment. "Register/Tone mismatch", "False friend / wrong sense", "Word choice / connotation", "UI constraint / length": useful labels, invented as it went, so nothing can be aggregated across a project or compared with the next file.
- It drifted on the target language. For the segment whose target is French, the run closed with a suggested rewrite in German: "Hey - deine Testphase endet in 3 Tagen. Wähl einen Plan, um weiterzumachen." Nothing in the prompt pinned the target language down, and nothing in the output warned the reader.
Run B: the structured prompt
The same model, with the four-part anatomy, the checklist attached and the report table requested:
| Error category | Subcategory | Severity | Source | Target | Description |
|---|---|---|---|---|---|
| Accuracy | Mistranslation | Major | Hey, ready to send your first message? | Greetings, are you prepared to dispatch your initial communication? | "Hey" is rendered as "Greetings" and "ready to send your first message?" as "are you prepared to dispatch your initial communication?" - the casual, direct, second-person register is lost and the meaning is distorted ("dispatch your initial communication" is not equivalent to "send your first message"). |
| Linguistic conventions | Unidiomatic | Major | Hey, ready to send your first message? | Greetings, are you prepared to dispatch your initial communication? | The phrasing is stilted and overly formal, violating the brand voice (casual, direct, second person). |
| Accuracy | Mistranslation | Critical | Found a bug? Report it here. | Found an insect? Report it here. | "Bug" (software defect) is mistranslated as "insect" (literal animal), completely changing the meaning. |
| Accuracy | Addition | Minor | Open draft | Open the draft document | "the" and "document" are added; the source is a short UI button label and the target is unnecessarily expanded. |
| Linguistic conventions | Unidiomatic | Minor | Open draft | Open the draft document | The added words make the label less concise and less suitable for a UI button. |
| Terminology | Non-compliance with the glossary | Critical | Invite your team to your workspace. | Invite your team to your account. | "Workspace" is the mandated brand term and must never be replaced by "account"; the target uses "account", a direct glossary violation. |
| Accuracy | Mistranslation | Major | Hey - your trial ends in 3 days. Pick a plan to keep going. | Greetings, your trial period expires in three days. Please select a subscription plan to continue. | "Hey" is rendered as "Greetings"; "Pick a plan" is rendered as "Please select a subscription plan" (not a direct verb, and "subscription" is added); "to keep going" is rendered as "to continue" (less casual). |
| Linguistic conventions | Unidiomatic | Major | Hey - your trial ends in 3 days. Pick a plan to keep going. | Greetings, your trial period expires in three days. Please select a subscription plan to continue. | The register is corporate and formal, violating the casual, direct, second-person brand voice. |
| Formatting errors | Number format | Minor | 3 days | three days | The numeral "3" is spelled out as "three"; for a trial-expiry message, the numeral is typically preferred for scannability and consistency. |
Then the closing paragraph, also verbatim:
"What I could not check with the material provided: I could not verify the actual target-language strings (German, Italian, Japanese, French) directly, since only back-translations into English were supplied; therefore I could not assess locale-specific punctuation, spelling, grammar, address/date/currency/unit conventions, or whether the back-translations faithfully reflect the original target text. I also could not check consistency across the rest of the product or confirm whether any other glossary terms apply beyond 'workspace'."
Nine findings, each with a category, a subcategory, a severity, both strings and a description. Two Critical, four Major, three Minor. The two Critical rows are the interesting ones: the insect mistranslation, and the glossary violation, which stopped being a risk and became a confirmed breach the moment the term was in the prompt. It also produced a finding the thin run never touched: the numeral "3" written out as "three", logged under formatting and number format. And it declared, unprompted, what it had not been able to check.
Figure 2. Severity distribution of the structured run's nine findings on our own course material, with the checklist block each one belongs to in the note. The thin run produced no severities at all: 17 free-text observations, no categories, no score and no verdict, which is the difference between a reading and a report.
The conclusion is not "the model got smarter". Both runs named the same documented failures, and the thin one named more of them than the structured one, in more words. What the structured run produced is something the thin one could not: severities, a fixed category for every finding, a glossary breach confirmed rather than suspected, a finding on numeral style, and a written statement of what it had not checked. That is exactly the argument of our quality course: the control lever is not the model, it is the instructions and the assets you hand it. The thin run would have shipped a button label that does not fit its button, in a report a client cannot act on.
9. The Error Report You Can Hand to a Client
The report has to survive a client who is not a linguist, and it has to drive a change. We use the TAUS DQF template as the skeleton, because a client already knows it, and we add the course's reporting layer on top of it.
The job block
Content type, source and target language, text size reviewed in words and the percentage of the job that represents, which technologies and resources were used (translation memory, MT system and version, termbase, style guide), who reviewed and when. One line each. This block is what stops the argument later about what was actually looked at.
The error log
| Column | What it takes |
|---|---|
| Segment | File name or segment number, so the fix can be applied. |
| Error category | From the checklist: accuracy, terminology, register, formatting, coherence, style. Fixed list, no free text. |
| Error subcategory | Addition, omission, mistranslation, untranslated text, number format, date format, units, markup, inconsistency, and so on. |
| Severity | Minor, major or critical. |
| Source and target | The two strings, verbatim, plus your suggested correction. |
| Description | One sentence a product manager can read. Not a lecture. |
| Comments | Things that are not errors: a repeated issue, an instruction or glossary change still pending, a reviewer preference. |
The score
Penalty points by severity, totalled, expressed per 1,000 words and compared with the maximum the client allows, against the 2 to 20 point band. PASS or FAIL, and one sentence on what the number does not cover.
The one-pager
The fourth pillar of the quality role is communication, and the course gives it a concrete format: three recurring issues, the actions taken, and one before-and-after example, sent monthly. Three rows, not a dissertation. That page is what turns a review into a glossary update, a prompt rule or a style-guide change, and it is the difference between fixing today's output and improving the system that produces tomorrow's.
10. What AI Does Not Catch Well
This is the part most articles about AI quality skip. It is also the part our course spends the most time on, with real runs behind it.
1. When it corrects itself, it approves itself
We tested this one rather than asserting it. The same model was asked to translate the trial reminder into Spanish with the brand brief, and then asked to run the full checklist on its own translation. What it produced was "Oye, tu prueba termina en 3 días. Elige un plan y sigue." Reviewing that, it found one issue: "y sigue" turns the purpose of the source (pick a plan so you can keep going) into a sequence, logged as a Minor mistranslation. Everything else in its own output was declared consistent: "Punctuation, spelling, grammar, number format, and register are all consistent with the brand voice." So the honest version is not "it finds nothing". It is that it catches a surface nuance and then approves the decisions it just took itself, including the register and the number style it chose two paragraphs earlier. One small run is not a benchmark, and the point holds either way: separate the roles. The model that fixes is not the reviewer that grades, and neither of them is the person who signs the report.
2. Register is where AI fails most, and it fails confidently
The clearest example in the course is a real one: "Hey, ready to send your first message?" came back in German as "Greetings, are you prepared to dispatch your initial communication?" No grammar error anywhere. The output is technically correct and brand-wrong, because no tone instruction existed, so the model defaulted to formal. A model asked to review that without the tone brief will often call it fine, because nothing in the string is broken. Register only becomes visible when you hand the reviewer the brand voice, which is what the AI brief in the four-asset toolkit is for: audience, tone, forbidden phrasing, and two or three examples.
3. Domain precision needs the glossary, not the model
Our MT evaluation material carries the canonical failures, and they are all the same shape: a word with two legitimate meanings in different domains. The Italian canali rendered as canals instead of channels. An English musicological term rendered literally into German as Hund instead of the term the database specifies. The classic and dangerous one: a source that says a medicine should not be administered above a dose, translated into a target that says it should, because the negation went missing. A model reviewing that text can flag it if it is told which terms are controlled. Without the termbase it is guessing, and it will often guess elegantly.
4. Coherence across a long document is invisible in a one-pass review
Segment-by-segment checking cannot see drift. A model reviewing 20 random segments will not tell you that the term it chose for "board" in chapter 2 is not the term it chose in chapter 9, and it will not notice that two speakers in a dialogue have started to sound identical. The course's answer is structural rather than clever: build an error library, one entry per example, because patterns become visible across entries, not within them. Twenty logged errors will show you the three patterns worth fixing; one clever prompt will not.
5. The bias towards the machine's own output
This is the failure our quality session keeps coming back to, in the phrase every specialist eventually hears: "the LLM told us it is correct." The story in the course is concrete. A client arrived with a quality audit that scored their content 6 out of 10, run with a one-line prompt, and the findings did not hold up when the parameters were examined. The trainer's own account of the other direction is just as concrete: an attempt to build an automatic review that would read translated pages and return scores failed, tested with Italian, which she speaks, and with native specialists for other languages, and it did not survive contact with real content. Our own machine translation evaluation session adds the reason to keep a human in the loop, in the list of things automatic scores miss: tag handling, terminology, casing, incorrect character display. The ContentQuo framework in our AI LQA course puts the same point in one line: a QA tool can highlight obvious issues only, and AI LQA needs a baseline and misses edge cases.
6. The quiet rows of the checklist
Numbers, dates, units and tags fail in ways that leave no smell. A date is plausible, a unit is familiar, a placeholder looks like a placeholder. This is precisely where the automatic metrics are weakest, and where our own run above returned nothing, because the sample contained none of those elements. On a real job, do those rows by eye, and do them after the model has finished, not before.
The honest summary: a model is a very fast, very confident first reader. It categorises well when you give it the checklist, it finds obvious meaning errors, and it will tell you it is done before it is. Fifteen minutes with it saves you an hour. They do not replace the second hour, and they never replace the person who signs.
11. The 15-Minute Routine
- Minutes 0 to 2. Choose the sample. The critical flow, the top help pages, or 10% of the job. Fix the content type before you open the file, because the register brief changes with it.
- Minutes 2 to 5. Build the prompt. Role, context, constraints, two or three examples. Attach the checklist and the glossary. Ask for the table and for "no errors" when there are none.
- Minutes 5 to 8. Read the table, row by row. Accept, reclassify or reject each finding. Reject the preferences, and say so: they go in Comments, not in the score.
- Minutes 8 to 12. Check what the model cannot. The target language itself, the terms against the glossary, and the quiet rows: numbers, dates, units, tags, placeholders.
- Minutes 12 to 15. Score and write three lines. Severities, penalty points per 1,000 words, PASS or FAIL, and the three recurring issues for the client. Feed whatever you found into the glossary, the style brief or the prompt. If nothing feeds back, the 15 minutes bought you one fixed file and nothing else.
12. FAQ
Can I really check a translation in 15 minutes?
A sample of it, yes, and well enough to be useful. Fifteen minutes is a high-impact review of the segments that matter, or about 10% of a 10,000-word job, which our AI LQA material treats as a meaningful sample. Full coverage of a large job is a different service with a different price.
Do I need a dedicated LQA tool?
No. The most common setup is a spreadsheet or the LQA module of your translation management system. What you cannot skip is the checklist, the glossary and the severity scale. The tool makes the reporting easier; it does not create the method.
Which model should I use for the check?
The one you can attach your assets to and whose output you can verify. The criterion that matters is not the model but the instructions: the same model produced a formal, unusable translation from "Translate this to French" and a correct on-brand one from the full prompt. If your tool lets you store the prompt and the glossary per language and content type, that matters more than the engine's name.
Is a model's review enough to sign off a translation?
No. Our own material is explicit that no evaluation system is safe enough without human intervention, and that automatic scores miss tag handling, terminology, casing and character display. The model gives you a structured first pass; the specialist gives you the verdict.
What do I do with the findings?
Sort them into three buckets: fix the file, fix the asset, or note it as a preference. The second bucket is the one that pays. A recurring terminology error is a glossary entry, a recurring register error is an AI brief, a recurring length problem is a prompt rule.
How do I charge for this?
Our quality course makes the case for pricing the deliverable and the outcome rather than the hour, and starts with an audit: glossary review, prompt teardown, an LQA scorecard and a short prioritised report. The AI Quality Specialist guide covers the packaging in detail.
Courses and Further Reading
If you want to run this properly, the material behind this article is taught, not guessed. The error categories, the prompt anatomy, the assets and the LQA loop come from From Post-Editor to AI Quality Specialist, taught by Nicola Calabrese across three sessions. The automatic evaluation, the thresholds and the human checkpoint come from the machine translation evaluation sessions of the Master, taught by Andres Romero.
The two courses below are the direct sources of the checklist, the prompt and the reporting format.
Terminology is the other half of quality, and it is where most of the errors above actually live.
And if you want the engine side, where the metrics, thresholds and human evaluation come from:
You can also read the courses and articles that go deeper on specific parts of this workflow: the practical guide to machine translation post-editing, best practices for MT and AI post-editing, what AI can translate and how to check it, AI translation, productivity and quality, and designing AI pipelines for localization.
Two courses on the terminology side are worth bookmarking for when you need the full framework rather than the working list: Strategic Terminology Management for Global Success and Evaluating Translation Through MQM, which is where the weighted, client-adapted scoring model is explained properly.
Put the method to work: see who is hiring for it on the TranslaStars job board, check your tool stack with the free CAT and TMS comparison tool, and browse the full AI and localization courses catalogue. Free audios on quality, AI and terminology are on TranslaStars Audio.









