Comparing the difference between Multilingual and Multi-Country DNN Guide Multilingual and Multi-Country Sites Whether you a new DNN user or a big company looking to take your business or company global by expanding your business or targeting other countries, you most likely most have thought of making your website more flexible. Flexibility in this sense refers to having multi-language sites that enhance your product and service sales or having multi-country portals in the case of organizations. This is where a DNN website has a superpower for your business. We all know that DNN is a content management system that enables programmers or users to build unique websites effortlessly and based on your business needs and specifications. When building a website, you most likely would consider making it available in different languages, available globally, and also available based on country. In this post, we would discuss different cases or scenarios that are very important when talking about multi-languages on your website. But before we delve into that we must establish the difference between multilingual sites and multi-country portals. Comparing Your Options and Solutions The Difference Between Multilingual and Multi-Country One thing is sure; multilingual is not the same as multi-country. This must be taken into consideration when planning and building your dotnetnuke website for your project, business, or organization. The first case is to serve Multilingual content without any geographical distinction. Multilingual Content With no Geographical Distinction: This means you are making your site accessible in multiple languages in one country or globally. Take, for instance, you are offering a product or service in China knowing full well that there are different languages in China. You can make the content of your site available in both Mandarin and Cantonese. This also applies globally in that you provide the site in multi-languages while delivering the content in the same manner to everyone. For example, you can deliver the same English content to English-speaking users in the UK, US, Australia, etc. They all receive English content regardless of their geographical affiliations. Multi-country content for different countries: This is another instance different from the first one. In this instance, your company offers different content based on the country. For example, if you are delivering a service to both the UK and the US but the service caters to totally different industries within these countries or they present different information and audiences, it is more appropriate to make available two different websites or portals. This means that content is been dispatched or sent based on geographical location. Multi-country and Multilingual: The last instance is a bit of a mix between the first two instances. In this case, your company might be delivering services to two different markets in two different countries. For example, you are delivering services to markets in Germany and the US with different audiences; in this instance, you would provide two different websites or portals with different languages for their content. Now that we have cleared the air about Multi-country and Multilingual content, let us take a drive into how DNN can work in different scenarios or case studies. Scenario 1. One Multi-Lingual Portal for One Country A good example of this scenario is a Chicago clinic that offers services to both English and Spanish speaking clients. The clinic can create one website that serves content in both English and Spanish but English being the main language. In this case, the content would also have Spanish translation available on the website. This type of scenario is handled in DNN using the Content Localization feature which was introduced from DNN version 5.2 upward. This feature allows content administrators to translate all pages while including support for localized Metadata. Furthermore, this feature allows for page settings and module settings to be set differently for different languages if there be a need for it. If in a case that some content cannot be translated, some features decide if the default language should be displayed or if it should be hidden. If there is a great change in the content and structure of the site as the language changes, then you should consider creating a different DNN portal for each language – we'd look into this in the next scenario. Scenario 2. Company with a Global Presence In this scenario, maybe your company operates at a global level and you have different teams for each country. You can set up different marketing teams in each country that would set up their local websites and content. This might be because of the different requirements as regards location, feel, content, and look of the website as it relates to their clients locally. In this scenario, the company center or mother company would be responsible for giving an appropriate sitemap for all other sites under the company’s jurisdiction making their sites multi-country. Although this can be handled using DNN, the maintenance of it can be a little tricky along the way. The best approach for this is to create different portals for each country and specify the default language based on the country for each portal. If there is any need for the inclusion of a different language along the line, then language packs are readily available for easy and quick installation. Scenario 3. Company with Teams Operating in Different Countries This is quite an extreme case in which you have teams within your organization that have different views and portfolios in different countries. In this case, the Main Company or Mother Company can make use of DNN services. For instance, you have a marketing team and IT team that simply can't select a common web platform or hosting system. The best way to go about this is to allow one team pioneer the adoption of their system successfully on a new platform while the others jump on the bandwagon on seeing successful results. If you made use of a DNN service, getting the latter on board can be as easy as giving them a portal on the original DNN installation. In the case of failure, DNN still allows for code reuse across your DNN installations. Clarity Ventures DNN Experts Other DNN Articles & Resources Comparing DotNetNuke to Other CMSs How to Install DNN (DotNetNuke) How to Select and Screen a DNN Developer DNN Website Basics DNN Hosting Recommendations How to Create a DNN Portal Top 5 Reasons to Update Your DNN Site DNN Evoq vs. Evoq Content Implementing jQuery within Your DNN Website DNN Content Staging and Content Workflows Common DNN Errors and Solutions Guide to Content Approval Workflows in DNN DNN Enterprise Infrastructure Environment Advanced Site Search and Indexing Guide to Granular Permissions and Security Access Website Security and Hardening Best Practices DotNetNuke Forums and Community Centric Plugins DotNetNuke Mobile Responsive Website Design Multi-Site / Multi-Domain Best Practices DNN Module Development Best Practices Harnessing the Power of DNN Forms Selecting a DNN Upgrade Specialist Comparing Evoq Platform vs Evoq Content Easy Optimizations for your DNN Site How to Choose a Right DNN Hosting Package DNN Guide to Azure Hosting and Configuration DotNetNuke Caching and Performance Tuning Guide Building Blogging Website with DNN eCommerce for DNN DNN Catalog, Payment, and Subscription Modules Understanding the DNN Database Creating Custom DNN Plugins and Widgets DNN Developers ADA and WCAG Compliance for DNN Utilizing Document Management Within DNN Enterprise Distributed Load Balancing Guide DotNetNuke Enterprise SharePoint Integration DNN Environment Configuration Guide Integrating Google Analytics and Tag Manager with DNN Website Health Monitoring and Logging DNN Guide Multi Portal CSS Switching DNN Permission-based Content Display Website Personalization and Tracking Consent DNN Theme Development Best Practices DNN Multi-Lingual / Multi-Country Portals DNN Upgrade Best Practices Guide to Mobile Responsive Skins for DNN The Relationship Between C# and DNN
Scenario 1. One Multi-Lingual Portal for One Country A good example of this scenario is a Chicago clinic that offers services to both English and Spanish speaking clients. The clinic can create one website that serves content in both English and Spanish but English being the main language. In this case, the content would also have Spanish translation available on the website. This type of scenario is handled in DNN using the Content Localization feature which was introduced from DNN version 5.2 upward. This feature allows content administrators to translate all pages while including support for localized Metadata. Furthermore, this feature allows for page settings and module settings to be set differently for different languages if there be a need for it. If in a case that some content cannot be translated, some features decide if the default language should be displayed or if it should be hidden. If there is a great change in the content and structure of the site as the language changes, then you should consider creating a different DNN portal for each language – we'd look into this in the next scenario.
Scenario 2. Company with a Global Presence In this scenario, maybe your company operates at a global level and you have different teams for each country. You can set up different marketing teams in each country that would set up their local websites and content. This might be because of the different requirements as regards location, feel, content, and look of the website as it relates to their clients locally. In this scenario, the company center or mother company would be responsible for giving an appropriate sitemap for all other sites under the company’s jurisdiction making their sites multi-country. Although this can be handled using DNN, the maintenance of it can be a little tricky along the way. The best approach for this is to create different portals for each country and specify the default language based on the country for each portal. If there is any need for the inclusion of a different language along the line, then language packs are readily available for easy and quick installation.
Scenario 3. Company with Teams Operating in Different Countries This is quite an extreme case in which you have teams within your organization that have different views and portfolios in different countries. In this case, the Main Company or Mother Company can make use of DNN services. For instance, you have a marketing team and IT team that simply can't select a common web platform or hosting system. The best way to go about this is to allow one team pioneer the adoption of their system successfully on a new platform while the others jump on the bandwagon on seeing successful results. If you made use of a DNN service, getting the latter on board can be as easy as giving them a portal on the original DNN installation. In the case of failure, DNN still allows for code reuse across your DNN installations.