How People Translate Quickly | Custom Spellcheck Dictionaries: Teach the QA Layer Which Names and Terms Are Actually Correct

People searching CAT tool custom dictionary, translation spellcheck dictionary, add words to spellcheck in CAT tools, translation spelling exceptions, custom spelling dictionary for translators, or how to stop valid product names triggering spellcheck are usually dealing with a small problem that becomes expensive at scale: the checker keeps flagging words that are actually correct.

A translation project may contain hundreds of proper names, product names, acronyms, scientific terms, compounds, transliterations, technical identifiers, and market-specific spellings. If the spellchecker treats every one as suspicious, translators either spend time dismissing the same false alarms or become so used to red underlines that they stop noticing real spelling errors. Current CAT environments still expose custom dictionary or spellcheck-exception functions precisely because a useful QA layer needs to learn the project’s legitimate vocabulary.

This article has one dominant reader job: build and maintain a small, controlled custom spellcheck dictionary so valid project vocabulary stops creating noise while genuine misspellings remain visible. It is not a general guide to terminology management, glossary compliance, style guides, or automated QA profiles. The focus is the spelling layer: what should the checker consider a valid word?

Quick answer

Use a custom spelling dictionary when the same valid words repeatedly trigger false spelling warnings.

A safe workflow is:

1. choose the correct target-language dictionary first;
2. confirm that the flagged word is genuinely correct;
3. decide whether the word is globally valid, client-specific, product-specific, or temporary;
4. add only stable legitimate forms to the appropriate custom dictionary;
5. keep product names, proper names, technical vocabulary, and approved transliterations consistent;
6. avoid adding misspellings merely to silence warnings;
7. audit the custom dictionary periodically;
8. remove obsolete names and accidental entries;
9. continue treating unknown words as prompts to verify, not annoyances to suppress.

The key principle is:

reduce false positives without training the checker to accept errors.

Why spellcheck noise slows translation

Imagine a 6,000-word product guide.

The target contains these valid strings repeatedly:

• AcmeCloud;
• XZ-700;
• Kubernetes;
• OAuth;
• PostgreSQL;
• eSIM;
• microservice;
• client surname;
• internal feature name.

If the spellchecker flags each occurrence, the translator sees dozens or hundreds of warnings.

At first, each one receives attention.

Later, the eye learns:

red underline probably means nothing.

That is dangerous.

Now a real misspelling can hide inside a field of false alarms.

The problem is not merely wasted clicks.

It is loss of signal.

Spellcheck is a cheap but valuable QA layer

Spellcheck catches errors that humans often miss because the brain normalizes familiar text.

Examples:

• transposed letters;
• doubled letters;
• missing letter;
• wrong accent;
• wrong apostrophe;
• accidental English carryover;
• typing slip.

These are inexpensive errors to catch automatically.

But the checker only remains useful if its vocabulary roughly matches the project’s legitimate language.

Custom dictionaries improve that match.

Step 1: verify the base language first

Before creating exceptions, confirm that the editor is using the correct target language or locale.

A French-Canadian translation checked against French-France settings may produce different warnings.

An English-UK project checked against English-US may flag:

• colour;
• organisation;
• centre.

Do not solve a locale configuration problem by adding hundreds of words to a custom dictionary.

First fix the base dictionary.

Then add genuine project vocabulary.

Step 2: verify before you add

When the spellchecker flags a word, ask:

Is this definitely correct?

Do not click “Add to dictionary” reflexively.

Check:

• source;
• glossary;
• product documentation;
• client reference;
• authoritative website;
• official spelling;
• capitalization;
• hyphenation;
• accent;
• locale.

A custom dictionary entry can persist.

One careless click can normalize an error across future work.

The dangerous convenience button

“Add to dictionary” is tempting because it removes the red underline instantly.

That creates a behavioral risk:

annoying warning → click add → continue.

Instead use a rule:

Never add a word merely because the warning is inconvenient.

Add it because you have positive evidence the form is legitimate.

Step 3: classify the word before adding it

A flagged valid form may belong to different scopes.

General-language word

Legitimate dictionary word missing from the current spellchecker.

Domain term

Specialized vocabulary used across a subject area.

Client term

Specific to one organization.

Product term

Specific to one product family.

Proper name

Person, place, institution, company.

Temporary project token

One-off code, campaign name, or test identifier.

The scope helps determine where the entry belongs.

Personal dictionary versus shared dictionary

A translator may have a personal custom dictionary.

A team may maintain a shared project dictionary.

These serve different needs.

Personal dictionary

Useful for:

• general target-language words;
• stable professional vocabulary;
• common names you encounter often.

Shared client or project dictionary

Useful for:

