Drupal 8 multilingual tidbits 4: highly flexible detection options

Up to date as of October 16th, 2015.

Once/if you have multiple languages configured on your website, selecting from them for the page becomes an important question. The Drupal 8 language detection and selection options are located the same place they were in Drupal 7 but almost all options got some improvement.

Useful out of the box

Drupal 7 only had the default language detection method turned on, so even if you kept adding in more and more languages (and even if you enabled the language switcher block), the URLs did not work. You still needed to get here and configure the URL detection method. Now this is built-in, so adding languages and placing a selector block would in itself make multiple languages accessible.

In-place configuration for URL language

Instead of the URL negotiation settings configured with languages, they are now housed where they are used, within the detection and selection configuration options. You can configure paths and domains here and even see nice complete URLs of how your site languages will be accessible. (We also took great care to make changes in site defaults properly update URL prefixes when configured, keeping existing paths as appropriate).

(The session setting is kept as-is from Drupal 7.)

More flexible user account preferences

The user system can now store up to three different languages associated with a user. The user profile language, the user's preferred language and (for admin users) the preferred language for administration (see below). By default, users will only see one preferred language option to configure, but for sites with a need to differentiate user profile content language information from user preferred language, that is possible in Drupal 8 with some altering. There are no changes to the configuration of this option as exposed by Drupal core by default.

Improved and configurable browser language detection

The algorithms used for browser language detection are highly improved, and now Drupal understands that the language codes it uses may not be what other systems use in the world. So there is an outside-inside language mapping table that lets you configure which browser configurations map to which internal languages. The mapping shown on this screenshot is what is shipped with Drupal by default. Other uses of this feature may be implemented in contrib.

New administration language feature

There is a module called Administration language available for Drupal 6 and 7. That module allows one global administration language to be specified for the site. On the other hand a new built-in feature in Drupal 8 exposes a per-account setting for each account with access to the administrative backend to provide a preferred language for the backend if desired. If you want to use this feature, it is suggested you place it as the first option above the URL detection method. That way, the normal URL detection can kick in for frontend paths, while the admin language takes precedence when on the admin backend. The user preference in account editing for the admin language will only be present if this option is enabled and only for users with access to the admin backend.

New selected language option

In Drupal 7, the last item in the list was the Default language option, so sites would fall back to the site global default language configured elsewhere. This made many people change the site default language when they intended to change how the site picked the page language by default. Changing the default language had numerous other unintended side effects as for example one of the commenters noted on my previous tidbit. So Drupal 8 makes this configurable. While it works with the site default language originally, it can be changed to any of the configured languages. No need to change the site default language anymore! This feature is implemented in the Fallback language negotiation module on Drupal 7, if you need this functionality now.

Still as extensible as before

Contributed modules can still add more options here using our APIs, but with the vastly expanded features, there will be less of a need to do so in Drupal 8.

Issues to work on

  • DONE! When content translation module is enabled, a content language negotiation option set is also made available. Two corresponding blocks are then exposed for language switching. However, on most sites, the two would be the same, so we should only expose the additional complexity when needed. See http://drupal.org/node/1833022 for an issue that is getting pretty close to resolve this.
  • DONE! Only letting users to set an empty prefix for the default language is actually not as flexible as the fallback language configuration suggests. When used in combination, to change the fallback language only makes sense if prefixes then allow empty values there. See https://www.drupal.org/node/2411343


Thomas Svenson's picture

It would be great if you could give a more explanatory description of the language fallback works. For me this is mostly important for site users (visitors) and thus a content issue.

Since Drupal is able to use different human readable URL's for translated pages, this is not generally a problem for pages users land on. However, for things like teasers, and Views lists, its a whole different matter. If an item there isn't available in the users current/preferred language, then it should optionally include the default language item. For D7, core does this, but unfortunately Views, last time I experimented with it, has no support for it.

