The Case for Doing Pre-Production Work Before MTPE Even Starts

mt-expert # Why Is MT So Sensitive to Source Text Quality?

Q. Why does the quality of the source text matter so much for MT output? Can't a good engine just handle a messy source?

A. MT does not correct for context the way a human translator does. It generates output based directly on the input it receives, so whatever ambiguity, inconsistency, or structural problem exists in the source tends to propagate straight into the translation rather than getting silently resolved along the way.

Source Problem	Resulting MT Problem
Overly long sentences	Structure gets tangled, or part of the meaning is dropped
Heavy use of pronouns and demonstratives	Mistranslated reference for "it," "this," "they"
Inconsistent terminology	The same concept gets translated differently each time it appears
Typos or ungrammatical source	Garbled or untranslated output
Ambiguous phrasing	The wrong sense of a word or sentence gets selected
Complex tags or placeholders	Tag corruption, mistranslated variables
Short UI strings with no surrounding context	Mistranslated function, inconsistent tone

In short, pre-editing is the work of reducing the chance that MT misreads the source in the first place, before a single segment is even translated.

Does Pre-Editing Actually Reduce the Post-Editing Workload?

Q. Is this just shifting work from post-editing to an earlier stage, or does it genuinely save effort overall?

A. It genuinely reduces the total effort, because the kind of work it eliminates is the most expensive kind for a post-editor to do.

Without Pre-Editing	With Pre-Editing
Post-editor has to re-interpret tangled sentence structure	MT output is already structurally stable
Omissions and mistranslations have to be hunted down	Fewer omissions occur in the first place
Terminology has to be reconciled after the fact	Terminology is already consistent going in
Tag errors have to be manually corrected	Tag handling rules were defined before translation
Client queries increase mid-project	Ambiguity is resolved upstream, before it reaches the linguist
Review stages keep surfacing the same recurring errors	Recurring errors are caught once, at the source

Without pre-editing, post-editors frequently end up re-translating rather than editing. With it, the MT output is stable enough that the work stays correction-focused, which is both faster and cheaper.

How Does Pre-Editing Improve Terminology and Style Consistency?

Q. From an LSP's perspective, why is this particular benefit such a high priority?

A. Because terminology drift is one of the most visible, most client-facing quality issues, and it is almost entirely preventable upstream. Cleaning up the following during pre-production has an outsized effect on MT quality:

Termbase and glossary application
A defined "Do Not Translate" list
Locked product, feature, and UI names
Abbreviations spelled out
Forbidden terms and preferred terms documented
A defined style register

A simple example makes this concrete: if the source text mixes account settings, profile settings, and user preferences to describe the same feature, MT is likely to translate each one differently, even though a human reader would understand they refer to the same thing. Standardizing this at the pre-editing stage removes a downstream burden from both post-editing and LQA.

Making Sentence Structure MT-Friendly

Q. What does it actually look like to make a sentence "MT-friendly"? Isn't this just rewriting for style?

A. Not quite. Pre-editing is less about making a sentence read more elegantly and more about removing ambiguity that a machine, unlike a human, cannot resolve through inference:

Before	After
Click it to proceed.	Click the Continue button to proceed.
This may affect them.	This may affect registered users.
The feature, which was previously available only to admins, can now be used by all users who have completed verification.	The feature was previously available only to admins. Now, all verified users can use it.
Check your docs before using it.	Check the documentation before using the feature.

Each change replaces a pronoun, a buried clause, or a vague reference with something explicit, which lets MT correctly identify the subject, object, and what each reference actually points to.

How Does Pre-Editing Reduce Tag, Variable, and UI String Errors?

Q. Software and app content is full of tags and variables. What goes wrong here specifically, and how does pre-editing help?

A. Software, app, web, and marketing-automation content is dense with elements like these:

{user_name}
%s
<b>text</b>
[ProductName]
Button, menu, and path labels
Short, context-free UI strings

Take a simple example:

Welcome, {user_name}!

If MT translates the variable itself, or shifts its position in a way that breaks the placeholder syntax, the string can fail at runtime, not just read awkwardly. Defining DNT rules, protecting placeholders, and adding short context notes during pre-production substantially reduces this risk before it ever reaches a post-editor.

Does Pre-Editing Help With Cost Estimation and Quality Prediction?

Q. Is pre-editing only about quality, or does it also feed into project planning?

A. It feeds directly into planning, and this is often underused as a benefit. Sampling the source text during pre-production lets a team predict, before committing to a workflow:

How well-suited the content is to MT in the first place
Whether full PE is required, or light PE is sufficient
Whether certain segments are better handled by human translation
Expected post-editor productivity
The likely scale of terminology and style issues
How many client queries the project is likely to generate

In other words, pre-editing work doubles as a risk assessment input that shapes quoting, scheduling, and resource assignment, not just a quality lever applied after the fact.

Which Content Types Benefit Most From Pre-Editing?

Q. Does every project need the same level of pre-editing effort?

A. No, the payoff varies significantly by content type:

Content Type	Pre-Editing Value
Technical documentation	High
Software UI	High
Help center / manuals	High
Legal, medical, or regulated content	Very High
Marketing copy	Optional, human translation is usually preferable when transcreation is needed
High-repetition bulk content	High
Low-quality, non-native-authored source	Very High
Social / UGC / short-form content	Needed mainly for context reinforcement

Is Pre-Editing Always Worth Doing?

Q. Are there cases where pre-editing isn't actually worth the investment?

A. Yes, pre-editing has a cost too, and applying it everywhere by default is not the right call.

Good candidates for pre-editing:

High-volume projects
Recurring, repeat-delivery projects
Projects where MTPE productivity needs to improve
Source content of inconsistent quality
Projects where terminology consistency is critical
Regulated content
Simultaneous multilingual delivery
Projects where LQA is expected to surface repeat errors

Cases where it's not worth doing extensively:

Small, one-off documents
Source content that is already high quality
High-creativity copy being handled through human translation anyway
Cases where the pre-editing cost exceeds the post-editing savings, given the timeline

What Is the Core Argument for Pre-Editing?

Q. If you had to compress the entire case for pre-editing into one statement, what would it be?

Pre-editing reduces ambiguity, inconsistency, and structural problems in the source text upfront, so MT produces a more accurate and consistent first-pass translation, which in turn reduces MTPE cost, review risk, and post-delivery correction burden.

Closing thought: from an LSP's point of view, pre-editing is not a separate quality nice-to-have sitting beside the MTPE workflow. It is risk management, cost management, and QA prevention, applied at the one point in the pipeline where a small intervention has the largest downstream effect.