• product names;
• recurring feature names;
• approved proper nouns;
• domain vocabulary relevant to the team.

Do not put confidential client-specific vocabulary into a broadly shared personal resource without considering policy and access.

Step 4: separate spelling validity from terminology approval

This distinction is crucial.

A word can be spelled correctly and still be the wrong term.

Suppose:

• “filesystem” is a valid spelling;
• client requires “file system.”

Adding “filesystem” to spellcheck does not mean it is approved terminology.

Spellcheck asks:

Is this token orthographically valid?

Terminology QA asks:

Is this the correct term for this concept and project?

Do not use the custom dictionary as a substitute for a glossary.

A simple resource map

Spellcheck dictionary

Valid word forms.

Glossary or termbase

Approved concepts and terminology.

Style guide

Writing conventions.

Translation memory

Previous source-target decisions.

Each resource has a job.

Fast translators use the right one.

Worked example 1: product name

Product name:

CloudFlowX

The checker flags it every time.

The product website, glossary, and client materials confirm that exact capitalization.

Good action:

• add CloudFlowX to the client or project custom dictionary.

Bad action:

• add cloudflowx;
• add CloudflowX;
• add every capitalization variant.

Why?

Because wrong capitalization should remain visible.

A custom dictionary should preserve the authoritative form when the platform supports case sensitivity appropriately.

Worked example 2: person name

A report mentions:

Szymborska

Spellchecker flags it.

The name is correct.

If it appears throughout the project, adding it can reduce noise.

But consider whether:

• the name is one-off;
• the dictionary is persistent;
• privacy policy permits storing names;
• the project is sensitive.

Sometimes “ignore for this document” is better than “add permanently.”

Scope matters.

Step 5: choose between ignore-once, ignore-all, and add

Many spellcheckers offer variants of:

• ignore once;
• ignore all;
• add to dictionary.

Use them intentionally.

Ignore once

Word is legitimate only in this context or you are uncertain.

Ignore all in current file/session

Repeated one-off name or code does not deserve persistent storage.

Add to dictionary

Stable legitimate vocabulary should be recognized in future work.

This decision prevents dictionary bloat.

Step 6: keep codes out when the checker can exclude them automatically

Not every strange token belongs in a dictionary.

Examples:

• AB-217;
• v4.8.2;
• SKU_9931;
• user_id;
• URL;
• email address.

If the QA system can ignore patterns such as codes, numbers, URLs, or identifiers safely, use that rule.

A dictionary filled with arbitrary IDs becomes useless.

Pattern exclusions and dictionary entries solve different problems.

Step 7: handle compounds carefully

Many languages permit productive compounds.

A spellchecker may flag valid compounds not present in its base lexicon.

Before adding:

• confirm spelling conventions;
• confirm hyphenation;
• confirm whether the compound is stable;
• confirm capitalization.

If a compound is project-specific and frequent, a custom entry is useful.

If it is a one-time creative formation, ignore may be better.

Step 8: handle inflection carefully

Should you add:

• lemma only;
• every inflected form;
• plural;
• gender variants;
• declined forms?

The answer depends on the spellcheck engine.

Some dictionaries understand morphology.

Others require surface forms.

Test the behavior.

Do not automatically add twenty forms if the base engine can derive them.

Do not assume it can.

Worked example 3: approved technical noun

Approved technical term:

microcontroller

Target language forms several grammatical variants.

If the spellchecker recognizes only the base form but flags every inflected form, the project may need:

• a language-specific dictionary update;
• multiple surface entries;
• a better spellcheck engine.

Repeated false positives are evidence about configuration.

Step 9: maintain capitalization rules

Custom dictionaries can accidentally make wrong case look acceptable.

Consider:

• PowerShell;
• JavaScript;
• iOS;
• eBay;
• acronym.

Correct case may carry brand identity.

If your checker cannot enforce case through dictionary behavior, use terminology or regex QA for brand-critical capitalization.

Spellcheck alone may be insufficient.

Step 10: treat diacritics as meaning-bearing

Names and words may differ by accent or diacritic.

Examples in many languages can change meaning or correctness when accents disappear.

Do not add unaccented variants simply because typing them is easier.

If the approved form uses a diacritic, keep the correct form authoritative.

Custom dictionaries should reinforce correct orthography.

False friends inside custom dictionaries

Suppose a translator accidentally adds a misspelling.

From then on, spellcheck stops flagging it.

That creates silent error.

This is the strongest reason to audit custom dictionaries.

Every custom entry should be treated as a rule:

this form is allowed.

Rules need maintenance.

Step 11: review accidental entries

People click quickly.

A translator may add:

• typo;
• partial word;
• source-language carryover;
• wrong capitalization;
• temporary placeholder.

Periodically inspect the custom dictionary.

