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).

Add new comment