Description
A Content item can be translated into several languages. Those languages are configured in the system and exposed in siteaccesses via a prioritized list of languages:
When visiting a Content item, it may be useful to let the user switch from one translation to another, more appropriate to them. This is precisely the goal of the language switcher.
The language switcher relies on the Cross-SiteAccess linking feature to generate links to the Content item's translation, and on RouteReference feature.
Tip
If you install the DemoBundle with at least 2 different languages, you will be able to see the Language Switcher and to test it.
Usage
Configuration: explicit translation siteaccesses
Configuration is not mandatory, but can help to distinguish which siteaccesses can be considered translation siteaccesses.
Note: Top prioritized language is always used for as the siteaccess language reference (e.g. fre-FR
for fre
siteaccess in the example above).
If several translation siteaccesses share the same language reference, the first declared siteaccess always wins.
Configuration: more complex translation setup
There are some cases where your siteaccesses share settings (repository, content settings, etc.), but you don't want all of them to share the same translation_siteaccesses
setting. This can be the case when you use siteaccesses for mobile.
Solution is as easy as defining new groups:
Configuration: using implicit related siteaccesses
If translation_siteaccesses
setting is not provided, implicit related siteaccesses will be used instead. Siteaccesses are considered related if they share:
- The same repository
- The same root location Id (see Multisite feature)
In a template
To generate a language switch link, you need to generate the RouteReference
, with the language
parameter. This can easily be done with ez_route()
Twig function:
You can also omit the route, in this case, the current route will be used (i.e. switch the current page):
Using sub-requests
When using sub-requests, you lose the context of the master request (e.g. current route, current location, etc.). This is because sub-requests can be displayed separately, with ESI or Hinclude.
If you want to render language switch links in a sub-request with a correct RouteReference
, you must pass it as an argument to your sub-controller from the master request.
ezpublish.translationSiteAccess( language )
returns the siteaccess name for provided language (ornull
if it cannot be found)ezpublish.availableLanguages()
returns the list of available languages.
Using PHP
You can easily generate language switch links from PHP too, with the RouteReferenceGenerator
service:
You can also retrieve all available languages with the TranslationHelper
:
3 Comments
Dovydas Baublys
How to install DemoBundle with at least 2 different languages ?
Dominika Kurek
Hello, Dovydas Baublys
I assume you mean the Platform Demo Bundle? (because the Studio Demo has a couple of languages by default).
Platform Demo only has content in English. To have more languages, you need to add them after installation. Have a look here for more info:
Using multiple languages
Managing languages
Dovydas Baublys
Thanks, I mean platform demo bundle. And if I add default siteaccess, not in english, then type I create is undefined.
For example default_siteaccess: lit. Created new content type dish. In content tree I'm trying to create new, it show undefined.