Look for:

• suspicious one-character variants;
• duplicate case forms;
• obsolete products;
• personal names from old projects;
• codes;
• words better governed by terminology.

Cleaning restores signal.

A simple dictionary audit

Export or review the custom entries if the platform allows.

Classify each:

• keep;
• move to client dictionary;
• move to termbase;
• remove;
• investigate.

You do not need to audit every week.

High-use shared dictionaries deserve periodic attention.

Step 12: make the dictionary project-aware

A pharmaceutical translation and a gaming translation may need very different vocabulary.

If one universal dictionary contains every specialized token, the spellchecker may accept forms that are wrong for the current project.

Where possible, use scoped dictionaries:

• general;
• domain;
• client;
• project.

This preserves precision.

Worked example 4: same token, different project

A capitalized feature name is valid for Client A.

For Client B, the same string is an accidental English word that should have been translated.

If both share one massive custom dictionary, spellcheck will not help.

Scope prevents leakage.

Custom dictionaries and confidentiality

A dictionary can become a small repository of client information.

It may contain:

• unreleased product names;
• employee names;
• internal project codes;
• medical names;
• legal entities.

Treat it according to data policy.

Do not upload or synchronize sensitive dictionaries to unauthorized services.

Productivity controls still need privacy controls.

Step 13: use custom dictionaries to reduce QA fatigue

The goal is not to make the document free of red underlines.

The goal is to make each remaining underline worth attention.

A high-signal spelling layer feels different.

The translator sees a warning and thinks:

I should check that.

That response is valuable.

Signal-to-noise ratio

Think:

useful warnings / total warnings

If 100 warnings contain only 3 real errors, signal is poor.

If 20 warnings contain 15 real issues, signal is strong.

Custom dictionaries can improve this ratio by removing repeated known-valid forms.

QA profiles can improve it further by disabling irrelevant checks.

Step 14: do not hide source-language intrusions

In translation, one common error is leaving a source-language word in the target.

A custom dictionary can accidentally whitelist it.

Avoid adding source-language terms unless they are genuinely permitted target content:

• brand;
• technical standard;
• code;
• borrowed term approved by style.

Otherwise spellcheck may stop catching untranslated residues.

Worked example 5: English word in non-English target

The project repeatedly uses an English product name.

Adding the product name is correct.

But adding common English words because the source contains them is not.

The custom dictionary should stay narrow.

Step 15: pair spellcheck with terminology QA

Spellcheck can say:

datasheet is spelled correctly.

Termbase can say:

project requires another approved target term.

Both can be true.

Run both layers.

One checks orthography.

One checks terminology policy.

Pair spellcheck with grammar checking carefully

Some platforms add grammar or language-model suggestions.

These can introduce another source of warnings.

Do not combine uncontrolled systems until the signal becomes overwhelming.

Tune layers independently:

• spelling;
• terminology;
• punctuation;
• grammar;
• style.

Know which warning comes from which system.

Failure mode 1: adding every flagged word

Dictionary becomes huge and permissive.

Repair:

• require verification and stable scope.

Failure mode 2: using dictionary to silence wrong terminology

A valid spelling hides a term policy problem.

Repair:

• keep terminology in termbase.

Failure mode 3: adding wrong capitalization

Brand errors disappear from spellcheck.

Repair:

• store authoritative form;
• use case-sensitive terminology QA if needed.

Failure mode 4: storing one-off codes forever

Dictionary grows with meaningless noise.

Repair:

• ignore pattern or current document instead.

Failure mode 5: dictionary contains confidential names

Shared resource leaks information.

Repair:

• scope and access-control dictionaries.

Failure mode 6: stale product names remain accepted

Old brand spelling is no longer flagged.

Repair:

• audit after terminology migrations.

Failure mode 7: wrong base locale

Translator adds ordinary regional words manually.

Repair:

• use correct language dictionary.

Failure mode 8: spellchecker becomes trusted too much

No underline is assumed to mean “correct.”

Spellcheck cannot detect:

• wrong real word;
• wrong terminology;
• wrong meaning;
• grammar;
• omission.

Repair:

• understand the layer’s limits.

Real-word errors

Sentence contains:

form

but should contain:

from.

Both words are valid.

Spellcheck may not flag it.

This reminds us:

spellcheck checks lexical validity, not intended meaning.

Human revision remains necessary.

A safe “add to dictionary” checklist

Before adding a word:

• verified spelling?
• correct locale?
• stable enough to recur?
• correct capitalization?
• no privacy concern?
• not better handled by termbase?
• not an arbitrary code?
• not a source-language residue?
• appropriate dictionary scope?

If yes, add.

If uncertain, ignore temporarily and investigate.

A team custom-dictionary workflow