How will this change for Drupal 8? Will Views fully support this? Will it be possible to more granular control of it, such as select what languages to include in the fallback and the order they will be checked?

Also, will it be possible for users to override the default and define their own fallback languages/order?

Gábor Hojtsy's picture

This is not possible in core, but it may be possible in contrib if only TranslationLanguageRenderer::preRender() would pass on some unique views environment identifier string to entity view. That would let contrib to do custom language fallback for views specifically. If the view name itself is also passed on, it may be made configurable per view as well. A core issue would be useful to track this request.

Thijs Vervloessem's picture

Hello Gábor,

What should be the best practice for a website which delivers content in Dutch and French but admins would like to have the administration pages in English.

So far, I have 3 languages enabled (Dutch, French and English) and have set English as my preferred language for the backend. Dutch is the default language. Is there a way to avoid that people make content in English?

Thanks for your work. As Belgians (country with 2 languages) we appreciate the hard work which is delivered on Drupal 8 Multilingual.


Gábor Hojtsy's picture

Hi Thijs. I guessed this will be a common request. The next article has this at the end which applies very well to your situation:

All the configured languages including the special ones will be available across everything in Drupal; content, configuration translation, etc. It would be great to have a system where some languages are not exposed in all environments. See https://drupal.org/node/1314250 for a discussion on such a system. Does not seem very likely for core unfortunately at this point. May need to be a contrib module that does massive form altering at different places based on configuration.

So in short, no not available in core. Yes, could be possible in a contributed module (and may eventually end up in core).

Gaurav Pahuja's picture


I have a requirement for using some path prefix along with domains.
For example: example.com and example.cn are server aliases.

For English I want to use example.com/en
For Spanish example.com/es
But for Chinese example.cn/cn.

How can I do it?

Gábor Hojtsy's picture

This is not possible to configure in core. It is an either or situation. However, you can write your own language negotiator plugin and implement this reusing the logic in the existing domain/path negotiator plugin.

Quevin's picture

@ Gaurav have you implemented this idea from Gabor? I'm very interested in learning whether you wrote a "language negotiator plugin," and what that might look like, thanks!

gerald's picture

I can't find any way to disable language fallback in D8 and instead show a message like "Español translation unavailable" with links to the available translations. Any possibility to archive that?

Gábor Hojtsy's picture

A contributed module could do that. It is not currently possible in core.

Philipp's picture

Where can I enable the administration language feature in Drupal 8? And is it possible to set a default language (not english)? I don't want to have a translated interface when I edit a content translation.

Gábor Hojtsy's picture

You can enable the administration language feature at the language negotiations settings, go to the language list and hit the selection and detection tab. After that, the specific admin language is a per user setting.

Philipp's picture

Thank you. In addition I set the option "Customize Content language detection to differ from Interface text language detection settings" where the "Account administration pages language setting." is not active. Otherwise I have problems to translate content (e.g. get English content even though I wan't to edit the German translation).

Cusco's picture

I installed Drupal 8 in English then I added Spanish and go to configure the path prefix. Drupal show me English(the default language) without path prefix, but Spanish have "es" prefix. Is this the recommended way? Or Do you suggest to put "en" for english?

Gábor Hojtsy's picture

The reason Drupal does this is you already had an English site without a path prefix. So you may have had visitors, search engines may have indexed you, etc. So keeping the English path prefix as empty keeps your existing URLs as-is. If it would change the prefix, your existing URLs would break. You have the choice to configure it differently of course if you want to, just keep the consequences in mind. (There is no language URL redirection feature in core as of now).

AmirSgh's picture

Is it possible to use different language detection system for Administration.
exp: domain based detection fro FO and path prefix fror BO ? Thanks

Gábor Hojtsy's picture

Core does not support that given that admin language is not an entirely different language type but rather a negotiation option that you can enable, so that does not have an effect on whether URL negotiation is based on the path or domain for example. A contributed module could add a new language type to support this.

Add new comment