Localization and Multilingual Content
Translation Change Log
Record source changes, affected locales, semantic risk, translation owners, review status, dependencies, release completion, and deferred work.
Free editable Markdown · Localization managers, content operations teams, and release managers ·
Accessible HTML preview
Blank template
The downloaded file contains the same fields in editable Markdown.
Source change
- Change ID
- [Stable identifier]
- Source locale and version
- [Locale; commit/release]
- Component or page
- [Location]
- Before
- [Exact source text]
- After
- [Exact source text]
- Reason
- [Correction, feature, policy, style, terminology]
- Semantic risk
- [Low, medium, high, critical with reason]
- Related strings/assets
- [IDs and surfaces]
- Release target
- [Date or version]
Locale status
- Target locale
- [Locale code]
- Translation owner
- [Person or vendor]
- Status
- [Not started, translating, review, QA, released, deferred]
- Terminology impact
- [Terms or memory changes]
- Placeholder/plural risk
- [Details]
- Linguistic reviewer
- [Owner and decision]
- Functional/visual QA
- [Owner and result]
- Subject/compliance review
- [If required]
- Live verification
- [URL/build and date]
Release checks
- Active locales and non-page assets are inventoried.
- Semantic risk determines review depth.
- Placeholders, plurals, variables, and formatting remain functional.
- Mixed-language or stale fallback is handled safely.
- Deferred locales have explicit status and owner.
- Live content is checked after deployment.
- Metadata, schema, sitemaps, and downloads match locale status.
- Terminology and source guidance capture lessons.
How to use this template
- Capture the source change, version, reason, before/after text, dependencies, and semantic risk.
- Enumerate active locales and every content or media surface that inherits the meaning.
- Assign translation, linguistic, functional, subject, and release owners with deadlines.
- Define safe staging or blocking behavior for incomplete locales.
- Verify live releases, record deferred work, and update terminology or workflow lessons.
Classify the source change
Record the exact before and after text plus component, page, source locale, version, author, and reason. Classify whether the change corrects a fact, changes meaning, adds a feature, alters legal or policy wording, adjusts style, or updates a token. Mark semantic risk: a punctuation change may be low risk, while “can” to “cannot” is critical. Identify related strings that share the same concept even if they were not edited in the source file.
Determine affected locales and assets
List every active locale, publication status, owner, translation memory impact, and whether an equivalent change already exists. Include screenshots, captions, audio, PDFs, emails, help content, metadata, structured data, and downloadable files. Check placeholders, gender, plurals, word order, and layout. Do not use an English fallback at a localized URL when it creates a mixed or misleading experience. Define whether release must wait for all locales or can be staged safely.
Close the loop after release
Require linguistic review, functional QA, subject review, and compliance review according to risk. Record build, deployment, cache, and index updates where relevant. Verify the live locale rather than marking completion when a translation is delivered. Document deferred locales with a user-safe treatment and owner. Link corrections back to terminology and source guidance so the same issue does not recur in the next release.
See the fields in context
Fictional example: export confirmation change
Archive Kite is an invented product, and the release process below is illustrative.
- Before: “Your export is ready.” After: “Your export request was received; we will email you when the file is ready.”
- Risk: High, because the source change corrects fictional product status and expected timing.
- Affected assets: Confirmation screen, status email, help page, and two screenshots across three invented locales.
- Staging: A locale remains on the prior product version rather than displaying the inaccurate source fallback.
- Completion: Each live flow is tested with sample data, and the timing term is added to the shared glossary.
Frequently asked questions
Does every source edit require retranslation?
No. Classify whether meaning or approved style changes. Still record a reviewed no-change decision for potentially ambiguous edits.
Can machine translation close an urgent change?
It may assist an approved workflow, but consequential content needs appropriate human review, context, privacy controls, and live QA.
What should happen when one locale is late?
Use a documented safe fallback, staged release, or temporary unavailability based on risk. Do not silently show misleading or mixed-language content.
When is a translation change complete?
When the intended live surfaces are verified, not merely when a file is delivered or merged.