A translation decision log is where professional judgment becomes traceable. Translators make hundreds of choices that are not obvious from the final sentence: why one sense was chosen over another, why a term changed, why an apparent style-guide rule was deliberately broken, why an ambiguous source was interpreted one way, or why a reviewer request was rejected. If those choices live only in memory or scattered comments, the project loses them.
Searches for translation decision log, localization decision log, translation documentation, linguistic decision record, translation rationale, terminology decision history, translation audit trail and localization governance describe the same professional need: not every important translation choice belongs in a glossary or style guide, but important choices still need a durable home.
This guide explains how to build that home. It shows what deserves a log entry, what does not, how to record source evidence, alternatives, rationale, scope, status, ownership and version, how decision logs interact with termbases and style guides, how to handle exceptions and reviewer disagreements, and how to keep the log searchable enough that people actually use it.
This is part of eduKateSG’s Master Art of Translation architecture. It complements the translation style guide, the ambiguity and translator-query workflow and the review-feedback workflow. It does not replace those systems; it records the project-specific decisions that connect them.
The professional principle: preserve reasoning, not just outcomes
A termbase answers, “What term do we use?” A style guide answers, “How do we generally write?” A project brief answers, “What is this translation trying to achieve?” A decision log answers a different question: “What did we decide in this non-obvious case, why, on what evidence, and where does that decision apply?” That distinction prevents the log from becoming a duplicate glossary or a random notebook.
Professional translation contains many legitimate choices. Some are local and temporary. Some later become global terminology. Some are exceptions to a broad rule. Some resolve ambiguous source wording. Some record why a reviewer preference was not adopted. The decision log holds those cases long enough for the project to remain coherent.
1. Log decisions, not every sentence
A useful log records choices that future work might reasonably revisit. If every ordinary translation becomes an entry, the system becomes unreadable. If nothing is logged, the team repeatedly rediscovers difficult answers. The skill lies in recognising decisions with future value.
Good candidates include ambiguous source interpretations, terminology changes, deliberate style-guide exceptions, high-risk wording, reviewer disputes, source queries with authoritative answers, localisation choices that affect many strings, and product-specific meanings that are not obvious from dictionaries. An ordinary verb in an obvious sentence rarely needs an entry.
Ask: would another translator benefit from knowing that this choice existed before meeting the same problem? If yes, logging it is probably useful.
2. Give each decision a stable identifier
Decisions need identities that survive discussion and version changes. Without IDs, people refer to “the comment on page 12” or “that issue from last week.” Those labels stop working as soon as pages move, files change or several similar issues appear.
Use a simple scheme such as DL-010, DL-020 and DL-030, or add a project prefix where several products share one system. The number does not need to encode the entire meaning. Its job is to provide a stable handle that can be referenced in review comments, termbase notes, release records and change requests.
A reviewer can then say “Apply DL-120 to all onboarding screens” instead of copying a long explanation into ten comments. Stable references make reasoning portable.
3. Record the exact source context
A decision without context is easy to misuse. The same word can mean different things in different screens, genres or legal clauses. The same target term can be correct in one product and misleading in another.
Capture the relevant source phrase, sentence or string, plus location: file, screen, paragraph, component ID or other stable locator. Include enough surrounding language to recreate the interpretive problem without copying an entire document into the log.
If the source word is “Apply,” record whether it appeared on a filter button, a job page, a financial form or a cosmetic instruction. The decision is only as reusable as its context is clear.
4. Separate evidence from the decision
The log should show what supports the choice before it states the choice. This makes future review easier because new evidence can be compared with old evidence directly.
Evidence might include an official product definition, regulator terminology, a screenshot, a source-author answer, a corpus pattern, an authoritative bilingual publication or observed interface behaviour. Record that evidence separately from the final target wording.
“Use X because it sounds better” is weak documentation. “The regulator’s official target-language guidance uses X for this legal concept” is evidence that another reviewer can verify. A decision log becomes valuable when its reasoning can survive the person who originally made it.
5. Preserve credible alternatives
When a choice is genuinely non-obvious, note the serious alternatives that were considered. You do not need a list of every dictionary synonym. The purpose is to show why a future translator should not restart the same debate from zero.
For each credible alternative, write a short reason for rejection. Perhaps one term implies legal ownership that the source does not claim. Perhaps another is already used for a different product feature. Perhaps a third is grammatical but uncommon in the target domain.
Recording alternatives demonstrates that the final choice was the result of comparison rather than oversight.
6. Write rationale in operational language
Rationale should name the controlling constraint. Useful reasons include official terminology, reader action, legal scope, target-language collocation, interface consistency, source ambiguity, accessibility, brand voice or a documented style-guide rule.
Avoid explanations such as “nicer,” “better,” “more professional” or “sounds right” unless they are unpacked into observable target-language behaviour. Professional reasoning should be testable. If naturalness is the reason, explain what pattern native target-language writing normally uses in that genre.
The aim is not to eliminate judgment. It is to make judgment inspectable.
7. Define scope explicitly
A correct decision can become wrong when applied too broadly. Project terms, UI verbs and style exceptions often depend on content type, product area, jurisdiction or release.
Every important decision should say where it applies: all files, one module, legal content only, one screen family, one client, one locale, one release or one quoted passage. It should also say where it does not apply when overgeneralisation is likely.
A shortened mobile label approved for a navigation bar should not automatically become the preferred wording in explanatory prose. Scope tells future users where to stop.
8. Use statuses that distinguish certainty
Projects contain proposals, confirmed decisions, temporary workarounds, exceptions, rejected options and superseded rules. A shared log needs a small status vocabulary so users can tell which entries are authoritative.
A useful set might be proposed, provisional, confirmed, exception, rejected and superseded. Keep it small enough that people understand it without training. A translator’s best guess can remain provisional while a query is open, then become confirmed after the source owner replies.
Status prevents informal suggestions from hardening accidentally into institutional rules.
9. Record who proposed, validated and approved the choice
Decision authority can be distributed. A translator may propose a target term, an engineer may confirm what the feature does, a subject specialist may validate the concept and a client language owner may approve the public wording.
Record those roles when they matter. “Approved by” is different from “suggested by.” A comment from a colleague in chat should not be indistinguishable from a formal client decision if the distinction affects future work.
Clear ownership is especially important in high-risk or regulated content, where the right to decide may belong to someone other than the person with the strongest stylistic opinion.
10. Attach decisions to versions and releases
A decision can expire when the source changes. Definitions, products, policies and official terminology evolve. Record the source version, product release, date or other change boundary that supports the entry.
If a choice was based on Version 3 behaviour, it should be reconsidered when Version 4 changes the feature. If a regulator publishes new official terminology, the old decision may need to be superseded rather than quietly reused.
Version linkage converts the log from a timeless rulebook into a traceable history.
11. Connect stable terminology to the termbase
The decision log should not become a hidden duplicate glossary. When a term decision becomes reusable and authoritative, move the operational form into the termbase and keep the decision ID as historical rationale.
The termbase can then enforce the approved target term in CAT tools or QA checks. The decision log preserves why the term changed, what evidence controlled and which old alternatives were rejected.
This division of labour is powerful: the termbase optimises daily use; the decision log preserves governance and history.
12. Promote recurring style decisions into the style guide
The same principle applies to style. If the log accumulates repeated decisions that UI headings use sentence case, the project probably needs a formal style-guide rule rather than twenty separate entries.
The log captures cases. The style guide captures durable generalisations. A mature workflow lets recurring case decisions improve upstream guidance. That is how documentation reduces work over time instead of merely archiving it.
When promoting a decision, link the old entry to the new style-guide rule so future users can see where the rule came from.
13. Record resolved source queries
Source ambiguities often get resolved in email, chat, meetings or comments. Those answers are easy to lose. The decision log should capture material query outcomes once they affect translation.
Record the source location, the competing interpretations, the question sent, the authoritative answer and the scope of that answer. If a client confirms that “charge” means service fee in all billing screens, the entry should say exactly that and trigger a search for affected strings.
This prevents different translators from asking the same question weeks apart and implementing the answer differently.
14. Document intentional exceptions
Exceptions are safest when visible. A campaign title may intentionally break normal capitalisation. A legal quote may preserve source punctuation. A small device label may use an approved abbreviation that would be inappropriate elsewhere.
State the governing rule, the exception, why it exists, its narrow scope and whether it is temporary or permanent. Otherwise a well-meaning reviewer will “correct” the exception repeatedly.
An explicit exception protects both consistency and flexibility because it tells the team that the deviation is deliberate rather than accidental.
15. Summarise disagreements without storing entire debates
A log is not an email archive. Long comment histories make retrieval difficult, while deleting all history can hide why a choice was controversial. Summarise the competing positions, evidence considered and final resolution.
If two reviewers prefer different terms, record the substantive reason the final one controls. Perhaps the regulator uses it officially, the product team has standardised it or the other term already means something else. Preserve unresolved risk only if it remains material.
A reader should be able to understand the disagreement and the reason for resolution in under a minute.
16. Propagate decisions across affected content
A decision is incomplete until affected content has been found. Changing one occurrence while leaving ten older occurrences creates contradiction.
Define propagation scope, search translation memory and current files, update dependent entries and record completion. If a feature is renamed, check UI, help articles, onboarding messages, screenshots, termbase entries and training materials as appropriate.
The decision log is useful here because it turns “we changed this word” into a controlled change event with a known reason and known impact.
17. Make the log searchable
Documentation has value only if people can retrieve it at the moment of need. Large chronological spreadsheets become graveyards of good decisions when the only way to find something is to remember roughly when it happened.
Use fields for decision ID, source term or issue, target term, product area, content type, locale, status, date, version and tags. Keep rationale concise enough to scan. Search should be possible using the words a translator naturally has in front of them.
If finding an old decision takes longer than inventing a new one, the system will be bypassed.
18. Review and retire obsolete decisions
A living log needs maintenance. Old entries can mislead after products, policies or style guides change. Do not delete history casually; mark obsolete decisions as superseded and link them to the current entry.
This preserves auditability while making active guidance clear. A user who finds an old term decision should immediately see that it was replaced and why.
Retirement is especially important when old decisions were based on temporary constraints. A mobile abbreviation approved because of a 2024 character limit should not remain authoritative after the interface is redesigned.
19. Keep the format lightweight enough to survive
The best decision log is the one the team actually maintains. Complex forms encourage people to move decisions back into private chat because logging feels slower than thinking.
Use a small mandatory core: ID, issue and context, evidence, decision, rationale, scope, status, owner or approver and version. Add optional fields only when the project benefits from them.
A ten-field system used consistently is better than a forty-field governance framework everyone ignores. Traceability should reduce friction over the life of the project, not become a parallel bureaucracy.
A repeatable decision-record workflow
- Identify a non-obvious choice worth preserving.
- Assign a stable decision ID and capture precise source context.
- Collect evidence and list credible alternatives.
- State the chosen treatment and operational rationale.
- Define scope, status, owner, approval and source version.
- Link stable terminology to the termbase and recurring style to the style guide.
- Propagate the decision across affected content.
- Use the decision ID in reviews, queries and release notes.
- Revisit the decision when source versions or authorities change.
- Mark superseded decisions clearly while preserving history.
Worked professional scenarios
A product term changes after client review
A reviewer approves a new feature name that replaces a translation used across hundreds of strings. Create a decision entry citing the approval, define the change’s scope, update the termbase, search current assets and record the release in which the new term becomes authoritative. The decision log explains the history; the termbase enforces the current form.
A campaign needs one style-guide exception
A title intentionally uses unusual capitalisation for brand recognition. Record the normal rule, the exception, the reason, affected assets and an expiry condition if the campaign is temporary. Future proofreaders then know that the deviation is deliberate and should not propagate to unrelated content.
A source phrase remains ambiguous after research
Two readings are grammatically possible and context cannot resolve them. Log the interpretations and evidence, open a source query and mark the entry provisional. When an authoritative answer arrives, update the entry to confirmed and propagate the result. The record preserves uncertainty rather than pretending the original choice was obvious.
Two reviewers keep debating the same word
Each release triggers the same preference dispute. Summarise the competing views, cite the evidence that controls and record the approved rule. If it generalises, promote the rule into the style guide. Future reviewers can reference the decision ID instead of reopening the argument.
A feature is renamed across several channels
The source team updates the UI name, but help content and training material retain the old term. Create a superseding decision, define dependent assets and run a propagation search. Record completion so the project does not gradually drift into two names for one concept.
A legal term applies only in one jurisdiction
A regulator mandates a specific target-language term. Record the authoritative source and set jurisdiction-specific scope. Do not let the local decision become a global default if another jurisdiction uses a different legal concept or official name.
Practice lab: twenty decisions that deserve traceability
1. A dictionary offers two equally common senses
Record the contextual evidence that selects one sense: product behaviour, domain topic, surrounding clause or authoritative definition. If the choice is likely to recur, include rejected alternatives. The useful record explains why the same source word may be translated differently elsewhere.
2. A reviewer prefers a synonym
If the issue is genuine preference rather than error, record the project’s governing rule only if the preference is adopted broadly. Do not create a decision merely to preserve every stylistic suggestion. The log should capture choices with future operational value.
3. A translation breaks the style guide for legal accuracy
Document the specific legal constraint, the normal style rule and the narrow exception. This makes it clear that accuracy controls in this context without weakening the style guide elsewhere.
4. An official institution publishes a new name
Create a superseding decision with the authoritative source, effective date and propagation scope. Update the termbase and search current content for the old form. Historical quotations may require an explicit exception rather than automatic replacement.
5. A source-author answer resolves a pronoun
Record the answer if the pronoun interpretation affects several segments or future releases. Include the source location and who confirmed the referent. Do not let the answer disappear inside a chat thread.
6. A UI label is shortened for one device
Record the hard character limit, approved short form and device-specific scope. The full term should remain authoritative elsewhere. This prevents a workaround from silently becoming the preferred global wording.
7. A scientific term has a popular but imprecise translation
Record why the technical target term is required, cite the subject authority or standard and note the common alternative as rejected if reviewers are likely to propose it again.
8. A culturally specific joke is adapted
Document the communicative goal and the approved adaptation boundary, especially when the target wording departs significantly from literal meaning. This helps later reviewers distinguish creative equivalence from unauthorised rewriting.
9. A product team accepts an untranslated brand term
Record that the name remains unchanged, its capitalisation, plural behaviour and scope. Link the choice to the termbase so translators do not independently transliterate or translate it later.
10. A client rejects a standard industry term
Preserve the client’s approved preference and rationale if it governs future work. Mark whether it is a brand choice, jurisdiction requirement or temporary exception. This prevents future translators from ‘correcting’ the client back to the industry norm.
11. A source contains a known factual error
Record the query and authoritative resolution. Do not let the translation quietly fix the error without traceability, because later versions may reintroduce the source wording or auditors may compare source and target.
12. A reviewer requests stronger certainty
If the source says “may” and the reviewer wants “will,” record why the request is accepted or rejected. Modality is semantic content, so changing it should not be reduced to a style preference.
13. A new release changes terminology only in marketing
Define scope carefully. Product UI may retain the technical term while campaign pages use a friendlier label. A decision log should prevent the marketing choice from overwriting engineering terminology across the whole corpus.
14. A target-language corpus contradicts a legacy translation
Record the evidence, compare authority and decide whether to modernise or preserve the legacy form. If the change is made, document propagation and whether old content will be updated.
15. A translation must preserve an awkward official quotation
Document that the published official target version is authoritative even if the team would normally phrase it differently. This protects the quotation from repeated editorial polishing.
16. A term’s grammatical gender causes recurring problems
Record the approved noun and any agreement implications if they affect surrounding templates. The decision may belong partly in the termbase and partly in developer guidance when variables are involved.
17. A locale uses a different date style than the global guide
Record the locale override and its scope. If it is a general rule, promote it into the locale style supplement so the decision log does not carry routine formatting forever.
18. A translator chooses to preserve ambiguity
Document that the ambiguity is intentional in the source and functionally important. A later reviewer may otherwise ‘clarify’ the target and destroy a deliberate rhetorical or legal openness.
19. A search term must remain recognisable for SEO
Record the approved balance between natural target language and established search terminology if the choice materially affects repeated headings or metadata. Keep the scope limited to search-facing content rather than forcing keyword phrasing into all prose.
20. An old decision is no longer valid
Do not delete it. Mark it superseded, link the replacement and state the effective version. History helps future maintainers understand why older releases differ without treating obsolete wording as current guidance.
Operational checklist
- Only non-obvious, reusable or high-risk decisions are logged.
- Each entry has a stable identifier.
- Source context is precise enough to recreate the problem.
- Evidence is separated from the conclusion.
- Credible alternatives and rejection reasons are visible where useful.
- Rationale names the controlling constraint.
- Scope prevents over-generalisation.
- Status distinguishes proposals, confirmations, exceptions and superseded rules.
- Ownership and approval authority are explicit.
- Source version or release is recorded.
- Stable terminology and style rules are promoted into their proper systems.
- Propagation and retirement are tracked.
Frequently asked questions
Is a decision log the same as a glossary?
No. A glossary or termbase controls terms. A decision log preserves the reasoning behind non-obvious project choices, including ambiguity, exceptions, scope and approvals.
How many decisions should be logged?
Enough to preserve choices that are likely to recur, be challenged or carry material risk. Ordinary obvious translations do not need entries.
Where should the log live?
In a searchable shared system the translation team actually uses: a spreadsheet, database, project tool or localization platform can all work if stable IDs and status are preserved.
Should rejected alternatives be kept?
Keep credible alternatives when knowing why they were rejected will prevent future rework. Do not clutter entries with every theoretical synonym.
What happens when a decision changes?
Create a new or revised authoritative entry, mark the old one superseded and preserve the link so the history remains auditable.
Can AI maintain a decision log?
AI can help summarise discussions or suggest related entries, but evidence, scope and approval status must be verified. A confidently invented rationale would make the log dangerous.
How does a decision log reduce review time?
It converts recurring preference debates into documented decisions that can be referenced, searched and propagated consistently.
What is the minimum useful entry?
Decision ID, issue and context, evidence, chosen treatment, rationale, scope, status, owner or approver, and relevant version.
The larger lesson
Translation quality depends partly on memory, and human memory is a poor database. A decision log converts fragile recollection into durable project knowledge without forcing every choice into a glossary or style rule.
The deeper value is governance. A good log makes professional judgment inspectable: what was known, what alternatives existed, why one path was chosen, who approved it, where it applies and when it stopped applying. That traceability turns consistency from a personality trait into a property of the workflow.