By Cathy Dew
An Overview of Cultures
We spent the last month discussing Cultures and implementing Multilanguage support in Kentico. If you want a refresher, please visit our Extending Your Website’s Reach series:
Kentico provides you the ability to serve up content based upon the browser’s selected Country and Language code. The ISO has standardized the available Country Codes (ISO 3166-1) and Language codes (ISO 639-1), and the browser and Kentico developers have integrated these codes into the base software so that language options, when setup, can be determined and displayed within the browser. Because the identification and assignment of codes is done by ISO, the internet as a whole, has a trusted source to work with to match codes to languages and countries.
However, that means if you’ve decided to create a custom culture or language pairing, the new code is not going to mean anything to your visitor unless they also make the same update. Which is unlikely since the user would need to update their operating system configuration to get the new custom language–country code pairing.
That said, even within the limited scope a custom language–country code paring provides, it can be useful to us to create custom code pairings to support a scenario we see all the time with our clients’ content delivery challenges.
Problem Description: Global Untranslated Content – Shared Translated Content – Local Only Content
When running an internal or external web site that is using a Multi-Lingual / Multi-Cultural configuration, you can divide up your content into three groups:
-
Globally Shared – Untranslated Content
-
Globally Shared – Translated Content
-
Local Content only, in the language of the requested culture
This paradigm works great for all content except content that lives in the “default culture”. You’ll remember that the primary step when setting up a Multi-Lingual site is deciding upon which culture will be the default. And with that decision, Kentico will show the content assigned to the default culture when no culture / translation is offered for that content. With alternate cultures, you can create pages and content that only lives within the that culture. However, you cannot do this with the default culture. If Page A only lives within the default culture, it is fully visible to all other active cultures and even findable via search. If you want to make that content available only within the default culture and not for alternate cultures you cannot do this directly out-of-the box with Kentico.
But what if you created a Custom Culture and assigned that as the default culture?
Custom Culture – A Possible Solution?
There are several options available to solve this problem, some of them require the building of custom events to assist Kentico with the decision of showing a page to the visitor. But what about building a custom culture to use as the default culture? As outlined earlier, the Browser gets the Language-Culture code pairing from the operating system and then gives that to the web server, via HTTP headers, with every request. Kentico understands all the current Language-Culture code pairings, but in order to use them correctly (you can’t just create a custom culture solely within Kentico) the pairing also needs to live within the server’s operating system.
We’ve been experimenting with building a custom culture within the web server operating system, then linking that to a newly created culture within Kentico, and declaring the custom culture as the default culture for the Kentico web site.
This setup solves the loop hole of local only content displaying across all cultures, because those pages would never exist in the default culture. And using the custom culture as the default culture means the custom culture doesn’t need to exist on the requesting browser’s operating system because, as the default, it doesn’t matter what the visitor is asking for, this content will be provided no matter what.
Then all “Globally Shared – Untranslated Content” will have to live within the new custom culture.
There are, of course, several drawbacks to utilizing a custom culture as the default culture. One of them is the default culture provides the primary structure of the web site that all the alternate cultures hang off of. While a page can only exist within the alternate culture, an editor specific to a culture won’t see the page as untranslated and utilize that page as a starting point when appropriate. Therefore, “Globally Shared – Translated Content” that should be related and served from the same Document/Page Object will exist across multiple Document/Page Objects.
This can be mitigated by declaring one of the alternate cultures to be a “Starting Culture” where all “Globally Shared – Translated Content” needs to start from, and translation of that content can be kicked off, but that is a procedural issue and not something that Kentico can assist with tracking because it’s expecting all content to originate from the default culture. (Translation workflows will still function, it’s more about losing the visual assistance that Kentico provides to see if pages are targets for translation.)
One alternate path is to load all “Globally Shared – Translated Content” into the default culture and do not translate the content for the culture that would normally be the default culture. While you can then utilize Kentico to track translation needs, you will always see one culture as needing translation.
Conclusion
Kentico is a powerful CMS and its multi-language setup is one of the best designs on the market. Even so, the design structure has a few minor short comings when it comes to controlling the display of content for the default culture. Additionally, Kentico is also a very strong development platform and you can build very complex custom solutions using Kentico.
The challenge with customizations is that they need to live within the Kentico ecosystem in a way that doesn’t prevent future upgrades and therefore avoids changes to core features that could get a rewrite for future versions. So, making a change to how Kentico works with serving up alternate cultures on demand is an area one needs to tread lightly.
But what if you take the current multi-culture functionality and slightly change the dynamic? By adding in a custom culture (which only exists for the web server & Kentico and not for the visitor) as the default culture, we can expand the types of content that is displayed (or not) to the visitor without making core changes to Kentico itself. And such a “change” should be upgrade proof.
As we mentioned, 2Plus2 is experimenting with these changes with our clients that are serving multi-culture content to their visitors. We’ll report back in another post later with our results.
2Plus2 is a Kentico Gold Partner and would love to help you get the most out of your Kentico system. Go online to schedule a free consultation with our team or call 510-652-7700 today.