Note: You are currently viewing documentation for Moodle 2.6. Up-to-date documentation for the latest stable version of Moodle may be available here: Language customization.

Language customization

From MoodleDocs

Words or phrases (in any language) used on the site may be easily changed by an administrator using the language customization feature. For example, you may want to change the word "Course" to "Unit". The process consists of 4 steps:

  1. Check-out the strings
  2. Filter the strings you wish to customize
  3. Customize the strings
  4. Save and check-in the strings

Quick instructions for the impatient

  1. Go to the Administration > Site administration > Language> Language customisation page.
  2. Pick the language to customise from the pull down list.
  3. Click on the "Open language pack for editing" button. This may take some time to process.
  4. Once the language pack has loaded, click on the "Continue" button.
  5. Click or Ctrl+Click to select the files in the "Show strings of these components" list. Notice that the files are grouped. For example, you will find the lesson strings under "mod" and moodle.php under "core".
  6. After selecting the file(s), it is possible to use the "Only strings containing" filter along with other filters. For example, to look at only the string text that has the word "teacher" the file(s) you selected.
  7. Click on "Show strings".
  8. Make your changes in the appropriate "Local customisation" box.
  9. Click on "Apply changes and continue editing" if you want to use another filter or edit other file(s).
  10. Click on "Save changes to the language pack" to save all of the changes you have made.
Tip: Do not see any string changes? Did you remember to use the "Save changes to the language pack" button? Did you refresh your browser so that it is not looking at a cached page? Did you edit the language file that is actually being used on your site, course or by the user?
Tip: Can't find the string you wish to change? Tick the 'Show origin of languages strings' checkbox in Administration > Site administration > Development > Debugging then visit the page containing the string you want to customise.


Moodle is translated into many languages - see Language packs for their list and the translation completion status. The translations are distributed in so called language packages (or just lang packs) that are maintained by kind volunteers, community contributors and Moodle partners. Please read the page Translation first to understand how the whole localization machinery works.

Moodle site administrators can customize any language pack to fit their individual needs (for example to use the term "Unit" instead of "Course"). You are discouraged from direct editing the files coming as a part official language pack. Such changes would be silently overwritten during the next upgrade. Instead, you should create a local language pack that holds all your changes from the official pack.

Local language packs have the same structure as the official ones. They are saved in your Moodle data directory in moodledata/lang/xx_local/ folder where 'xx' is the code of the language. You have to have the official language pack installed before you can customize it. Local language pack should contain just strings you have customized - you should not copy whole official language packs.

When displaying a string, Moodle first looks if a local customization of it exists in moodledata/lang/xx_local/component_file.php. If so, it is used. If not, the string from the official language pack is used (eventually, if the string has not been translated yet, the original English version is displayed). Please note that the strings are cached for better performance so you have to purge Moodle caches after you modify a file in your xx_local pack (caches are purged automatically if you use the tool described below).

Using Language customization tool

Moodle comes with a tool that allows you to edit your local language pack via web interface. This tool is available for the site administrators in Settings > Site administration > Language > Language customization. Please refer to the following workflow diagram.

Workflow of the language customization (click to enlarge)

Check out strings into translator

At the Language customization first page, select a language to customize and press the button 'Check out string into translator'. During the checkout, Moodle loads the language strings from PHP files into its database. The language customization tool works with this database so the files in your xx_local pack are not touched unless your proceed to the final step of this workflow. If the xx_local language pack does not exist yet, Moodle automatically creates an empty one for you.

Tip: There is currently a problem with "execution time". If you get the "Fatal error: Maximum execution time of 180 seconds exceeded" message, you will have to press the button 'Check out string into translator' several times to get the operation completed. See forum discussion.

Use filter to find the strings you want to customize

Moodle 2.0 language filter

After the checkout, use the "filter strings" form to find strings you want to customize for your site. Not selecting any filters will display all strings in the language pack.

  • Show strings of these components - Click or Ctrl+click to select one or more files that contain the string you want.
  • Customized only - check this field to display only those strings that are already present in your xx_local pack.
  • Help only' - check this field to display only help tooltips, that is the texts used when clicking the yellow question mark icon.
Note: Starting in Moodle 2.0, help string identifiers must end with _help suffix.
  • Modified only - displays only the strings that are modified in the current session.
Note: The term 'customized' means strings that are saved on disk in your xx_local pack directory. The term 'modified' represents the changes made since the last checkin string into the language pack. Customized strings (already saved in a file) are highlighted with green. Modified strings (not saved in a file yet) are highlighted with blue.
Tip: You may want to use this option look at your current work before you check it in.
  • Only strings containing - insert a phrase that must appear in the string. For example, if you put a word 'student' here, you will get only those strings that contain this word.
Tip: The 'Only strings' filter can be used for a total search for a term used in your Moodle site for the selected language pack.
  • String identifier - if you know the string identifier (it is the first parameter of the get_string() function), type it here. For example, the names of activity modules are defined in strings 'modulename'. Finding where a particular string is saved can be difficult sometimes. The administrator can start a debugging function: Site administration>Development>Debugging and choose "Show origin of language strings". Then if you append "?strings=1" (or "&strings=1" if there is already a parameter) to the end of the page URL, beside each string will be shown something like "{rememberusername/admin}". The last part says which php file uses the string, so this one is in admin.php. If there is nothing after the / look in moodle.php. The first part, before the /, is the string identifier.

Use combination of filter settings to get the required set of strings.

Click button 'Show strings' for potential editing.

Input your own translation

The strings that pass all the conditions defined in the filter are displayed in a table. To replace the standard translation, put your own into the 'Local customization' field.

Tip:If you want to delete your current customization , just delete the content of the 'Local customization' field and click the "Save and continue editing". The modifications that are going to be removed a customized string are highlighted in red. If you made changes to a field previously "Save and continue editing" it will be highlighted in blue.

Click "Save and continue" button before you change the filter settings and show a new set of strings.

Saving your work into files

As necessary, you may repeat the "show strings", "local customization" and "Save and continue" process. When you have made all the changes you want to make:

Click "Save and check in strings into files" to process all changes made in the translator database to your local language pack.

Writing the modifications into files

During the checkin, the contents of the translator database are dumped into files in moodledata/lang/xx_local/ directory.

Click "Save and check in strings into files" to process all changes made into your local language pack.

Note: this operation removes the directory first and then re-creates it with the actual data. Therefore it is reasonable to not to touch the files directly after you have checked out them into the translator.

How to backup and restore a customized language pack

This is handy when you have made customizations of your language pack and you want to install these changes in another server.

If you customized a language pack xx, the only folder you need to back up is $CFG->dataroot/lang/xx_local. All others without the _local suffix are standard packages that can be installed and uninstalled via the admin tool.

Once the folder is restored at another server, you also have to manually purge caches from the admin interface to let the in-built string manager to re-read the *_local folders and start using them.

Database error seen when attempting a language customization

The language customization tool normally takes a fairly long time to execute the very first time (for each language pack) it is used in a Moodle site. This is because it needs to access the Moodle DataBase. Later uses of the Language customization tool are rather quick.

Database error while language customization.png

Sometimes you may encounter a DataBase error when you try to customize your language pack. This error may be caused by a recent add-on that corrupted the database. You are advised to check all plugins recently added to your site, and test if removing a plugin prevents this error. If that is the case, please contact the maintainer for the involved plugin and report the error. Most cases seen in 2013 were fixed by the maintainers of those plugins.

Or, you can execute a DataBase query at your server in order to track down the plugin causing the problem.

See also