SDL Tridion BluePrint and Translation

This article explains SDL Tridion BluePrint in relation to Translation and possible approaches.
Note: If you are not familiar with SDL Tridion BluePrint,
perhaps you should think about getting support from someone that does.
In the long term, you will find that it was worth every cent.
Background
SDL Tridion offers the possibility of managing translations in a quite easy way. BluePrint feature provides the basis for Translation and possible integration with translation management systems.
As a natural consequence, you should make sure that you think about translations when creating the BluePrint Design.
Otherwise, later on, you may have to redesign your BluePrint, or work around your original BluePrint. The redesign and work around may be even more complex, if you plan to integrate with translation management systems, such as TMS or WorldServer.
Standard Approaches
A typical scenario in a SDL Tridion implementation is websites in multiple countries or markets and multiple languages. In this article, we use this scenario to illustrate the possible solutions.
The scenario assumes that:
·         You have common content, web pages and website structure, in the solutions referred as Global. This needs to be translated in multiple languages.
·         You have Local market or country content, web pages and website structure which need to be available in multiple language websites. A very neutral example is the Swiss websites. The websites need to be available in Italian German and French. Local content, web pages and website structure are created in German and should be available in Italian and French.
Classic BluePrint Solution
The classic BluePrint solution proposes setting 3 translation layers:
·         Global Components: all common (Global) components are created in one single language (typically in English) in 200 Global Content (EN) publication and gets localized and translated to other languages in a  300 Translation (Language n) publications (e.g. 300 Translation FR publication for French, 300 Translation ES publication for Spanish, …)
·         Global Pages & Structure Groups: all common (Global) pages and structure groups to all the websites are created in one single language (typically English) in 400 Web Site Parent (EN) publication. Those items get localized and translated to other languages in each of the  500 Web Site Parent (Language n) publications (e.g. 500 Web Site Parent FR for French, 500 Web Site Parent ES for Spanish, …)
·         Local Country/Market Components, Pages & Structure Groups: all Local components, pages and structure group are created in one single language (typically the main country/market language) in 600 www.company.xx (yy) publication, where xx is the country code domain and yy is the corresponding language code. Items get localized and translated in the 700 www.company.xx (zz) publication, where zz is the corresponding language code for the website. For example in Switzerland, the 600 www.company.ch (de) publication is where local items are created in German, and translated into Italian and French in the 700 www.company.ch (it) and 700 www.company.ch (fr) publications respectively.
The diagram below shows this generic example.
Note: You can tell this is a classic BluePrint by the vintage icons on the diagram.

Optimized Classic BluePrint Solution
The three translation layers of the classic BluePrint solution can be reduced to two layers. This can be done by:
·         Managing all translatable content in components in 200 Global Content (EN) publication.
·         Manage web page title and metadata in components in 200 Global Content (EN) publication.
·         Manage Navigation, breadcrumbs and sitemap titles as content in 200 Global Content (EN) publication.
If you do this, you can remove the level 5 of the Classic BluePrint solution. This aligns with the concept of Minimizing Localizations.

BluePrint and Translation Management Systems
BluePrint is the basis for the integration with translation management systems.
SDL Tridion BluePrint has Parent-Child relation between publications; for example, 200 Global Content (EN) is the parent publication and the 300 Translation FR is the child publication.
Translation management systems have language pairs; for example, the language pair EN>FR means that the translation should be done from the Source language English to the Target language French.
In conclusion, as long as we can map a Parent Publication to a Source Language and a Child Publication to a Target Language, we should be on the safe side for the integration of SDL Tridion and translation management systems.

In our classic BluePrint solution example, we have two global Source publications, 200 Global Content (EN) and 400 Web Site Parent (EN); each with their own Target publications, 300 Translation (Language n) and 500 Web Site Parent (Language n).
For each country/market publication in Level 6, we may need to set its own language pairs. For the Swiss country/market example, the 600 www.company.ch (de) publication will be used as the Source publication in German. Publications 700 www.company.ch (it) and 700 www.company.ch (fr) are the target publications for Italian and French translation of the Swiss local items. Keep in mind that German to Italian (DE>IT) and German to French (DE>FR) define language pairs in the translation management system.

1 comment:

  1. I've seen the manage-in-020 Global Content approach also useful for channel-specific scenarios as wells. Rather than a separate mobile/organization/sub-Global shared content publication it makes sense to push these components up, especially if they hahve little-to-no localization and authors are centralized.

    Would the catch then be a new publication needed later for localization? Otherwise we'd need to localize at a website or website parent (which includes structure, making it impossible to just share that content elsewhere).

    Beyond the BluePrint document, do you typically set up the "if we need these later" publications early on and hide them? Or do you find organizations just save the option for later. Personally I've seen both but wasn't sure if there was a "rule."

    Of course child content publications would be easier to add than parent structure group publications.

    ReplyDelete