Working with multiple language websites in TYPO3?

[Junior]

There are two concepts for working with multiple language websites in TYPO3. This is the topic of todays tip and the first thing I'm going to do is to outline the difference of these concepts so you'll better understand which way you should go yourself.

This is the "old" way to do it. This does not imply "old-fashioned" as if this is an inferior way to the new possibility! It just fits another purpose.

Schæffergården in Denmark is a high class conference center which has a website in both english and danish. As you see from the screenshots below their welcome pages look much alike:

... and the english welcome page:

Both the english and danish version are from the same TYPO3 database, but they are implemented as two "different" websites from the same database. This concept is widely known and tested - the ability of TYPO3 to run more independent sites within the same page tree. This is the "Two-tree" concept and as such it is not specifically about multiple language websites - we simply decide to take advantage of this inherent capability of TYPO3 to solve the problem.

When TYPO3 is used in this way, it's very common to share a template for the two sites. Notice the sysFolder "Skabeloner" in the bottom of the page tree. This contains a TypoScript template which is used by each "website tree". In the root of the english website for instance there is a template record ("Engelsk (placeholder forside)") which includes the common template ("Schæffergården skabelon") as a basis template. Looking in the Web>Template/Template analyser module, you'll see this hierarchy clearly:

The placeholder record is not totally empty. Rather the placeholder is the place to override the general settings from the common template to specific settings for the language of the current page tree section. For instance the english section draws its news from another archive page (pid) than does the danish. So in the "placeholder" record this alternative pid is just overridden:

Pros and cons:

By the "Two-Tree" concept you choose a simple and straight forward way to implement multiple languages. You gain a lot of freedom because you can build separate tree structures if you like, having pages in english, which are not available in danish and vice versa.

On the other hand there is no "close integration" of the two sites. Basically the customer chooses which language at entrance and he is just directed to the right page tree. And there are no "relations" between the "same" pages in each language so building a "see this page in danish" button in the bottom of pages would be a manual task!

For those who need a concept of multiple languages where there is one page tree and where language versions are available within on single page id, the new concept has been made. Works like this:

There is one page tree

There is a default language in which all pages must primarily be created

Then optionally each page in this page tree may be translated into another predefined language

There is currently no known live implementations of this principle because it's new. However it's demonstrated on the testsite which you should have downloaded so we'll go with the example there.

* Step 1: Your default language

Define which language will be the default language. All pages will primarily be created in this language. The page titles in the page tree will also be shown in this language in the backend.

In the testsite example, english is the default language.

* Step 2: Your alternative languages

You define alternative languages for your site by creating each language as a "Website Language" in the root of the page tree. These languages will be globally available in the system!

In the testsite example, Danish and German is created as default languages. They are technically identified by their "uid" numbers.

* Step 3: Create an "Alternative Page Language" record

In step 2 you defined an alternative language which would now be available for use. But you must still for each page provide a translation (of course...). The point is that all pages have content in the default language (here English) but if the website user has chosen German as his preference, then the german page content will be shown if there exist german content for the page! If no german translation exist the page content will be shown in the default language instead.

This is what you do; Go to the Web>Page module, click the page you want to translate in the page tree, finally select the "Languages" function in the function menu:

As you see the columns on the page in the default language is shown here.

Now make a new translation of this page into german:

... and then you see this form:

Here you are about to create an "Alternative Page Language" record which - as you should be able to recognize - contains fields perfectly similar to those (content oriented fields) of the actual page record of the page. The secret is that the content here will override the default content of the page record when the alternative language is shown!

* Step 4: Create page content in the new language

Back in the Web>Page module you can now create content for the new language in any of the columns.

Technical note: With the appearance of this multi language approach the content element table has got yet a field to select for - the sys_language field. So now content elements are selected based on their column and their language:

.. and as you can see in the static_templates, the TypoScript for selecting content elements has been updated as well:

* Step 5: A language selector on the website

If you take a look at the page "Backend user" for which you have just created the german language version, you'll see that the language selector menu in the bottom of the page displays the german flag (the danish is still dimmed):

Clicking the german flag, you'll get the page in german (or whatever I tried to write in german :

And this menu is inserted in the TypoScript template ("+ext: Language settings") like this:

So just dive into the php script "media/scripts/example_languageMenu.php" and check out how I did it!

* Step 6: Configure your TypoScript template to select the language

Now that you have studied the menu you have found that I use the variable "L" to indicate the language to show. At least look in the URL:

(The number "2" refers back to the uid number of the german "Website Language" record we created in step 2.)


The final thing to do now is to configure TypoScript to enable the language set by L. This is also shown in the extension template "+ext: Language settings" on the testsite:

It's very important that you do it like this, because then all the caching of templates, pages etc. will still work.

The really important setting here is "config.sys_language_uid" (Please look it up in TSref). When this is set then by total automation all system calls that select page records will automatically override the default field content with that of any present Alternative Page Language record for the given language on the page. And bang - you've got the page header, the menu etc. shown in the right language:

This will be your job to determine from this article. I believe it depends on how close you expect the languages to be woven into the pages; The two-tree concept offers freedom, but "loose control". This approach is great if you wish to put up a downscaled version of your main website in another language. The one-tree solution integrates translations seemlessly in the same pages keeping the page ids the same etc. However I believe this concept demands a pretty consistent practice of translation throughout the site to become a success.

Maybe you need some kind of hybrid between these solutions. If you feel inspired with a vision based on these models, please let me know.

May God pour sunshine upon your working week! Mondays aren't that bad when you love your job, right?

© kasper

[christian_gnoth]

Hello,
is there anything like the i18n module from Drupal - means a extension through which the content can be translated from a translation portal?
is there anyone who is working to build a extension to support the https://www.icanlocalize.com/ project?
with regards
christian

[just2b]

i use the ext llxmltranslate