A lot of work has been done in recent years to improve Moodle's support for multi-language. Moodle is also currently going through an accessibility review.

To my knowledge, there isn't a Moodle course available that would enable proper testing of Moodle course features for multi-language support and accessibility. As a result, developers and quality assurance (QA) testers are constantly re-creating parts of such a course to do this verification.

A non-source code project that I feel would be seriously useful and appreciated by developers and QA testers around the world is a good QA Test course to test the following for multi-language support and accessibility:

  • All the core Moodle course activities
  • All the core Moodle course resources
  • All the core Moodle blocks that can be added to a course.

When testing Moodle for accessibility, you want to test the code generated by the application, not the quality of the content produced by the course developer.

Required Skills

The only skills required to work on this project are:

  • Ability to type in English. Knowing a second or third language would be great but is not required.
  • Know how to add activities, resources and blocks in a course.
  • Some familiarity with Moodle can be an asset.

You DO NOT need to know…

  • More than one language
  • Instructional design
  • Anything about accessibility
  • HTML, CSS, JavaScript or PHP!

Configuring Moodle

In order to configure Moodle for Multi-Language and Accessibility Testing, you will need to:

Install and enable the third-party filter plugin called Multi-Language Content (v2). You can download it from: https://moodle.org/plugins/filter_multilang2 . Be sure to enable the filter for Headings and Content.

You should need to enable all course-related features, especially Comments, Completion Tracking and Restricted Access as these can have an impact on what is displayed in a course. The site should be configured to use the stock Boost theme as this is the basis for most Moodle themes today.

The Moodle Atto editor has never yet produced HTML5 compliant content since its creation. I therefore recommend using the TinyMCE editor instead for this project. You can change that by going to User Menu > Preferences > Editor preferences and choose the TinyMCE editor. Even better, for this project, set TinyMCE as the default editor for the whole Moodle site.

The Course

This course will not be a course in the usual way. Instead, it will be filled with meaningless content that only a developer and QA tester will appreciate.

Here is an overview of what needs to be done. The details will follow.

  • Create a new topics format course.
  • Add sections to the course
  • Add activities to the sections.
  • Add blocks to the course

The first step will be to create a new topics format course containing 18-20 sections. Be sure to give your course a title, summary and course image. More information on this shortly.

Next, create a course section for each of the following activity and resource modules:


  1. Assignment
  2. Chat
  3. Choice
  4. Database
  5. Feedback
  6. Forum
  7. Glossary
  8. H5P (optional – only if you have some very simply H5P content to embed in the page). Eventually, this will be needed as H5P is scheduled to become fully integrated in Moodle 3.9. At that time, each H5P activity type will probably need to be represented in this course.
  9. Lesson
  10. Quiz
  11. SCORM package (only if you have a very simple SCORM package available)
  12. Survey
  13. Wiki
  14. Workshop


  1. Book
  2. File (cannot be made multi-language)
  3. Folder
  4. Label
  5. Page
  6. URL (cannot be made multi-language)

Course Activities

As you progress through the list of sections, you will need to create as many activities of that type as required to make use of every Moodle feature in every possible combination.

For example, you may be able to combine multiple quiz question types in one and could create them all in the same quiz. However, for simplicity, I recommend that you create a separate quiz for each of the 16 question types and, within each quiz, create a series of questions which make use question type’s various options:

  1. Multiple choice
  2. True / False
  3. Matching
  4. Short answer
  5. Numerical
  6. Essay
  7. Calculated
  8. Calculated multichoice
  9. Calculated simple
  10. Drag and drop into text
  11. Drag and drop markers
  12. Drag and drop onto image
  13. Embedded answer (Cloze)
  14. Random short-answer matching
  15. Select missing words
  16. Description

And within each of these are many options for how to display, answers, feedback, correct answers, wrong answers and grades. Each display format for a question must be included in the test. Small things like whether radio buttons are listed horizontally or vertically can result in different test results.

Another complex activity module is the Feedback activity which includes the following elements and question types:

  1. Add a page break
  2. Captcha (you will need to enable Captchas on your site to use this one)
  3. Information
  4. Label
  5. Longer text answer
  6. Multiple choice
  7. Multiple choice rated
  8. Numeric answer
  9. Short text answer

Within each of these are many options for display, answers, feedback, correct answers, wrong answers. Each display format for a question must be included in the test. Small things like whether radio buttons are listed horizontally or vertically can result in different test results.

