Learning Content Localisation: Decision Log

1. Open one localisation decision log

Name the approved source before changing a word or format. The log should let a later reviewer see why a local version differs and who can correct it.

• Source asset, version, owner and permitted use.
• Receiving role, location or operating context, work moment and intended channel.
• Declared language or languages, relevant terminology and any access condition to test.
• Local reviewer, source owner and release decision maker.
• Date, planned test and event that will trigger another review.

2. Separate fixed practice from local adaptation

For each important instruction, record whether it is fixed by the source, needs local wording or workflow detail, or must be removed until a responsible owner decides. Do not treat a translated sentence as permission to copy a process into another setting.

• Fixed: the approved task, safety boundary, decision owner or source reference that must remain intact.
• Local: role names, system labels, work sequence, examples, language, format or access route that the receiving team must check.
• Unresolved: a rule that conflicts with local practice, lacks an authorised source or needs a policy owner.
• Reason and evidence: the approved record or local condition supporting the change.

3. Test the version at the work moment

Ask a representative user to find and apply the asset to a suitable practice case. Observe where the instruction is unclear, inaccessible or not usable in the available time. The user test checks the asset; it does not measure an employee's capability or prove that the asset improves an outcome.

• Can the user identify the relevant action and its boundary?
• Do the terms, screen references and example match the local work setting?
• Can the asset be accessed in the agreed format, language and work conditions?
• What requires correction, a local owner decision or a different support format?

4. Release, label and revisit

Record the released version, audience, channel, approving owner and the source it depends on in the existing learning or document system. Mark a limited local adaptation as limited. If the source process, receiving workflow, language needs or access conditions change, reopen the log rather than assuming the old version still applies.

Why this guide is useful

Use this original decision log after a practice and production brief have already been approved. It is for adapting a finished draft to another work setting. The production brief determines the source, audience and agreed deliverable; the frontline learning test examines whether a short aid works during a shift. This page records the changes needed between those two moments.

Keep the source and the local decision together

For web-based material, W3C guidance explains why declaring the page language helps browsers and assistive technologies interpret its text. GOV.UK's interface-writing guidance also starts with the words people need to understand and act. Apply those principles to the asset at hand: identify the language, work vocabulary and access conditions to test. They do not certify that a local version is understood, accessible in every context or compliant with every local requirement.

Concrete example

Fictional example: a UK customer-support team has approved a one-page handover guide. A US team wants to use it for a different queue. The decision log keeps the source rule about recording an owner and next action, but changes the screen names and escalation contact to match the receiving team’s approved process. A local adviser tests the guide with a fictional case using the team’s usual device. When the guide suggests an escalation that the local process owner has not approved, the team marks that step unresolved rather than publishing it. The process owner and a representative user approve the revised version for that queue only.

Sources

• W3C: Understanding Success Criterion 3.1.1, Language of Page
• GOV.UK Service Manual: Writing for user interfaces