The Wagtail admin backend has been translated into many different languages. You can find a list of currently available translations on Wagtail’s Transifex page. (Note: if you’re using an old version of Wagtail, this page may not accurately reflect what languages you have available).

If your language isn’t listed on that page, you can easily contribute new languages or correct mistakes. Sign up and submit changes to Transifex. Translation updates are typically merged into an official release within one month of being submitted.

Logged-in users can set their preferred language from /admin/account/.
By default, Wagtail provides a list of languages that have a >= 90% translation coverage.
It is possible to override this list via the WAGTAILADMIN_PERMITTED_LANGUAGES setting.

In case there is zero or one language permitted, the form will be hidden.

If there is no language selected by the user, the LANGUAGE_CODE wil be used.

This section of the documentation will show you how to use Django’s translation features with Wagtail and also describe a couple of methods for storing/retrieving translated content using Wagtail pages.

Just enabling the multi-language support in Django sometimes may not be enough. By default, Django will serve different languages of the same page with the same URL. This has a couple of drawbacks:

Users cannot change language without changing their browser settings

It may not work well with various caching setups (as content varies based on browser settings)

Django’s i18n_patterns feature, when enabled, prefixes the URLs with the language code (eg /en/about-us). Users are forwarded to their preferred version, based on browser language, when they first visit the site.

This feature is enabled through the project’s root URL configuration. Just put the views you would like to have this enabled for in an i18n_patterns list and append that to the other URL patterns:

# mysite/urls.pyfromdjango.conf.urlsimportinclude,re_pathfromdjango.conf.urls.i18nimporti18n_patternsfromdjango.confimportsettingsfromdjango.contribimportadminfromwagtail.adminimporturlsaswagtailadmin_urlsfromwagtail.documentsimporturlsaswagtaildocs_urlsfromwagtail.coreimporturlsaswagtail_urlsfromsearchimportviewsassearch_viewsurlpatterns=[re_path(r'^django-admin/',include(admin.site.urls)),re_path(r'^admin/',include(wagtailadmin_urls)),re_path(r'^documents/',include(wagtaildocs_urls)),]urlpatterns+=i18n_patterns(# These URLs will have /<language_code>/ appended to the beginningre_path(r'^search/$',search_views.search,name='search'),re_path(r'',include(wagtail_urls)),)

Important

The example above assumes you are using Django version 2.0 or later. If you are using a Django version earlier than 2.0, you should rename all occurrences of re_path() to url(). For example: fromdjango.conf.urlsimportinclude,url instead of fromdjango.conf.urlsimportinclude,re_path and url(r'^django-admin/',include(admin.site.urls)), instead of re_path(r'^django-admin/',include(admin.site.urls)),.
(read more).

You can implement switching between languages by changing the part at the beginning of the URL. As each language has its own URL, it also works well with just about any caching setup.

Static text in templates needs to be marked up in a way that allows Django’s makemessages command to find and export the strings for translators and also allow them to switch to translated versions on the when the template is being served.

As Wagtail uses Django’s templates, inserting this markup and the workflow for exporting and translating the strings is the same as any other Django project.

In order for the translations to be shown on the site frontend, the correct field needs to be used in the template based on what language the client has selected.

Having to add language checks every time you display a field in a template, could make your templates very messy. Here’s a little trick that will allow you to implement this while keeping your templates and model code clean.

You can use a snippet like the following to add accessor fields on to your page model. These accessor fields will point at the field that contains the language the user has selected.

Copy this into your project and make sure it’s imported in any models.py files that contain a Page with translated fields. It will require some modification to support different languages.