03 · What You Need to Know
What Should Stay the Same, and What Usually Needs to Change?
Separate the Search Concept From Its Database-Specific Expression
Before translating anything, identify the conceptual architecture of the original strategy.
Suppose your search contains two major concepts:
- teacher-related terms;
- burnout-related terms.
Within each concept, you may have subject headings and free-text alternatives connected with OR. The two concept groups may then be connected with AND.
That architecture is the part you generally want to preserve. The exact syntax used to express it is the part that may change.
Preserve
The research concepts, intended relationships among them, relevant free-text terminology, and rationale for each retrieval route.
Translate
Controlled-vocabulary terms, field codes, phrase syntax, truncation, wildcards, proximity operators, explosion commands, and other platform-specific instructions.
This distinction follows directly from why the same search syntax does not work in every research database. Translation is not character substitution. It is functional reconstruction.
Choose a Well-Developed Search as the Starting Strategy
For a multi-database search, it is usually more efficient to develop and test one principal strategy carefully before translating it into the remaining databases.
In health research, MEDLINE is often used as that starting point because its MeSH vocabulary and search interfaces are well documented, but there is no universal rule that the first strategy must be MEDLINE. The most appropriate starting database depends on the topic, discipline, database coverage, and available expertise.
What matters is that the source strategy is conceptually sound before translation begins. Translating an unfinished search merely reproduces its weaknesses in several dialects.
Do Not Start by Replacing Field Codes
A common translation method is to take the original string and begin replacing syntax: change one title code into another, substitute the truncation symbol, and replace the proximity operator.
That is risky because it encourages superficial equivalence.
Instead, annotate the original search by function:
Concept What idea does this line represent?
Vocabulary route Is this a controlled-vocabulary term or free-text expression?
Field Where is the free-text term intended to match?
Expansion Is truncation, a wildcard, synonym mapping, or hierarchical explosion being used?
Relationship Does phrase, proximity, Boolean grouping, or exclusion logic connect this expression to another?
Destination implementation How does the new database provide the same or closest useful retrieval function?
Once those questions are answered, the required syntax becomes much easier to identify.
Controlled Vocabulary Must Be Looked Up Again
This is one of the most important translation steps.
MEDLINE uses Medical Subject Headings (MeSH). Embase uses Emtree. CINAHL uses CINAHL Subject Headings. APA PsycInfo uses terminology from the APA Thesaurus of Psychological Index Terms.
Cochrane's current Handbook explicitly notes that controlled-vocabulary terms for MEDLINE and Embase are not identical and that their approaches to indexing differ. Search strategies therefore need to be customized for each database.
Do not simply copy a MeSH descriptor into Embase and assume that it functions as an Emtree term. Search the destination thesaurus for the concept itself.
Translate the Concept, Not Merely the Subject-Heading Label
Suppose the source strategy contains a controlled-vocabulary term. When you open the destination thesaurus, you may find:
- an apparently direct equivalent;
- a differently named preferred term;
- several narrower terms instead of one equivalent heading;
- a broader heading that requires additional free-text support;
- no satisfactory controlled-vocabulary equivalent.
Each situation requires a different decision.
Read the scope note or definition where available. Inspect broader and narrower terms. Check entry terms or synonyms. Examine how known relevant records are indexed.
The task is the same one involved in understanding how controlled vocabularies represent concepts, but now you are comparing two indexing systems rather than working within one.
Check Whether the Subject Heading Should Be Exploded
Hierarchical vocabularies often allow a heading to retrieve narrower concepts beneath it. This is commonly called exploding the term.
Cochrane recommends identifying appropriate controlled vocabulary, including exploded terms where suitable, because failure to include relevant narrower concepts can cause studies to be missed.
However, explosion behavior and syntax differ by database and interface. A source strategy may have relied on automatic explosion, while the destination database may require an explicit command or provide a different hierarchy.
Do not translate the heading without translating its hierarchical behavior.
Free-Text Terms Often Transfer Better Than Subject Headings, but They Still Need Review
A phrase used by authors can often remain useful across databases because it comes from the literature rather than the indexing system.
For example, teacher burnout may remain a useful free-text expression whether you search MEDLINE, PsycInfo, Scopus, or another relevant resource.
But free-text terminology should not be copied uncritically. Different databases cover different disciplines, and disciplinary communities may use different natural language for the same or overlapping concepts. Cochrane's Technical Supplement specifically notes that terminology appropriate in a general healthcare database may differ from terminology needed in a specialized database.
A translated strategy can therefore need additional free-text terms, not merely converted syntax.
Inspect Relevant Records in the Destination Database
One of the best ways to identify destination-specific terminology is to find several clearly relevant records in that database.
Inspect:
- their titles;
- their abstracts;
- author keywords;
- controlled-vocabulary terms;
- database-specific indexing fields.
You may discover terminology that was unnecessary in the source database but important in the destination database because of disciplinary coverage or indexing differences.
This is also a useful check that the translated vocabulary still represents the same concept rather than merely resembling the original words.
Translate Fields by What They Search, Not by Their Names
Suppose the source strategy searches free-text terms in Title/Abstract. The destination platform also offers something called Topic or Keyword. Which should you use?
The answer depends on the field definitions.
A field named Topic may include titles, abstracts, author keywords, and additional indexing. A Title/Abstract field may include author keywords in one database but not another. A default keyword search may search full text on one platform and only bibliographic metadata on another.
The correct translation therefore asks:
Which destination field most closely reproduces the information source I intended to search?
This is why the distinction among title, abstract, and keyword searching should be understood before translating field codes.
Do Not Assume Similar Field Codes Are Equivalent
A short code such as ti, ab, or kw can look self-explanatory. Its syntax and exact scope are still platform-specific.
Cochrane's current Handbook demonstrates this clearly by presenting different syntax for comparable search concepts across PubMed, Ovid MEDLINE, Embase.com, and Ovid Embase. PubMed may use a tag such as [tiab], Ovid uses dot-field syntax such as .ab., and Embase.com uses forms such as :ti,ab,tt.
The intention may be similar, but the technical expression is different.
Phrase Searching Needs to Be Rechecked
If the source strategy uses quotation marks, do not assume they produce an equivalent phrase search in the destination platform.
Ask:
- Does the database require quotation marks for phrases?
- Does it automatically search adjacent words as a phrase?
- Does quotation alter automatic mapping or stemming?
- Does the platform maintain a phrase index?
- Would proximity be a better translation of the original linguistic intention?
The phrase itself may transfer. The phrase-search behavior may not.
Truncation Must Be Rebuilt Using the Destination Rules
Suppose the original strategy uses:
educat*
The intention is to capture multiple word forms beginning with a shared stem.
In the destination database, check the truncation symbol, minimum number of characters, maximum expansion, permitted positions, and interaction with phrases or proximity.
Cochrane's Technical Supplement specifically warns that wildcard and truncation symbols vary across databases and interfaces and can even have opposite meanings in some systems.
Watch Out
Never translate truncation or wildcards by visual similarity alone. Confirm what the symbol means in the destination platform and test the resulting word forms before incorporating it into the final strategy.
Wildcards May Need a Different Symbol or Explicit Terms
A source strategy may use a wildcard to capture spelling differences such as randomized and randomised. The destination platform may use another wildcard character, may automatically handle the spelling variation, or may not support an equivalent internal wildcard.
If necessary, replace one compact wildcard expression with explicit OR terms.
The goal is not to preserve the wildcard. It is to preserve coverage of the relevant spelling variation.
Translate Proximity by Relationship, Not Operator Name
Proximity is particularly easy to mistranslate.
Suppose the source strategy means:
Find these terms within approximately five words of each other, in either order.
The destination database may use NEAR/n, Nn, ADJn, another operator, or a field-specific syntax. It may also count distance differently.
Before translating, write the intended relationship in plain language:
If the destination platform cannot reproduce the relationship exactly, document the adaptation and test its consequences.
Some Search Features Have No Direct Equivalent
Translation occasionally reaches a dead end. A destination database may not support an operator used in the source strategy.
Possible responses include:
- write several explicit phrase variants;
- replace truncation with explicit word forms;
- use a broader field and compensate with more specific terminology;
- use separate search lines rather than one nested expression;
- accept a somewhat broader or narrower implementation after testing it.
The absence of a direct equivalent is not permission to silently drop the function. Decide how best to approximate it and record what changed.
Automatic Term Processing Must Be Considered
Two identical-looking free-text searches can behave differently because the platforms automatically transform them differently.
PubMed, for example, uses Automatic Term Mapping for many untagged searches. Field tags, quotation marks, wildcards, and proximity syntax can alter that mapping.
Another platform may automatically include singular and plural forms, spelling variants, or stemming.
Translation therefore involves both what you explicitly type and what the platform silently adds.
Do Not Add Explicit Variants Until You Know What the Destination Database Already Does
Suppose your source strategy explicitly includes:
behavior OR behaviour
The destination database may automatically search both forms. Keeping both may be harmless, but it may also add unnecessary complexity. Conversely, assuming automatic equivalence where none exists can reduce retrieval.
Test representative terms and consult the official documentation. The same principle applies to plurals, possessives, hyphenation, diacritics, and other lexical variations.
Preserve Boolean Concept Structure Unless There Is a Substantive Reason to Change It
If the source strategy uses:
(A1 OR A2 OR A3) AND (B1 OR B2)
the destination strategy should ordinarily preserve the same conceptual architecture unless testing reveals a reason to revise it.
Do not accidentally transform OR alternatives into separate AND requirements while rewriting lines. Likewise, do not allow one synonym to escape its concept group because parentheses were lost.
For complex searches, rebuild concept groups independently and then combine them. This reduces the risk of subtle Boolean errors.
Translation Is Also an Opportunity to Catch Problems in the Original Search
Reconstructing a strategy forces you to examine each line closely. You may discover that a source term is ambiguous, a truncation stem is too broad, a concept is represented poorly, or a field restriction has no strong rationale.
Do not preserve an obvious error merely in the name of equivalence.
If you revise the conceptual strategy itself, however, apply that revision consistently across the databases where appropriate. Otherwise, you are no longer merely translating; you are running substantively different search strategies.
Translation change
The syntax or database-specific vocabulary changes while the intended retrieval concept remains the same.
Conceptual revision
The terms, concepts, or relationships change because you decided the original search strategy itself needed improvement.
Both can be legitimate. Keeping them conceptually separate makes the search process easier to document.
Do Not Expect Identical Result Counts
A translated strategy should not be judged by whether it produces the same number of records.
Different databases cover different journals, disciplines, publication types, dates, and document types. Even the same article can carry different indexing and metadata across resources.
If MEDLINE returns 2,500 records and Embase returns 4,100, that difference does not by itself indicate a translation failure.
Result counts are useful for detecting implausible behavior, not for proving equivalence.
Compare Concept Blocks Before Comparing the Final Search
When a translated strategy behaves unexpectedly, troubleshoot it concept by concept.
Suppose the final search retrieves dramatically fewer records than expected. Instead of modifying the complete query immediately, compare:
- the first concept block;
- the second concept block;
- controlled-vocabulary retrieval;
- free-text retrieval;
- individual high-impact terms;
- the final AND combination.
This can reveal that one subject heading was not exploded, one wildcard failed, or one field restriction is much narrower than its source equivalent.
Known Relevant Records Provide a Practical Translation Test
If you have several articles that clearly represent the research question, determine whether they are indexed in the destination database. If they are, test whether the translated strategy retrieves them.
If a known relevant article is present but missed, inspect the record. Which terminology and indexing does the destination database use? Which line of the translated search should have retrieved it? What failed?
This process can expose missing subject headings, inadequate free-text terms, or syntax that did not behave as expected.
Known-item testing cannot demonstrate complete sensitivity, but it is a valuable diagnostic tool.
Use the Destination Database's Own Documentation
Published systematic reviews and librarian guides can provide useful examples, but technical syntax changes over time.
Cochrane's Technical Supplement advises consulting the search-help documentation supplied by the relevant service provider and database because syntax, controlled vocabularies, operators, truncation, wildcards, and date fields vary across interfaces.
Use current official documentation to verify technical behavior, especially when the search contains complex operators.
Automated Translation Tools Can Help, but They Do Not Remove the Need for Review
Tools have been developed to convert database syntax automatically or semi-automatically. Cochrane's Technical Supplement discusses examples such as the Systematic Review Accelerator's Polyglot application and other conversion tools.
These can reduce repetitive syntax conversion, particularly for large search strategies.
However, Cochrane also notes an important limitation: automated syntax conversion does not resolve all differences in natural-language terminology or controlled vocabulary.
Watch Out
An automated translator can convert symbols without understanding whether the destination database uses a different preferred subject heading, whether another disciplinary term should be added, or whether the translated field is conceptually equivalent. Treat automated translation as a draft to verify, not as the completed search.
Peer Review Is Particularly Valuable for Complex Translations
Search translation involves many opportunities for small errors: a missing parenthesis, an incorrect field, an untranslated subject heading, a proximity operator with the wrong order behavior, or a truncation symbol that expands unexpectedly.
The PRESS guideline for peer review of electronic search strategies specifically includes Boolean and proximity operators, subject headings, text words, spelling and syntax among the elements that should be assessed. It also notes that proximity operators vary by search service.
For a high-stakes systematic review, involving an information specialist or obtaining peer review of the strategy can therefore be more than editorial tidiness. It is a methodological quality-control step.
Document Each Search Exactly as It Was Run
Translation produces database-specific strategies, so each final strategy should be preserved separately.
Cochrane recommends saving bibliographic database search strategies exactly as run, together with search-set numbers and retrieval totals where applicable. Its reporting guidance also calls for the database, access platform, search fields, limitations or settings, and complete line-by-line strategies to be documented in supplementary materials.
Do not reconstruct the search from memory after screening has begun. Database syntax has enough personality without asking your memory to become part of the method.
A Translation Table Can Make the Process Easier to Audit
For complex projects, create a working table that maps the main search functions across databases.
| Search Element |
Source Database |
Destination Database |
Translation Check |
| Controlled vocabulary |
Source subject heading |
Destination thesaurus term |
Scope, hierarchy, explosion, indexing checked |
| Free-text field |
Source title/abstract field |
Closest destination field |
Field definitions compared |
| Truncation |
Source symbol and stem |
Destination syntax |
Expansion tested |
| Wildcard |
Source wildcard |
Destination wildcard or explicit variants |
Character behavior checked |
| Proximity |
Source operator and distance |
Destination equivalent |
Distance and word order checked |
| Phrase |
Source phrase syntax |
Destination phrase syntax |
Automatic processing checked |
| Final Boolean structure |
Source concept groups |
Translated concept groups |
AND/OR logic preserved |
The table is a working aid rather than a mandatory reporting format. Its value is that it forces each translated feature to have an explicit rationale.