For recurring projects:

Translator

Proposes new valid term.

Reviewer or language lead

Verifies.

Resource owner

Adds to shared dictionary.

Team

Benefits immediately or in next sync.

This prevents each translator from maintaining incompatible local exceptions.

Fast approval for low-risk words

Not every dictionary addition needs committee review.

Create categories.

Low risk

Public product name, widely recognized technical term.

Quick add.

Medium risk

Client-specific coined term.

Check reference.

High risk

Regulated term, confidential codename, ambiguous form.

Require owner review.

Governance should be proportional.

Custom dictionaries and proper nouns

Proper names are among the best candidates for document-level ignoring and selective shared addition.

Ask:

• will name recur in many files?
• public or confidential?
• stable spelling?
• multiple transliterations?

For a public executive appearing in hundreds of corporate reports, shared recognition may be useful.

For a one-time customer name, persistent storage may be unnecessary.

Transliteration variants

Names can have multiple valid romanizations or transliterations.

Spellcheck cannot decide which project variant is authoritative.

Use:

• glossary;
• style guide;
• client instruction.

Then add only the approved form if useful.

Scientific names

Scientific vocabulary creates dense false positives.

A project may contain:

• Latin binomials;
• chemical names;
• gene symbols;
• protein names.

Before mass-adding them:

• identify which tokens need exact case;
• which should be italicized;
• which are symbols rather than words.

Some are better controlled through terminology or pattern QA.

Legal names

Registered entity names may require exact preservation.

Custom dictionary can remove spelling noise.

But exact legal form may include:

• punctuation;
• suffix;
• capitalization.

Use terminology or reference checks for full-form correctness.

Spellcheck is only one layer.

Software names and code tokens

Software localization contains many mixed tokens:

• API;
• class names;
• command names;
• filenames;
• package names.

Do not pour them all into the dictionary.

If patterns identify them reliably, exclude them from spelling checks instead.

Reserve dictionary entries for natural-language tokens that the checker should recognize as words.

Step 16: test the custom dictionary

After adding entries, deliberately type:

• correct form;
• wrong capitalization;
• one-letter misspelling;
• old product name.

Observe what the checker does.

A dictionary is a QA rule set.

Test the rules.

Dictionary migration between tools

Translators may change CAT tools.

Custom dictionaries may use:

• plain text;
• platform-specific formats;
• operating-system dictionaries.

When migrating:

1. export if possible;
2. clean obsolete entries;
3. separate personal and client vocabulary;
4. import into appropriate scope;
5. test case and morphology behavior.

Do not blindly copy years of accumulated noise.

Dictionary size is not quality

A 50,000-entry custom dictionary is not automatically better than a 500-entry one.

Quality depends on whether entries are:

• valid;
• relevant;
• scoped;
• maintained.

The perfect dictionary is not the biggest.

It is the one that makes warnings meaningful.

Measuring the benefit

Track a representative project.

Before cleanup:

• 430 spelling warnings;
• 390 false positives;
• 40 worth checking.

After controlled dictionary:

• 90 warnings;
• 50 false positives;
• 40 worth checking.

Real errors did not disappear.

Noise did.

The translator now spends less time dismissing valid vocabulary.

Another useful metric: repeat false positives

Count how many times the same valid word is flagged.

If one product name triggers 200 warnings, it is a high-value dictionary candidate.

Prioritize by frequency.

This is similar to term extraction:

fix repeated friction first.

Spellcheck during drafting versus final QA

Live spellcheck is useful for immediate typos.

Final spelling QA is useful after:

• review;
• copy changes;
• client edits;
• global replacements.

Run both where practical.

A reviewer can introduce a typo too.

Custom dictionary and review mode

If reviewers use a different machine or environment, they may not share the translator’s personal dictionary.

Then warnings reappear.

Shared project dictionaries can reduce this discrepancy.

If shared support is unavailable, provide:

• approved names list;
• domain lexicon;
• terminology resources.

Do not assume personal configuration travels automatically.

Build a minimal project lexicon

Before a large job, compile likely spelling exceptions:

• client name;
• product names;
• key people;
• common technical terms;
• approved transliterations.

Add verified entries before drafting.

This is especially useful for high-density specialized material.

Do not add unfinished terminology candidates

A term-extraction list may contain:

• noise;
• misspellings;
• variants;
• partial phrases.

Do not bulk-import it into spellcheck as accepted vocabulary.

Candidate extraction and spelling approval are different stages.

A five-minute dictionary preflight

Before a recurring project:

1. confirm target locale;
2. open custom dictionary;
3. remove obvious obsolete product names;
4. test current client name;
5. test one important technical term;
6. intentionally type one known misspelling.

You want proof that:

• valid recurring forms pass;