Some module types, such as the label and page, will be very simple while others, such as the Quiz and Feedback forms will be quite complex as they have so many options.

Don’t forget to include examples with Completion tracking and activity restriction enabled and disabled. You don’t necessarily need to do this for each possible test but should for at least one or two where it would affect what is being displayed.


You should add one instance of the 30 core Moodle block to the course. It may look odd but it will make it possible to spot accessibility and language issues.

Course Content

The content should be minimal to ensure that it is not the content that is causing an accessibility issue during testing.

To meet that objective, the course does not need to contain real information. For example, I use the Multi-Language Content v2 plugin from moodle.org/plugins a lot with my clients. It uses the {mlang} tags.

In the following examples, I used English and French. However, you could make it English and just about any other language. Two languages are usually enough. However, if you wanted to use a third language and had the skills for it, you could use a right-to-left (RTL) language for the third.

Here are a few examples of content.

For a course name, you might put:

 {mlang en}Course name in English{mlang}{mlang fr}Course name in French{mlang}

For an HTML block title field, you might use the following:

{mlang en}HTML Block title in English{mlang}{mlang fr}HTML Block title in French{mlang}

And for the HTML block content field:

{mlang en}HTML Block content in English{mlang}{mlang fr}HTML Block content in French{mlang}

As you can see, the content need not be in a different language. It just needs to be different so that we can see that there has been a change when I changed the UI language.

Why use the 3rd party Multi-Language Content (v2) filter? Doesn’t Moodle come with its own?

This is the syntax for the core Multi-Language Content tags. Because it is HTML, it must be inserted directly into the HTML source code:

<span lang="XX" class="multilang">your content here</span>

This is the syntax for the 3rd party Multi-Language Content (v2) tags. It is entered along with the rest of your text, but can equally and just as easily be inserted directly into the HTML code:

{mlang xx}your content here{mlang}

The fact that you don’t need to know any HTML to apply these tags makes it so much easier to prepare content outside of Moodle and just copy and paste it in. These plain text {mlang} tags have several other advantages over the more complicated HTML based multi-language content <span> tags that come with Moodle:

  • They are significantly shorter. This means that can include more content or more languages in fields that are limited in length.
  • They are not HTML. There are many fields in Moodle that will simply not accept or will filter out HTML upon saving it. {mlang} tags work in situations where the span tags don’t.
  • {mlang} tags are typed in along with the rest of the content. You don’t need to search through HTML content to figure out the proper placement of the tags.
  • Because the {mlang} tags are visible in the WYSIWYG editor, it is also clear to see where one language ends and another begins. It is also easy to spot when they are not being processed and therefore identify filtering issues.

When correctly applied in an appropriately configured Moodle site, the language of a course should change automatically when a user changes the UI language in Moodle.

Answers to a few questions you might have…

If you try to use a language other than the ones implemented by the tags, you will not see any content. Don’t be too surprised, there are still many places in Moodle where content fields are not processed through Moodle filters. That is why this QA Test course is so needed.

Some content is not yet filtered in Moodle courses. Examples include the Glossary, the Database and Badges. I am letting you know, because, if you backup your course, this information may be missing when you restore it to the same or on a different site.

If you have the skills, you could translate the content instead of having the same content in English appended with the words “in French”. What is important here is that it be different between English and French, and not introduce any accessibility issues on its own. In my examples, I am using English and French simply because these are the two official languages here in Canada. English is also known to be the international language of business and the base language in Moodle.

Why not use language-neutral content like Lorem Ipsum? Because testers probably could not tell that there was a change in language and, when there is an issue, they won’t be able to necessarily tell what data entry caused the issue.

Why not use actual course looking content? I believe that creating this course will already be a pretty big project on its own without having to develop actual course content. The focus here should be on testing Moodle, not the content.

What about the existing Activity Examples course?

Some might suggest that you start with the following course which would be similar in format:

While a great course to demonstrate the different activities and resources available in Moodle, it fails to be useful in Language and Accessibility QA testing of Moodle for the following reasons:

  • It contains too much content.
  • It is not a multi-language course.
  • There are accessibility issues in the content.
  • It does not include content in all possible configurations.
  • Its Glossary and Databases are empty.
  • There are no course badges.

With that said, developers and testers are still free to test using that course too. It is a great course for testing other aspects of Moodle such as the various types of content that one can insert into a course. However, I believe that a separate course would make the jobs of testing for accessibility and language by developers and QA testers easier.