If you are searching for Moodle language customisation, how to translate Moodle interface strings, or how to change the wording in a Moodle language pack, the practical challenge is rarely finding another synonym. It is changing the correct string, for the correct audience, in the correct layer of Moodle, without having the change vanish during an update. The fastest reliable method begins by finding the component and string identifier behind the text on screen, then deciding whether your site needs a local wording change or a contribution to the official language pack.
Moodle language pack translation involves a surprisingly useful distinction. The words a learner sees may come from the Moodle core interface, an activity plugin, a theme, an installed language pack, or a site-specific override. Two buttons can display the same English word and still be driven by different strings. Two users can see different language choices while using the same course. Searching for the visible phrase is a beginning, not proof that you have located the right source.
This guide focuses on one reader job: make a controlled, testable change to the language of a Moodle site’s interface using the supported language customisation workflow. It explains how the official pack, local overrides, component keys, variables and cache interact; follows a complete school-site example; shows what commonly breaks; and gives a regression plan. It is not a tutorial on translating teaching materials or a general argument for multilingual education. The goal is a Moodle translation change that survives real use.
Quick answer: identify the owner, then customise the smallest surface
A Moodle administrator should first reproduce the wording in a test or staging course and record the user role, page, active language and the complete sentence. Next, open Site administration → Language → Language customisation, choose the relevant language, open its pack, and search for the string through its component and identifier or a carefully chosen substring. Enter the replacement in the local customisation field, save, and inspect the actual page as users of that language. Repeat with any other pages or notifications that use the same string. Keep a record so later site upgrades can be reviewed against the decision.
That path is different from contributing translations to Moodle’s central AMOS system. An AMOS contribution is for broader language-pack maintenance and is reviewed through the community workflow. A local override is for wording your institution deliberately wants on its own site. Treating them as interchangeable leads to wasted effort: a site-only label might be rejected as a universal translation, while a genuine mistranslation in the shared pack should not be quietly fixed only on one campus forever.
Before changing anything, make a tiny acceptance statement: “When a learner using French opens the course page, the action currently labelled X will read Y; the destination and permissions stay unchanged.” You can test that statement. “Improve translation” is too broad to test. This method feels slower for the first thirty seconds and saves time on the next fifteen screens.
Why Moodle interface translation is a lookup problem before it is a writing problem
A conventional document offers a paragraph, a page number and neighbouring sentences. A Moodle interface often offers the opposite: a short fragment such as “Continue”, “Attempt”, “Submit”, or “Grade”, stripped of the context that gives it meaning. The text may be a navigation command, an assessment action, a status, or a heading. The application selects an entry from its string system and displays its current translation. The translator must find that entry rather than editing what happens to look like the current page.
The useful mental model is a three-part address: component, string identifier, and language. A component points toward the part of Moodle that owns the wording, such as Moodle core or a specific activity module. The identifier names the particular message. The language chooses the target value. The visible English text is not always unique; several entries may share it. If you change the wrong one, an unrelated label changes while the original screen remains untouched.
A fourth ingredient is precedence. Moodle’s installed language pack supplies a shared value. A site’s local customisation can override that value for a particular language. If there is no suitable translation, Moodle may fall back according to its language mechanisms, often displaying English. A fifth ingredient is caching: strings are held for performance, so editing data at the wrong layer or by hand can leave a stale value visible. When you use Moodle’s language customisation interface, it handles cache updating as part of the supported workflow; raw file edits do not offer the same safety.
This is why rapid Moodle translation is not “search and replace every occurrence of Course”. It is “locate one identity, change it deliberately, and verify every context that identity reaches”. Once the team understands that distinction, a large proportion of mysterious translation bugs become ordinary, diagnosable address mistakes.
Three different jobs that are often called “translate Moodle”
The first job is to install or update an official language pack so users can use the site in a supported language. The administrator manages languages in Site administration and can check the pack appropriate to the Moodle version. This is primarily a deployment and configuration task; it does not require rewriting thousands of strings. The second job is to customise a few labels for local institutional vocabulary: perhaps a college uses “Learning unit” where a generic interface uses “Course”. Moodle has a supported language customisation feature precisely because a local institution can legitimately need different terminology.
The third job is to contribute a missing or improved translation to the shared Moodle community. AMOS, Moodle’s translation toolkit, holds string history and supports staging, review and language-pack generation. A contributor can submit a stage for a language maintainer; a maintainer with appropriate permissions can commit approved changes. The community route is useful when the change should help other Moodle sites using that language, not merely reflect a school’s internal branding.
Do not confuse any of these jobs with translating a teacher’s lesson, a PDF uploaded to a course, a quiz question authored by a lecturer, or a student’s submission. Those are course-content jobs with their own ownership and quality checks. This article owns the interface-label problem. If an administrator says, “Our French language pack is installed but our biology lecture notes are still in English,” the language-pack editor is not the missing solution. The distinction prevents a whole afternoon of editing the wrong system.
Establish a safe baseline before opening the editor
Record the Moodle version, active theme, relevant plugin version, installed language packs, and whether the symptom appears in the browser interface, an email, a mobile app, or an external integration. The version record matters because components and identifiers can change across releases. Do not assume a screenshot from an old manual names the same setting on every supported release. Use a staging environment or a narrow controlled window for changes to operational assessment wording, especially labels that students use to submit graded work.
Capture the source screen in a way a reviewer can recognise. A compact record has the route or activity name, the user role, the currently selected language, the current visible text and the intended replacement. If a phrase appears only after submitting a quiz, state whether you can safely reproduce it in a test attempt. If it appears in a notification, capture a sample message with sensitive data removed rather than relying on memory. Obtain approval from the staff member responsible for that process when it affects assessment or policy.
Export or back up the current customisation if available in your supported workflow, and record the current value before saving a new one. A rollback plan need not be complex: you should know which component and string identifier to revert, what value to restore, and how to verify the return. Never use a learner’s production attempt as a translation experiment. Build a disposable course that reproduces the state, and test with accounts whose permissions mimic learner and teacher roles without exposing real student information.
Finding the exact string: follow the component, not only the word
Open the language customisation feature and choose the language you intend to change. Moodle loads the language-pack files into an editing interface; this may take time on a large installation. Filter strings by component when you know it, and use a distinctive source phrase when you do not. The interface lets you inspect the standard wording and enter a local customisation. Its filters and status colours help distinguish unsaved modifications from saved custom entries. Exact labels vary by release, so work from your version’s interface rather than an old screenshot.
Suppose a learner sees the button “Submit all and finish” during a quiz. Search a distinctive part of that phrase and inspect results, instead of entering “Submit”. A generic word might occur in file uploads, assignments, forums and administration dialogs. Find the result whose component and context match the quiz attempt. Look at associated help text and neighbouring strings where available. If multiple results remain plausible, change nothing yet; reproduce the page and use documentation or string-identification techniques appropriate to your Moodle installation to narrow the owner.
A simple confirmation rule is valuable: name the feature, identify the exact string, and predict the scope of the proposed change. If you cannot say what else might use the identifier, include those possible screens in testing. Translators are often trained to seek one perfect word. Administrators need a slightly different discipline: protect the relationship between language value and feature identity. Translation quality begins after that relationship is known.
Worked case: “Course” versus a local institution’s “Learning unit”
Imagine a Singapore training organisation that calls its programme containers “Learning units” in student handbooks. Its Moodle interface currently displays “Course”. A manager asks for a quick translation because students find the two vocabularies confusing. The most tempting action is a broad replace of every occurrence of “Course”. That would be risky. The same word may appear in navigation, catalogue descriptions, settings, enrolment emails, documentation links and plugin-owned UI, some of which refer to slightly different things.
The administrator instead defines the job: replace the specific learner-facing navigation label that introduces a course home page, not every system concept containing the word course. The team records its current page, role and identifier, then experiments in a staging language customisation. After saving, the team signs in as a learner and checks the dashboard, course home page, breadcrumb and enrolment confirmation. They inspect teacher-facing screens too, because a short label can be shared across roles. If the override reaches places where “Learning unit” is misleading, the team revises the decision or chooses a narrower display-layer solution rather than forcing the global string.
The translation reviewer checks the wording as an interface instruction: does it name the same object students are entering? The Moodle administrator checks that the link still goes to the same course, that access rules are unchanged, and that the change survives a normal page refresh. The policy owner approves consistency with school materials. Only then is the edit moved into the live site. This case teaches an important lesson: the smallest visible edit can have a large semantic footprint if the string is reused.
Worked case: a bilingual assessment button with real consequences
Consider a course where the label on a final assessment button is being translated into another language. The English source says “Submit all and finish”, signalling finality. A proposed target suggests merely “Continue”. That translation feels friendly, but it changes the student’s expectation. A learner might commit an attempt believing there is another screen where answers can be checked. No software crash is needed for this to become a serious defect. The button still works; the wording misrepresents what it does.
Before editing, the reviewer writes down the action semantics: this button closes or finalises the relevant attempt according to the activity’s configured workflow. They distinguish it from “Save”, “Next page”, “Finish review” and “Return to course”. They reproduce the step in a sandbox quiz so the warning dialogs and subsequent status can be viewed. The target wording is then chosen for finality, not brevity alone. A phrase that is slightly longer but unmistakable may be safer than a shorter ambiguous imperative.
Test one attempt at the start, another immediately before final submission, and the confirmation state afterwards. Verify that screen-reader reading order and the button’s accessible name still express the same action. If the phrase occurs in emails or mobile flows, note those separately; one browser test does not prove every client uses the same string. The practical check is not “Does the target look translated?” It is “Would a reasonable student understand what happens after pressing this control?”
Variables are part of the message contract, not ordinary words
Moodle strings may contain placeholder variables whose values are inserted by the application. A template might include a simple placeholder such as {$a} or a structured value such as {$a->username} in contexts where the string system supports it. These symbols are not prose to be translated. Their spelling and structure connect the string to data supplied by Moodle. Removing a brace, changing an object property or treating a placeholder as a person’s literal name can produce a malformed message or incomplete notification.
Picture a message conveying that an assignment was submitted by a student. The target language may need a different order for student name, activity title and date. The correct approach is to understand the complete message and reorder surrounding words while leaving the technical variable names intact. When necessary, ask the plugin author or administrator what each placeholder represents and whether its value is already localised, for example a formatted date versus a raw timestamp. Do not infer the answer from a sample containing one English name.
Use test values that stress the format: a long learner name, a course title with punctuation, a value that includes non-Latin characters, and a blank optional field if the application can supply one. Check output in the actual screen or notification. In an exported local-language file, a missing placeholder may be obvious to a parser, but an awkward sentence around a correctly preserved placeholder is a human review problem. The two checks complement rather than replace each other.
Context-sensitive words: attempt, activity, enrolment, grade and completion
Moodle is an educational environment, not a generic shopping application. Several recurring English words have institutional meanings that translators must understand before choosing a target. An “attempt” can refer to an assessment attempt, not a casual try. “Enrolment” can involve access to a course, not necessarily admission to an institution. “Grade” may mean a recorded assessment value rather than a school year. “Completion” may refer to tracked activity conditions, not the learner’s declaration that they have finished reading.
Create a small term record with three fields: source term, operational meaning in your deployment, and proposed target wording. Add an example screen and a rejected alternative when it helps future editors. If “grade” has two possible target words, note the distinction between the gradebook result and the student’s academic year, then identify the strings concerned. This kind of glossary is deliberately smaller than a complete terminology database. It focuses on decisions that could change a learner’s action or interpretation.
Remember that a teacher and a student may meet the same word in different contexts. The label “visible” can mean available to learners in one administrative screen and simply displayed in another. The word “restricted” can refer to conditional access rules rather than a moral judgement. A translation should not imply broader permissions or guarantees than Moodle actually implements. If the operation has a precise definition in your site’s policy, confirm it with the policy owner rather than inventing it from the English label alone.
Plugin strings and theme strings have separate owners
A Moodle site may use a quiz plugin, video activity, attendance extension, custom report or visual theme that contributes its own strings. The words appear in one interface, but their ownership is distributed. A language-pack editor can show component-specific strings when the relevant plugin is installed. If you search only core Moodle or the wrong component, you might conclude that a string cannot be translated. In reality it belongs to a plugin language file or has been hard-coded by a developer.
Take an attendance plugin with a button reading “Present”. The same English word can be a status adjective, a verb meaning “show”, or an attendance value. The translator should ask what data the button writes. Does choosing it mark the student present? Does it display a presentation? The component and nearby interface behaviour settle the question. Translating only the word in isolation can flip its grammatical role and produce a confusing action label.
Keep a list of third-party plugins whose strings you modify locally. During plugin updates, check whether a new version introduces its own better translation, renames keys or changes the behaviour of the button. A local override might remain technically active while masking a corrected upstream term. Conversely, a renamed string might make the old local customisation irrelevant. Review changes against the newly installed plugin version instead of assuming all customisations remain appropriate forever.
Understand the precedence of language packs and local customisations
The official language pack is the shared baseline; your local customisation is a site-specific overlay. Moodle documents that local strings are stored separately from the official pack and take precedence where they exist. This separation is useful because official language packs can be updated without overwriting local terminology, whereas manual edits to the official pack risk being replaced during an update. The local folder holds the changed entries, not a second full copy of the global language data.
A helpful analogy is a transparent sheet laid over a printed map. The base map receives updates, while the transparent sheet still displays the specific annotations you chose. This is an analogy, not the internal implementation, but it clarifies why a local term can remain visible after a language-pack refresh. It also reveals a risk: an old annotation may no longer correspond to the new underlying map. A shared term can change meaning between versions, and an override can hide that improvement.
Therefore create an “override review” item for every major Moodle upgrade. Record the identifier, original source meaning, target override, reason and responsible approver. After the upgrade, confirm the identifier still exists and inspect whether the surrounding workflow changed. A local override should be treated as a maintained decision, not a permanent secret patch. The strongest translation system makes future editors able to explain why a wording choice was introduced.
Caches: why a saved translation sometimes looks unchanged
Suppose the language editor reports a saved customisation, but a tester still sees the old string. Do not immediately translate the phrase a second time. First verify that the test account uses the intended language and is visiting the exact screen covered by the change. Confirm the component and identifier were right, then refresh the relevant page. Look for custom theme behaviour, another plugin string with similar text, or a different delivery surface such as an email template generated separately.
Moodle stores language strings in caches for performance. Its supported language customisation feature normally manages cache changes during saving. If someone edits underlying files manually or moves a local pack between servers, Moodle’s guidance describes purging relevant language caches as a troubleshooting step. A cache purge is not a substitute for identifying the correct key. If the editor changed an unrelated identifier, clearing every cache on the server will not make the desired target appear.
Separate three observations in your incident record: the value shown by the customisation interface, the value shown to the test user, and the value delivered in the live action. If the first is correct but the latter two differ, investigate runtime language selection, caching and component ownership. If all three show the same incorrect wording, the translation itself needs revision. Diagnosis is faster when it tests causes rather than repeatedly pressing Save.
AMOS belongs to community translation, not a hidden site override
AMOS is the central Moodle translation toolkit. It stores strings and their history and provides a translator interface, temporary staging, stashes, contributions and maintainer review. A community contributor can prepare translations and submit them for a language-pack maintainer to accept or reject; a maintainer can commit approved changes. The official download packages are generated from the maintained translation repository. This workflow is valuable because consistent educational terminology serves institutions beyond a single Moodle installation.
Imagine discovering that a shared translation of “Completion conditions” incorrectly implies that the teacher manually awards completion when the platform is tracking configured conditions. The mistake affects many schools using that pack. A contribution with the original string, context, corrected target and explanation is more useful than a private workaround. If your own institution calls the same concept “Progress checks” as part of a branding programme, that may belong in the local layer instead. The difference is public correctness versus local naming policy.
Before contributing, inspect existing translation and discussions, coordinate with the language maintainer where appropriate, and keep proposed changes narrowly evidenced. Community translation is not a place to impose one institution’s marketing voice on everyone. A contribution may be edited during review; test the final official wording on your own site rather than assuming that submitting a stage changes the deployed pack immediately. Submission, acceptance, package generation, installation and display are distinct events.
A complete worked workflow for one plugin notification
A school uses an assignment activity and wants to adapt one notification sent to tutors. The message contains an activity title, a learner name and a status phrase. In a test environment, the administrator triggers the relevant workflow with synthetic accounts. They save the full original output and note whether the notification is in-app, emailed, or both. They find a distinctive source fragment in the customisation editor, inspect its component and confirm that the placeholders shown there correspond to the sample values.
The translator rewrites the target as a complete message instead of replacing one word at a time. They preserve every placeholder token and ensure the target grammar still works for a short and a very long learner name. The reviewer asks whether the notification represents a submission, a grading event, or a change to availability. These are easy to confuse when the English phrasing is short. The platform administrator tests the actual trigger, not just a preview of the string, and verifies that hyperlinks and named values point to the correct learner and activity.
Before release, the team produces a one-row record: component, identifier, previous value, new value, sample trigger, screenshots, reviewer and rollback step. This gives the next administrator enough evidence to assess the override after an upgrade. The important speed gain is not the time taken to type one notification. It is the removal of guesswork from every future report about that notification. Context can be reused; mistaken assumptions do not have to be rediscovered.
Test by role, screen and language rather than by one browser refresh
Plan a small test matrix. One dimension is the audience: learner, teacher, manager and site administrator where those roles see the relevant string. Another is location: desktop browser, responsive mobile browser, notification preview, and actual delivered message if applicable. A third is language: the target language plus the source/default language. A fourth is state: before an action, during confirmation, and after completion. Not every string needs every combination, but high-risk assessment wording deserves more coverage than a decorative label.
Start with the path most likely to reveal the issue. For a quiz finality warning, that is the learner’s final submission workflow. For a report title, it may be the teacher’s list view and export. For a course navigation term, test the dashboard and breadcrumbs. Use a short expected-result sentence for each scenario. A screenshot alone proves appearance, not meaning. The tester should record what the label allowed or caused the user to do.
Test accessibility as an ordinary quality dimension. Does the accessible name still convey the action? Do screen readers announce the replacement without duplicated hidden wording? Is the label truncated at common widths? Does keyboard focus remain understandable? Localised strings can be longer than the source; fitting text by deleting meaning is the wrong fix. If the problem is layout, report it to the theme or interface maintainer and retain the accurate message. Translation and rendering are separate responsibilities.
The costliest failure: a correct word in the wrong functional place
Suppose the word “Suspend” appears near course access. In one place it is a status showing that a user’s enrolment is suspended; in another it is an administrator’s action that will suspend it. A target language may need different word forms. If a team uses an unqualified glossary entry to translate both identically, a status can read like an invitation to click and an action can read like a passive description. The actual platform behaviour is unchanged, but the interface becomes harder to operate.
Another example is “Reset”. In a quiz it may mean resetting a preview; in authentication it can involve credential recovery; in reports it can clear filters. Translating all instances with the same dramatic verb may overstate the effect. Screen context decides whether it resets preferences, clears temporary input or performs an irreversible action. This is why source keys and usage notes matter. One word is not one meaning, and one meaning is not always one interface control.
A third case is notification language that states “has been submitted” while the system status is actually “saved as a draft”. The translated message cannot correct a workflow bug, but it must not conceal the distinction either. Confirm source behaviour with the plugin owner. If the source itself is misleading, log it as a product defect or source-copy clarification, not as a licence to invent different target behaviour. The translation should be accurate to the intended system action, with any product discrepancy tracked openly.
What not to change: course content, IDs, URLs and permissions
The language customisation system is not a shortcut for rewriting an educational curriculum. Course titles, teacher-authored lesson pages, quiz questions and student work may be stored as content rather than interface strings. Changing a pack will not reliably translate that content. Similarly, course IDs, activity identifiers, enrolment rules, role permissions and URLs are not translation targets just because a nearby label is. If a request would change those mechanisms, it belongs in site administration or course design with separate approval.
Do not attempt to “fix” a menu destination by translating its identifier or altering a URL in a label. A page can display a target-language name while continuing to use a stable technical identifier. It is valuable precisely because the system’s relationships remain unchanged. If a multilingual URL scheme is desired, that is a routing project beyond this article. Treat translation resources as presentation values unless the documented feature explicitly does more.
Also avoid embedding confidential user information into strings to make a sample look real. Use fictitious names and dummy course data in screenshots, notifications and regression records. A translation bug report should carry component ID, phrase and behaviour, not a learner’s private grade. That distinction makes the evidence easier to share safely with translators, maintainers and external plugin support.
A compact issue taxonomy for Moodle language work
When testing, classify a defect before fixing it. A wrong meaning is a linguistic defect: the target says something different from the intended action. A wrong owner is a lookup defect: the team edited the wrong component or key. A missing variable is an interpolation defect: the template no longer receives or displays essential data. A stale display is a deployment or cache symptom. A clipped label is a layout defect. A phrase absent from the language editor may be a hard-coded plugin issue or a content-not-interface misunderstanding.
This classification matters because the remedy changes with the cause. A linguist can revise a misleading imperative. An administrator can locate the correct key and resolve language selection. A developer may need to expose a previously hard-coded phrase for localisation. A theme maintainer may need to resize or wrap a control. Sending every issue back to the translator produces unnecessary cycles, while fixing every issue in code risks introducing changes the language system already supports.
For each defect, record reproducibility, impact and whether a learner could make an irreversible or consequential decision because of it. A misspelt decorative term should be corrected, but an ambiguous final-submission label deserves higher priority. The objective is not a perfect spreadsheet of every possible concern. It is a shared vocabulary for getting each actual problem to the person capable of fixing it.
A fifteen-minute inspection routine before release
Reserve three minutes to confirm the intended language, component and identifier against the current page. Spend four minutes on the target-language message itself: meaning, role, tone, action, numbers and variables. Use three minutes to trigger the real screen or notification in a test course. Spend another three minutes checking the same key at a second occurrence or role, then two minutes recording the result and rollback information. These are suggested attention budgets, not Moodle-specific performance promises.
If the string is high risk, expand the inspection. A final exam action, privacy notice, consent label or automated disciplinary notification may need a responsible reviewer and broader test matrix. Conversely, a heading in a seldom-used configuration page can be checked quickly when the owner and scope are clear. The principle is proportionality. Do not spend equal time on every label; spend time where a misunderstanding has consequences.
Use a “stop rule”: do not release if the exact owner remains unknown, a placeholder has changed, the target label implies a different action, or the tested interface does not show the approved wording. Release only after the acceptance statement can be demonstrated. This is the fastest form of caution, because it prevents an unclear edit becoming a campus-wide support ticket.
Translating quickly when multiple editors share a Moodle site
A language administrator, a curriculum specialist, a translator and a plugin developer may all participate. Give each person a clear responsibility. The administrator owns the key lookup, staging environment, saving and rollback. The translator owns target-language accuracy. The process owner explains what a control actually does and approves assessment or policy wording. The developer investigates strings that are missing from the translatable interface or whose placeholders cannot support the required grammar.
Use one lightweight decision record per changed key, not a shared document that merely says “updated French”. Include the course or screen, observed language, component and ID, old/new target, reason, test evidence and owner. If a terminology choice has site-wide implications, link that decision to the institution’s language style notes. The shared record is especially useful when a staff member leaves or a module gets upgraded. It lets someone else distinguish an intentional local term from a temporary emergency workaround.
When a reviewer disputes a translation, bring them to a reproducible action instead of arguing about a word out of context. Show the control, its consequence and the audience. The debate often resolves once the real workflow is visible. If disagreement remains, record the interpretation chosen and the reason. Quick translation is possible when decisions accumulate as trusted knowledge rather than evaporate after each meeting.
An upgrade rehearsal: what to review next term
Imagine Moodle and a third-party assignment plugin both receive updates before a new semester. The language customisations still exist, but the plugin has altered its submission process and introduced a clearer English warning. The old local target reads smoothly yet describes the former behaviour. This is semantic drift: the software changed while the translation survived. It will not necessarily be caught by a syntax checker, because the override is perfectly valid text.
Before opening courses to learners, inventory the local overrides affecting high-stakes flows. Compare their source meanings with current screens, and test the real actions. Remove an override if the official pack now supplies a better accepted translation and local policy no longer needs the difference. Update an override if the same string now has a changed semantic context. If an identifier disappears, determine whether the string was renamed, deleted or moved to another component before discarding its record.
Treat the term-start review as maintenance of an instructional environment. Teachers update assessment instructions when procedures change; administrators should do the same for interface language. The principle transfers to learning management systems generally, but Moodle’s combination of language packs, local customisations and AMOS makes the ownership boundary particularly visible. That is the boundary this guide teaches readers to manage.
A practice exercise for an administrator and a translator
Choose a low-risk Moodle label in a staging course. Without changing it, ask each person to predict its component, audience and every screen where it appears. Find the entry in language customisation and compare the predictions with the actual owner. Then agree on a target-language replacement that preserves the interface function. Apply it locally, save, and test the relevant page with two user roles. Finally, restore the original value so the exercise does not become an undocumented policy change.
Discuss the surprises. Did the same English word have several string IDs? Did a plugin supply the label rather than Moodle core? Did the target language need more space? Was the saved translation visible immediately? Did the lecturer and translator disagree about the meaning until the workflow was demonstrated? Those observations become the team’s practical guide for later, higher-stakes changes.
Repeat the exercise with one notification containing a placeholder and one item whose wording is shared across pages. The aim is not to memorise every Moodle component. It is to learn the sequence: locate the exact identity, understand the action, protect system syntax, test the delivery surface, and record the decision. This sequence turns a seemingly mysterious localisation task into a manageable editorial process.
Transfer: what Moodle teaches about translation systems
Moodle illustrates a principle that applies across modern software: language is data with ownership, scope and lifecycle. A phrase may be grammatically perfect yet wrong for a particular action, or technically safe yet misleading to its audience. A translation system succeeds when people can trace a displayed sentence to its source, identify who can change it, and test the effect. That traceability is more valuable than rushing through strings with no record of where they appear.
It also demonstrates why local vocabulary needs restraint. Different schools can legitimately prefer different names for learning activities, but those names should not overwrite the technical meaning of enrolment, completion or assessment. The best localisation lets institutional language feel natural while retaining the behaviour learners must understand. Distinct layers make that possible: official pack for shared linguistic coverage, local overlay for campus-specific needs, and course content for teacher-authored learning material.
For broader checks, eduKateSG’s localization build validation guide explains how to validate target resources in the software release pipeline; placeholders and non-translatables examines protected tokens; and look-ahead reading explains how local context prevents rework. Those articles own transferable methods. This page owns the Moodle-specific task of making a safe local interface-language override.
Frequently asked questions
Can a Moodle administrator change one word without translating the entire language pack?
Yes. Moodle’s language customisation feature supports site-specific changes to selected strings. Identify the exact component and key, enter a local customisation for the desired language, save and test. There is no need to copy an entire official pack merely to change one institutional term. Keep a record so an upgrade does not leave the reason for the override unexplained.
Why does the old English word still appear after my local customisation?
First confirm that the test user is using the intended language and that you edited the correct component and string identifier. Two visually identical source phrases may belong to different components. Next check whether the text is actual interface language or authored course content. After that, investigate caching and plugin behaviour. Clearing a cache cannot repair a wrongly identified source string.
Is AMOS the same as Site administration language customisation?
No. AMOS is Moodle’s central community translation system for contributing to language packs. Site administration language customisation is a local override mechanism for an individual installation. Choose based on audience: public correction for the shared pack, or specific wording your institution needs only on its own site.
Will a Moodle update erase my local terminology?
The supported local customisation mechanism keeps custom strings separately from the official language pack, which is designed to prevent direct overwriting during routine pack updates. You must still review changes when an update alters a feature’s meaning, removes a key or changes plugin behaviour. Persistence of a string is not evidence that it remains correct.
Can I translate placeholders such as {$a} or {$a->username}?
No. Preserve technical placeholder names and syntax when localising a message. Translate the surrounding sentence and change its word order if necessary, then test with representative values in the actual interface. Ask for context if a value’s grammatical role is unclear.
Why can I not find a phrase from a third-party activity?
It may belong to that plugin’s own component, require the plugin to be installed before its strings are available, be a separate email template, or be hard-coded rather than exposed for translation. Identify where the phrase comes from before trying to replace a vaguely similar Moodle core string.
What is the difference between interface strings and course material?
Interface strings are controlled by Moodle or plugin code and language resources. Course material is authored educational content: pages, lessons, attachments and many assessment questions. Language customisation targets the former. Translating the latter requires a content process and appropriate academic review.
How can I safely test a final-submission label?
Use a staging course and synthetic learner accounts, trigger the action, and verify that the target wording explains its consequence. Check warning dialogs, confirmation states and relevant accessible names. Do not test potentially irreversible actions against real learner assessment records.
Should a school change every occurrence of “Course” to its preferred term?
Not automatically. Similar source text can describe different concepts, and the same key may serve more pages than expected. Define exactly which reader-facing concept must change, inspect the key’s scope, and test other uses. A brand-preferred word should never make a control less clear.
What should go in the translation change record?
Record language, component, string identifier, original and new text, reason, affected feature, test account role, test result, reviewer, version and rollback step. Screenshots with fake data can help. The record should let the next administrator reproduce the decision rather than guess why an override exists.
Summary: translate the right Moodle string once, then prove it works
Rapid Moodle interface translation is a controlled selection problem. Locate the component and string ID, decide whether the change belongs in the official pack or a local override, preserve variables, choose wording that matches the action, and verify the actual result under the correct language and role. Keep local changes separate from course content and from system identifiers. Document the smallest change that satisfies the learner’s need, then revisit it after upgrades. That combination of precise lookup and real-world testing makes speed sustainable.
Official references and further reading
The primary product references are MoodleDocs on Language customisation, the AMOS manual, Moodle’s live translation community, and the language-pack downloads. Consult the documentation branch matching your site’s Moodle version and confirm the exact component or setting before changing production wording. These references support the platform workflow; the worked school scenarios above are instructional examples, not descriptions of any identifiable institution.