Updated on May 5, 2017.
The goal of this post is to discuss different scenarios that come into play when people start discussing using multiple languages on a website. I'm going to be addressing this from the perspective of using the DNN platform, or its commercial cousin EVOQ, but most of these scenarios exist regardless of platform. This post is about exploring the business use-cases more than technical solutions. People often start talking about multilingual content in a very generic way without realizing that it can be applied to many different types of solutions.
First Thing: Multilingual is NOT the Same as Multi-Country
One of the first things you should establish when planning for your project is whether the goal is to deploy content in multiple languages for users in the same country, or in different countries or both. Let's explore a couple of different options:
Multilingual Content with No Geographic Distinctions
Whether your audience is all in the same country or not, there may be a need to provide the content in multiple languages. In a perfect world, the content would be exactly the same from language to language. Examples: Canadian web sites often provide content in both English and French. Likewise, a site for a Chinese audience might offer content in Mandarin and Cantonese. In both of these examples it is likely that the information that needs to be communicated in each language is largely the same.
A similar, but different situation is a site that serves a global audience in multiple languages - without making any distinctions on the geographic location of the user. In this case the site serves exactly (or nearly) the same content to all users, just translated into different languages. In this example, English speakers in UK, Australia, and the USA, all receive the same English content, regardless of the fact that they live in different corners of the world.
Serving Distinct Content to Users in Different Countries
Sometimes it is important for a global organization to present specialized content to users dependent on their geographic location. In this scenario, we are often talking about the creation and management of two or more distinct web sites, or portals. For example, a company that serves markets in the U.S. and in the U.K. might need to present very different information to the audiences of each country, and the differences are great enough where it makes sense to deploy a distinct web site for each. Or perhaps a company serves markets in both the U.S. and Germany, in which case it might need two different websites, each in a different language and each with different content.
Now that we've cleared up the difference between multilingual and multi-country, let's look at some of the scenarios come up under the general heading of "our website needs to be multilingual."
Scenario: One Country, One Portal, Multiple Languages
For this scenario, let's use as an example a Chicago hospital that serves both English and Spanish speaking customers. The hospital has decided that its new website should should serve content in both languages, with English being the main language, and most of the content having a Spanish translation available.
DNN and EVOQ handle this scenario very well via the content localization feature (introduced in DNN version 5.2). Content localization lets content administrators translate all pages and content, and includes support for localized meta data as well, Going further, page settings and module settings can be set differently for different languages if need be. In the event that not all content can be translated, there are appropriate controls for deciding whether to show the content in the default language, or to hide it. That being said, this approach works best when the general goal is translate all of a site's content into multiple languages. If a site's content and structure needs to greatly change as languages are switched, then it might be best to create different DNN/EVOQ portals for each language (see the next scenario).
This approach works well when:
- You want to keep your content mostly in "lock step" between languages, meaning that most of your content will be translated into all the languages you plan to enable.
- Your want to keep the design consistent between languages, and the design can accommodate both languages (sometimes navigation design gets thrown off when the translated words have more letters than the language for which the design was created).
- Your site management is centralized and there won't be future situations where a team that manages content for one of the languages wants/needs to change the site's structure or content in ways that won't make sense for the other language.
Scenario: An Organization Has a Presence in Different Countries ...
... And each country has divergent web presentation needs ... OR, each country has a marketing team that can't (or won't) arrive at a common site architecture, even though the functional requirements are the same. In this case, each country/language essentially need its own site distinct site map. While you could try to accomplish this objective through the use of DotNetNuke/EVOQ localized content, this is NOT a good idea. It could work because the localized content feature allows you to specify whole pages as being enabled only for one language, but in practice this becomes very cumbersome to manage. It is MUCH easier to simply create a separate portal for each country/language. In this event, it easy to specify the default language for each portal, and language packs are also readily available and easy to install in most languages. Note that this applies to both the DNN platform and EVOQ, which share the same core language handling functionality.
This approach works well when:
- The content or site structure needs vary considerably from language to language, and it makes sense to conceptualize each language as having its own site instead sharing a common site.
- Because the site will be administrated through disparate organizations (marketing departments on different continents) it will be easier and more efficient to manage each language as a separate site rather than to try and "get and stay on the same page."
- The languages may have similar needs today, but it can be foreseen that they their needs will evolve differently over time, such that it makes sense to give each language its own portal.
Scenario: A Global Organization Has Disparate Groups for Marketing and IT...
... And getting everyone to "sing from the same sheet of music" is simply not possible, or will be too slow of a process. In the extreme, this means that it can be challenging for the groups to select common web platform software and hosting systems. The best outcome here, in my opinion, is that one group successfully pioneers the adoption of a new platform,and the others jump on the band wagon after seeing proven results. If the pioneers used DotNetNuke or EVOQ, the late-adopters could potentially be given a portal on the pioneer's original DNN installation. Failing that, the modular architecture of DNN still allows for code reuse across installations, so any custom skins or modules that were created for the pioneers can be easily shared with the late-comers if it makes sense to do so.
This approach is for you if:
- Your organization is far flung with redundant marketing and IT groups that have their own internal goals and time lines, and finding a common web platform is simply not a mandate.
- One group tends to be the technology trail blazer, with the others willing to follow if they can see tangible benefit.
Well, that's all I can think of at this time. Let me know if you have come across multilingual scenarios that I haven't covered. And finally, if your organization needs help deploying multilingual sites or sites for multiple countries, please let us know if we can help.