We support multi-language and multi-region setups by different means in Frontastic so that you can build website for all your setups. Depending on your requirements there are different ways to implement this, with different trade-offs.

There are generally three things which can be translated or adapted to the target reagions by other means:

  • Frontastic Page Structure & Data

  • Data from external APIs (Products, Content, …)

  • User Interface strings (button captions, …)

Each Frontastic project can be multi-lingual and multi-region. But you can also use a dedicated Fromtastic project by region or language. We identify languages and regions by their locale. en_GB would stand for English - Great Britain. This is especially important for slight variantions in languages, like the differences between english in Great Britain and the USA, but also for countries using multiple languages, like Switzerland (de_CH for German, fr_CH for French and it_CH for Italian). If a project has multiple languages you should also define a default language.

Frontastic Page Structure & Data

The simplest way is to set up internationalisation in Frontastic is just a single language per project. In this case tell Frontastic to create multiple projects, with one language each. Those projects can share data using the (optionally partial) inter-project synchronozation mechanism Frontastic Supports. This synchronozation mechanism allows Frontastic to specify which data sets are synchronized. A common case, for example, is to synchronize nodes (the navigation tree) and tastics, while not synchronizing pages. Thus the general navigation tree is the same for all langauges, but you can create entirely different pages. When not synchronzing nodes even the structure can be vastly different between those projects, of course.

The other way is to use a single project with multiple langauges. This way the structure and pages are shared across all languages. You can still overwite pages for a certain language or locale, for eaxample to show a s different start pages to customers from Germany.

Bot mechanisms can be combined:

  • English Website (en_GB)

  • Swiss Website (de_CH, fr_CH, it_CH) with the same node tree as the English website, but different pages

If a single project defines multiple locales all contents of fields configured as translatable can be translated in backstage by frontend managers.

Data From External APIs

The Catwalk Backend For Frontend always determines the locale of the user based on the locale configured for the current project and the accept header sent by the users browser. For all subsequent requests this locale will be used, except the user choose a different locale manually. This mechanism can be changed and extended of course. Thus we always know which locale the current user uses.

The users current locale is passed to all API requests (ProductAPI, ContentAPI, …) and those APIs can modify queries based on that and are supposed to only return data in the current users locale.

Some APIs need even more information then language and region in the locale, which is supported by Frontastic. The system also is currency aware, which is especially important for commerce APIs, so you could use en_GB@EUR to use Euro instead of Pounds when shopping even in Great Britain.

If there is some additional logic wanted like a fallback from de_AT and de_DE to just de (because you do not want to maintain dedicated product descriptions in Austian German and German) this logic has to be implemented either in the API itself or inside the mapping in the API abstraction in Frontastic.

User Interface Strings

Translation of user interface strings and contents from backstage is documented in Internationalization in Tastics.