How do you translate Totara Learn training without changing who is required to complete a program, when a certification expires or what a report proves? Begin with the learner’s obligations, not only the text. Totara language packs, multi-language content filters, learning activities and reporting rules serve different functions, so each must be checked on its own terms.
This international Totara Learn translation guide explains language packs, content-language filters, course pages, quiz instructions, programs, certifications, audience assignments, roles and reporting terminology. It is written for administrators, employers, educators, compliance trainers and localization professionals. The examples are fictional and should be validated against the specific Totara product, version, installed extensions and local policy before implementation.
Totara’s official documentation describes multilingual site capabilities and a multi-language content filter for supported authoring areas. Some content can be presented through language tags, while interface translations rely on language packs. These mechanisms do not themselves certify that a translated quiz, completion rule or legal training notice means the same thing. Reliable localization requires readable language, accurate conditions and a tested learner experience.
The answer in one minute
A reliable Totara Learn translation has three layers. The first is the explanation the learner reads: titles, instructions, examples, feedback and help. The second is the operating rule underneath: access, assessment, sequence, due date, completion, identity or payment where relevant. The third is the evidence that both layers still agree after publication: a repeatable learner journey, a bilingual meaning review and an administrator’s configuration check. If any layer disagrees, the translation is not ready even if the prose is fluent.
Start with the actual environment, not a hypothetical screenshot. Note the installed product version, enabled functions, theme or design context, integrated services and intended languages. Identify a content owner for pedagogy, a technical owner for configuration, a language reviewer for audience understanding and a release owner who can stop a harmful change. One person may perform several roles on a small site, but the responsibilities remain distinct. Keep source and target copies so that a correction can be made without losing the original evidence.
What Totara Learn localization actually covers
Totara Learn serves structured organisational learning, where courses may sit within broader programs, certification requirements and audience assignments. A site may include multiple languages, job roles, approval responsibilities and reports consumed by managers. Translating its words is therefore inseparable from understanding the decisions those words describe. Confirm the installed product generation and enabled features before assuming that a setting exists.
This chapter addresses the Totara organisational learning workflow rather than treating Totara as another generic Moodle export. Its scope is multilingual content filters, official language packs, assigned learning, certification interpretation and accountable reporting.
A useful inventory is not simply a list of paragraphs. Create one line for each visible element with these questions: who sees it, where does it appear, what action or decision follows from it, which underlying field or rule gives it meaning, what variables or codes must remain unchanged, who approves it, and how will it be tested? An introductory course title and a quiz pass threshold may both be strings on a page, yet their risk is completely different. They should not move through the same unreviewed text-replacement workflow.
First distinguish display text from controlled data
Most learning systems mix prose with data. Prose includes a course overview, explanation, instructions and educational feedback. Controlled data may include a record identifier, resource path, target URL, role, duration, grade boundary, locale code, price, completion state, integration key or date-time instant. The safe default is to translate only genuinely human-facing language and to treat everything else as protected until its owner confirms otherwise. Never assume that a field is safe to replace because it is stored in JSON, HTML, WordPress content or a configuration table.
The distinction becomes clear in a fictional course about workplace laboratory practice. Translating “put on eye protection before approaching the bench” requires preserving the sequence and obligation. Translating a course title requires preserving the program’s identity. Translating “minimum score: 80%” requires keeping the numerical threshold intact. Translating “you may attempt again after the review session” requires confirming that the platform actually permits a second attempt. In each case the problem is meaning, but the operational check is different.
Do not let language automation rewrite learner histories, grades, enrollment records or audit events. These are records of things that happened, not draft instructional paragraphs. If an old message was misleading, keep the historical evidence and publish an authorised correction. If a target-language lesson is unfinished, call it incomplete rather than hiding the discrepancy. These habits protect learners, administrators and translators from costly misunderstandings.
A practical source-to-target inventory
Before translating, build a small table with source item, target item, owner, location, locale, risk, protected fields, review status and release version. Mark each item as informational, instructional, assessed, contractual, privacy-sensitive or technically controlled. A course welcome sentence may only need language editing, whereas a sentence introducing a graded assessment needs teacher verification. A membership promise may need finance or legal review. The classification determines how much checking is proportionate, not whether the prose sounds sophisticated.
For each target language, keep a terminology sheet covering at least the words for course, lesson, unit, quiz, assessment, assignment, attempt, prerequisite, enrolment, completion, certificate, requirement, due date, pass, fail and retry. Add any platform-specific term whose translation could confuse a learner. Note where a term is intentionally different between learner-facing teaching text and administrator-facing configuration. Consistency does not mean forcing one translation onto every context; it means the same role or status is not silently given conflicting names.
Preserve reversible changes. Work on a staging course or duplicate where possible, use fabricated test accounts and set an explicit version boundary for what has been reviewed. Check the installed implementation before following a generic tutorial: product plans, plugins, features and APIs change. Record the procedure actually tested, including whether the validation used an anonymous visitor, a newly enrolled learner, an enrolled but incomplete learner, and a completed learner. That is better evidence than one editor screenshot.
Twenty-four situations where Totara Learn translations go wrong — and how to repair them
1. Site language selection
A realistic example. An employer enables French and English for a geographically distributed workforce. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The team confuses translating the interface with translating every existing training module. A translator should ask what real action the sentence asks a learner to take. Read the source and target alongside the actual setting, not as two isolated sentences. If the instruction refers to a condition or sequence, reproduce that condition and sequence in plain language. If uncertainty remains, obtain a decision from the course owner rather than inventing a platform behavior.
A safer method. Install and test appropriate language packs while inventorying all authored courses and message templates separately. For the final review, do not stop at spelling. Use a fictional learner to attempt the action from the exact page where the wording appears. Record the expected and observed outcome, the reviewer who checked the meaning and the version being tested. This is a practical way to catch a beautiful but misleading translation.
Proof of success. Learners in each locale see interface strings and course content whose language coverage is explicitly known. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
2. Multi-language filter
A realistic example. A course introduces safety controls using language-tagged paragraphs. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The filter is not enabled, so all language versions appear together or tags show as raw text. The essential distinction is between the instruction’s surface wording and the rule behind it. A concise target sentence is welcome only when it leaves the underlying relationship unchanged. Keep units, thresholds, names and eligibility facts under explicit control. Where several user roles see different states, review those states separately.
A safer method. Confirm the content filter and supported authoring areas for the installed version before adding multilingual tags. Test the smallest realistic end-to-end journey, including entering through a navigation link, encountering the text, making a choice and receiving feedback. Document whether the result agrees with the source. This catches problems that neither an isolated text export nor an administrator preview can reveal.
Proof of success. A learner changes preference and sees the correct single-language content without broken markup. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
3. String placeholder
A realistic example. An interface message inserts a course name and a numeric deadline. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The translator removes a programmatic placeholder or changes its order without checking formatting. Here the risk is not bad grammar but a different promise. Ask what a reasonable reader would believe after reading the translated sentence and compare that belief with the live implementation. Do not use a vague synonym for a precise status or rule. When the desired wording is unclear, publish the more precise approved wording rather than the more persuasive one.
A safer method. Preserve variables in language-pack strings and test their grammatical behavior using realistic values. A useful acceptance test has two witnesses: a bilingual reviewer who checks meaning and a platform reviewer who checks behavior. Each records a simple pass, fail or unresolved result. If a contradiction is found, correct the text or obtain authorization for a separately reviewed configuration change; never silently change historical learner evidence.
Proof of success. The message shows the actual course and deadline in both languages without blank fields. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
4. Course title and identity
A realistic example. An induction course has a human-readable title and a stable internal course identifier. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The localized title is accidentally used as a replacement machine identifier in an integration. Consider the learner’s point of view before editing. They cannot see database fields, plugin ownership or hidden configuration, so the translated explanation is their map of the system. Every button, label and warning should guide them toward an action that will actually work. Translation has failed if fluent language makes the real pathway harder to understand.
A safer method. Translate display names while preserving IDs and external system mappings unless a supported migration is explicitly planned. Review the outcome across at least the likely target devices and roles, including accessibility controls where appropriate. Compare target text with live state and with the source version’s learning objective. Preserve a clear record of any deliberate adaptation, so later updates do not accidentally reverse a good editorial decision.
Proof of success. Assignments and imported learner records still refer to the same course. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
5. Audience assignment
A realistic example. A training requirement applies only to workers operating a certain machine. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The translation generalizes the audience to all employees, changing the perceived obligation. A translator should ask what real action the sentence asks a learner to take. Read the source and target alongside the actual setting, not as two isolated sentences. If the instruction refers to a condition or sequence, reproduce that condition and sequence in plain language. If uncertainty remains, obtain a decision from the course owner rather than inventing a platform behavior.
A safer method. Cross-check role descriptions, eligibility and audience membership with the policy owner. For the final review, do not stop at spelling. Use a fictional learner to attempt the action from the exact page where the wording appears. Record the expected and observed outcome, the reviewer who checked the meaning and the version being tested. This is a practical way to catch a beautiful but misleading translation.
Proof of success. Members and nonmembers of the intended audience see accurate requirements. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
6. Program sequence
A realistic example. A program contains three courses that must be completed in a controlled order. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. One target-language description says the final assessment can be attempted first. The essential distinction is between the instruction’s surface wording and the rule behind it. A concise target sentence is welcome only when it leaves the underlying relationship unchanged. Keep units, thresholds, names and eligibility facts under explicit control. Where several user roles see different states, review those states separately.
A safer method. Keep step order, requirement language and exceptions consistent with the program configuration. Test the smallest realistic end-to-end journey, including entering through a navigation link, encountering the text, making a choice and receiving feedback. Document whether the result agrees with the source. This catches problems that neither an isolated text export nor an administrator preview can reveal.
Proof of success. A test learner sees the same mandatory journey in each locale. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
7. Certification validity
A realistic example. A certification expires after a defined validity interval. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The translated certificate text suggests a permanent qualification. Here the risk is not bad grammar but a different promise. Ask what a reasonable reader would believe after reading the translated sentence and compare that belief with the live implementation. Do not use a vague synonym for a precise status or rule. When the desired wording is unclear, publish the more precise approved wording rather than the more persuasive one.
A safer method. Separate certificate award, recertification date, expiration and employer-specific recognition. A useful acceptance test has two witnesses: a bilingual reviewer who checks meaning and a platform reviewer who checks behavior. Each records a simple pass, fail or unresolved result. If a contradiction is found, correct the text or obtain authorization for a separately reviewed configuration change; never silently change historical learner evidence.
Proof of success. A sample certificate and learner dashboard show the actual validity conditions. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
8. Recurring certification
A realistic example. A worker must complete refresher learning during each renewal cycle. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The target text converts a recurring condition into a one-time requirement. Consider the learner’s point of view before editing. They cannot see database fields, plugin ownership or hidden configuration, so the translated explanation is their map of the system. Every button, label and warning should guide them toward an action that will actually work. Translation has failed if fluent language makes the real pathway harder to understand.
A safer method. Translate the renewal window and triggering events as conditions rather than approximate calendar phrases. Review the outcome across at least the likely target devices and roles, including accessibility controls where appropriate. Compare target text with live state and with the source version’s learning objective. Preserve a clear record of any deliberate adaptation, so later updates do not accidentally reverse a good editorial decision.
Proof of success. Learners in different cycles see consistent instructions and reminders. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
9. Quiz stem
A realistic example. A health-and-safety item asks which action is required before entering a controlled zone. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The translation weakens must to should, making an obligation seem optional. A translator should ask what real action the sentence asks a learner to take. Read the source and target alongside the actual setting, not as two isolated sentences. If the instruction refers to a condition or sequence, reproduce that condition and sequence in plain language. If uncertainty remains, obtain a decision from the course owner rather than inventing a platform behavior.
A safer method. Review the exact action, negation, exceptions and answer logic with an authorised subject expert. For the final review, do not stop at spelling. Use a fictional learner to attempt the action from the exact page where the wording appears. Record the expected and observed outcome, the reviewer who checked the meaning and the version being tested. This is a practical way to catch a beautiful but misleading translation.
Proof of success. Independent reviewers identify the same correct response and justification. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
10. Numeric quiz
A realistic example. A practical task requires a threshold reading with specified units. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. Local decimal punctuation is updated but the units or rounding rules change. The essential distinction is between the instruction’s surface wording and the rule behind it. A concise target sentence is welcome only when it leaves the underlying relationship unchanged. Keep units, thresholds, names and eligibility facts under explicit control. Where several user roles see different states, review those states separately.
A safer method. Keep quantities, comparisons and accepted-answer configuration synchronized with the language. Test the smallest realistic end-to-end journey, including entering through a navigation link, encountering the text, making a choice and receiving feedback. Document whether the result agrees with the source. This catches problems that neither an isolated text export nor an administrator preview can reveal.
Proof of success. Boundary-value test answers receive the same pass or fail result. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
11. Seminar notifications
A realistic example. A training seminar has a date, location and attendance rule. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The localized notification changes the time zone or says attendance is optional. Here the risk is not bad grammar but a different promise. Ask what a reasonable reader would believe after reading the translated sentence and compare that belief with the live implementation. Do not use a vague synonym for a precise status or rule. When the desired wording is unclear, publish the more precise approved wording rather than the more persuasive one.
A safer method. Protect event fields, render the learner’s time zone explicitly where needed and match participation wording to the actual rule. A useful acceptance test has two witnesses: a bilingual reviewer who checks meaning and a platform reviewer who checks behavior. Each records a simple pass, fail or unresolved result. If a contradiction is found, correct the text or obtain authorization for a separately reviewed configuration change; never silently change historical learner evidence.
Proof of success. A test invitation, reminder and cancellation display coherent dates and obligations. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
12. Approval workflow
A realistic example. A manager approval is required before a course place becomes confirmed. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The target confirmation email implies registration is final immediately on request. Consider the learner’s point of view before editing. They cannot see database fields, plugin ownership or hidden configuration, so the translated explanation is their map of the system. Every button, label and warning should guide them toward an action that will actually work. Translation has failed if fluent language makes the real pathway harder to understand.
A safer method. Distinguish requested, approved, waitlisted, canceled and attended states as separate terms. Review the outcome across at least the likely target devices and roles, including accessibility controls where appropriate. Compare target text with live state and with the source version’s learning objective. Preserve a clear record of any deliberate adaptation, so later updates do not accidentally reverse a good editorial decision.
Proof of success. A test request follows every state and displays truthful instructions. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
13. Competency wording
A realistic example. A role framework distinguishes awareness, working proficiency and independent competence. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The translated competency labels become synonyms, obscuring the required level. A translator should ask what real action the sentence asks a learner to take. Read the source and target alongside the actual setting, not as two isolated sentences. If the instruction refers to a condition or sequence, reproduce that condition and sequence in plain language. If uncertainty remains, obtain a decision from the course owner rather than inventing a platform behavior.
A safer method. Create a reviewed controlled vocabulary and anchor each translated level to observable evidence. For the final review, do not stop at spelling. Use a fictional learner to attempt the action from the exact page where the wording appears. Record the expected and observed outcome, the reviewer who checked the meaning and the version being tested. This is a practical way to catch a beautiful but misleading translation.
Proof of success. Assessors can explain the same performance difference across languages. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
14. Performance review form
A realistic example. A performance form asks for observed evidence, not a self-rating alone. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The target question invites an unsupported opinion instead of evidence. The essential distinction is between the instruction’s surface wording and the rule behind it. A concise target sentence is welcome only when it leaves the underlying relationship unchanged. Keep units, thresholds, names and eligibility facts under explicit control. Where several user roles see different states, review those states separately.
A safer method. Keep the question’s purpose, audience, confidentiality and data fields intact. Test the smallest realistic end-to-end journey, including entering through a navigation link, encountering the text, making a choice and receiving feedback. Document whether the result agrees with the source. This catches problems that neither an isolated text export nor an administrator preview can reveal.
Proof of success. Managers and workers interpret the prompt consistently in a safe sample review. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
15. Role and permission names
A realistic example. An administrative menu contains labels for roles with different data privileges. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The translated title makes a viewer sound like an administrator, inviting inappropriate requests. Here the risk is not bad grammar but a different promise. Ask what a reasonable reader would believe after reading the translated sentence and compare that belief with the live implementation. Do not use a vague synonym for a precise status or rule. When the desired wording is unclear, publish the more precise approved wording rather than the more persuasive one.
A safer method. Translate what each role may actually do, and never change capabilities merely to match wording. A useful acceptance test has two witnesses: a bilingual reviewer who checks meaning and a platform reviewer who checks behavior. Each records a simple pass, fail or unresolved result. If a contradiction is found, correct the text or obtain authorization for a separately reviewed configuration change; never silently change historical learner evidence.
Proof of success. Test accounts confirm accurate visible labels and unchanged permissions. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
16. Report column labels
A realistic example. A completion report distinguishes started, completed, overdue and exempt. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The target report collapses these into a single done/not done vocabulary. Consider the learner’s point of view before editing. They cannot see database fields, plugin ownership or hidden configuration, so the translated explanation is their map of the system. Every button, label and warning should guide them toward an action that will actually work. Translation has failed if fluent language makes the real pathway harder to understand.
A safer method. Define status terms with operational meanings and preserve filters, denominators and timestamps. Review the outcome across at least the likely target devices and roles, including accessibility controls where appropriate. Compare target text with live state and with the source version’s learning objective. Preserve a clear record of any deliberate adaptation, so later updates do not accidentally reverse a good editorial decision.
Proof of success. A manager can reconcile a translated report with the underlying canonical status data. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
17. Dashboard metrics
A realistic example. A chart displays percent completed across assigned learners. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. A translator mislabels the denominator as all employees, inflating or deflating the interpretation. A translator should ask what real action the sentence asks a learner to take. Read the source and target alongside the actual setting, not as two isolated sentences. If the instruction refers to a condition or sequence, reproduce that condition and sequence in plain language. If uncertainty remains, obtain a decision from the course owner rather than inventing a platform behavior.
A safer method. Keep population scope and reporting period in the explanatory text. For the final review, do not stop at spelling. Use a fictional learner to attempt the action from the exact page where the wording appears. Record the expected and observed outcome, the reviewer who checked the meaning and the version being tested. This is a practical way to catch a beautiful but misleading translation.
Proof of success. A reviewer reproduces the proportion using synthetic data and the same filter. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
18. Badges and credentials
A realistic example. A digital badge is awarded for finishing a specific skills path. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The target badge title implies a professional license the course does not grant. The essential distinction is between the instruction’s surface wording and the rule behind it. A concise target sentence is welcome only when it leaves the underlying relationship unchanged. Keep units, thresholds, names and eligibility facts under explicit control. Where several user roles see different states, review those states separately.
A safer method. Match achievement wording to evidence and local regulation; avoid inventing external accreditation. Test the smallest realistic end-to-end journey, including entering through a navigation link, encountering the text, making a choice and receiving feedback. Document whether the result agrees with the source. This catches problems that neither an isolated text export nor an administrator preview can reveal.
Proof of success. The translated badge describes precisely the learning accomplishment recorded. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
19. Course accessibility
A realistic example. An instructional diagram explains a process sequence through arrows and colors. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. Visible captions are translated, but meaningful alternatives and keyboard focus remain English or ambiguous. Here the risk is not bad grammar but a different promise. Ask what a reasonable reader would believe after reading the translated sentence and compare that belief with the live implementation. Do not use a vague synonym for a precise status or rule. When the desired wording is unclear, publish the more precise approved wording rather than the more persuasive one.
A safer method. Review alternative text, link names, reading order and non-color cues in the actual learner interface. A useful acceptance test has two witnesses: a bilingual reviewer who checks meaning and a platform reviewer who checks behavior. Each records a simple pass, fail or unresolved result. If a contradiction is found, correct the text or obtain authorization for a separately reviewed configuration change; never silently change historical learner evidence.
Proof of success. A screen-reader learner can follow the process and operate required activities. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
20. Right-to-left content
A realistic example. An Arabic user works through a page with tables of figures and action controls. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. A locale switch changes direction but reverses columns whose order carries meaning. Consider the learner’s point of view before editing. They cannot see database fields, plugin ownership or hidden configuration, so the translated explanation is their map of the system. Every button, label and warning should guide them toward an action that will actually work. Translation has failed if fluent language makes the real pathway harder to understand.
A safer method. Test right-to-left layout alongside invariant numeric values and the intended workflow order. Review the outcome across at least the likely target devices and roles, including accessibility controls where appropriate. Compare target text with live state and with the source version’s learning objective. Preserve a clear record of any deliberate adaptation, so later updates do not accidentally reverse a good editorial decision.
Proof of success. A real device renders clear hierarchy and safe navigation. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
21. External learning record
A realistic example. Totara shares completion status with an HR or identity system. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. A target-language status label is written back in place of the integration’s controlled status value. A translator should ask what real action the sentence asks a learner to take. Read the source and target alongside the actual setting, not as two isolated sentences. If the instruction refers to a condition or sequence, reproduce that condition and sequence in plain language. If uncertainty remains, obtain a decision from the course owner rather than inventing a platform behavior.
A safer method. Keep canonical codes stable and localize only presentation layers or documented text fields. For the final review, do not stop at spelling. Use a fictional learner to attempt the action from the exact page where the wording appears. Record the expected and observed outcome, the reviewer who checked the meaning and the version being tested. This is a practical way to catch a beautiful but misleading translation.
Proof of success. Read-back confirms the integration still exchanges expected identifiers and states. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
22. Incomplete language pack
A realistic example. An installed language pack leaves several plugin and extension strings untranslated. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The launch team interprets that as proof the language switch is malfunctioning everywhere. The essential distinction is between the instruction’s surface wording and the rule behind it. A concise target sentence is welcome only when it leaves the underlying relationship unchanged. Keep units, thresholds, names and eligibility facts under explicit control. Where several user roles see different states, review those states separately.
A safer method. Check coverage for the exact version, distinguish missing translations from broken filters, and review extensions. Test the smallest realistic end-to-end journey, including entering through a navigation link, encountering the text, making a choice and receiving feedback. Document whether the result agrees with the source. This catches problems that neither an isolated text export nor an administrator preview can reveal.
Proof of success. A documented inventory identifies all outstanding visible strings before release. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
23. Course policy updates
A realistic example. The organisation changes a safety procedure after the translated course is approved. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. The old target version remains accessible with contradictory instructions. Here the risk is not bad grammar but a different promise. Ask what a reasonable reader would believe after reading the translated sentence and compare that belief with the live implementation. Do not use a vague synonym for a precise status or rule. When the desired wording is unclear, publish the more precise approved wording rather than the more persuasive one.
A safer method. Assign an owner to monitor source-policy changes and update localized statements after revalidation. A useful acceptance test has two witnesses: a bilingual reviewer who checks meaning and a platform reviewer who checks behavior. Each records a simple pass, fail or unresolved result. If a contradiction is found, correct the text or obtain authorization for a separately reviewed configuration change; never silently change historical learner evidence.
Proof of success. A release record links each target edition to the correct approved policy version. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
24. Audit trail integrity
A realistic example. A learner challenges whether a translated assessment changed the pass requirement. This is the sort of instruction or screen a learner might encounter in a normal training journey. It is easy to overlook when a project concentrates only on the most visible reading passages, yet it can determine what someone attempts, submits, believes or asks a tutor to clarify.
What can go wrong. A staff member edits historic result labels without preserving the original decision. Consider the learner’s point of view before editing. They cannot see database fields, plugin ownership or hidden configuration, so the translated explanation is their map of the system. Every button, label and warning should guide them toward an action that will actually work. Translation has failed if fluent language makes the real pathway harder to understand.
A safer method. Keep immutable historical event data, preserve approved source and target versions, and document correction notices. Review the outcome across at least the likely target devices and roles, including accessibility controls where appropriate. Compare target text with live state and with the source version’s learning objective. Preserve a clear record of any deliberate adaptation, so later updates do not accidentally reverse a good editorial decision.
Proof of success. A reviewer can reconstruct what language and rules the learner actually encountered. Keep the evidence proportionate to the stakes: a simple navigation label may need a screenshot and quick learner check, whereas assessment, privacy, access or commercial language needs a documented owner and relevant test state.
A worked project: a bilingual Totara Learn course
Imagine a fictional organisation offering a six-week introductory course in workplace problem-solving. The English version includes a catalogue description, two introductory activities, a required practice exercise, a short assessment, feedback for different outcomes, a completion record and a message explaining what to do next. The organisation now needs a second-language version. It would be tempting to translate a Word document containing the teaching text, paste it into the editor and announce completion. That process misses the parts of a course that learners experience as decisions.
The course owner begins with an inventory and a learning-outcome statement: successful learners must be able to identify a problem, compare two options using evidence and explain a decision. The language reviewer translates the teaching prose while an assessment specialist reviews every instruction, distractor and feedback sentence. A technical administrator verifies access rules, required activities, completion behavior and identifiers. The group tests the course with fictional accounts representing a new visitor, an enrolled learner who has made a mistake and a learner who has completed the required work.
During testing, the team notices that the target version’s friendly instruction “finish whenever convenient” contradicts a timed assessment rule. The target course also includes a reminder whose template still uses the source language, and one visual comparison has an alt description that omits the key contrast. These are not cosmetic defects: they can change learner expectations or exclude someone using assistive technology. The team repairs the wording, checks the actual settings, replays the test journeys and approves a clearly identified course edition.
At handover, the team keeps the original source intact, records the target locale and approval date, names the owners of future updates and notes which linked resources are shared. If a later instructional change affects an assessed topic, the target owner will review the associated explanations and feedback rather than translating one new paragraph in isolation. This small discipline is what makes multilingual education maintainable after the launch.
A four-week implementation plan
Week 1 — discover and classify
Audit visible text, lesson structure, assessment conditions, access or completion rules, notifications, files, links, locales and extensions. Identify the installed product version. Decide which content is truly translatable and which values or histories must be preserved. Create realistic fictional accounts and a source-to-target item map.
Week 2 — translate meaning with owners
Prepare terminology for important learner statuses and technical concepts. Translate instructional text and accessible alternatives, then obtain bilingual and domain review for high-consequence language. Protect identifiers and variables. Keep notes on meaning-sensitive differences rather than allowing an automated rewrite to make hidden decisions.
Week 3 — test real learner journeys
Use a safe staging environment or isolated course edition. Walk through catalogue entry, enrollment, lesson navigation, assessment and feedback, completion and notifications. Test at least one negative path such as denied access or failed assessment. Inspect mobile views, keyboard navigation and screen-reader labels where relevant.
Week 4 — release with evidence
Resolve every material discrepancy; record approvals and source version. Compare the published edition against the validated copy. Check search snippets and related links. Explain how corrections will be communicated without editing historical learner events, and nominate someone to monitor source-content or platform updates.
Questions a careful reader should ask
Can I simply translate all text fields in a database?
No. A text-shaped field may contain an ID, code, machine-readable value, placeholder or structured expression. Only edit documented human-facing fields after you know the record’s ownership and dependencies. An exported text file is not proof that every string is ordinary prose.
Does changing the interface language also translate the actual course?
Not necessarily. Interface language packs and authored educational content may be controlled separately. Review course pages, files, assessments, feedback, emails and accessible descriptions rather than assuming one locale switch covers all of them.
How should artificial intelligence be used?
It can help propose first-pass wording and identify repetitive terminology, but it cannot guarantee identical assessment difficulty, legal meaning or access conditions. Keep human editorial accountability, use synthetic records for experiments and review consequential content before release.
What should never be silently changed?
Historical submissions, grades, awarded credentials, enrollment evidence, learner identity, access privileges, exact deadlines and protected integration identifiers should not be rewritten to make a translation look cleaner. Correct published wording through authorized procedures and retain a traceable record.
What is the minimum acceptance test?
At least one source-to-target meaning comparison plus a complete target-language learner journey through the relevant functions. For a low-risk paragraph, that may be simple. For a scored quiz, paid access, safety instruction or certification, test edge states and obtain specialized review.
How can a small team maintain multiple languages?
Keep a source version, a terminology sheet, a list of target editions, the name of the accountable course owner and a release checklist. Review the changed source sections and dependent messages whenever the course or installed software is updated.
Should search descriptions differ by language?
They may use natural search intent in each language, but they must accurately represent the actual edition. Avoid claiming that a course has translated files, an accredited certificate or unrestricted access until those claims are verified.
When is publication too early?
When a substantive requirement is unclear, a critical file is missing, the only test used an administrator account, a quiz’s answer logic is unverified, or the translated learner would be led toward an action that does not work. Mark the edition incomplete and finish the relevant check.
Official guidance, source verification and further reading
The following references help readers verify platform capabilities against current versions. Product interfaces and plan features can change; use official manuals as a starting point and confirm behavior in the environment actually being localized. Totara: using multiple languages; Totara: install a language pack; Totara developer internationalisation guidance; Totara language packs. These references describe the software; the examples and explanations above are educational illustrations, not vendor certification.
For adjacent concepts that should remain separate from Totara Learn-specific editing, consult Platform assessment item semantics and scoring; Learner event statements and language maps; Common Cartridge and LMS course-package handover; Translate Like a Pro series index. When a task crosses into another system, read that system’s own guide rather than assuming the same package fields or learner states apply.
The central test is straightforward: can a person who does not speak the original language enter the correct course, understand what is required, complete the intended learning actions, receive accurate feedback and know what their record means? If yes, with the relevant owners and technical checks agreeing, the language is serving the learner rather than merely decorating the interface.