Loading content for a new language/geographic region


What is the usual process for loading content for a new language/geographic region?

We have a website that contains content for 3 geographic regions. Each region presents in English, but we use languages to make variations in content for each region. We wish to load content for another English language geographic region. All content changes are made directly in the live website environment.

If we just turn on the new language, then it will show on the website in the region selector dropdown, and pages will show immediately on publish. We want to enable the language to enable content entry, but not allow the new region to show on the website until all content is loaded.

It seems this would be a business as usual process for any global website with regional content. What is the usual approach?

Edited, Mar 07, 2018 7:27
  1. Projects is a good option if you want to prepare much content that should later be published at once.
  2. Simply saving content but avoid publishing the correct should do as well 
  3. If I recall correctly (might be wrong) you can enable the editor to create the new translated pages in edit mode but disable the language in admin mode to hide from users?
  4. Talk to the developer that built your language selector if none of the above works 
Mar 23, 2018 20:15

Thanks for your response Daniel.

Our developer is doing additional coding to achieve option 3 that you suggested. Does anyone know if that shoudl required special coding? Or is it a normal feature on episerver?

Our developer is also then going to use projects to allow us to build the content and publish in batch.

Is using languages the recommended way to handle content that varies by country/region? We have several countries but they all speak English.

Would we have been better to use personalisation (by geographic region) to make country specific content?

Mar 26, 2018 5:42

To enable and disable languages is standard functionality but the language selector on your site is custom made so that might still show the language depending how it was coded. That might require code change.

Setting the new language versions to unpublished status makes sense if it shouldn't yet be available to users. Using projects too since it's a batch of content that you need to prepare and publish at the same time.

Using language branches/visitor groups/separate tree structure depends on how different the sites are from each other? That's a good question really. Here is my opinion:

  1. Use visitor groups if you only have a few places where you want to show different content. This option is the fastest for the editor but also the most limited. It's not intended for creating a new site for a new market. It's intended for presenting a slightly better flavor of the content to the current visitor. Using it too much might get messy for editors.
  2. Use language versions if you will have approximately the same content in the same structure for the different countries. Advantage is that you can easily compare content between languages and translate easier. 
  3. Use different tree structure per country if you think they will have different kinds of content in another structure to a large degree. Gives most freedom but takes longer time to create content for and you will lose advantage of comparing language versions.
Mar 26, 2018 9:10

Thanks for the information Daniel. Our situation is probably either scenario 1 or 2.

We have the same tree globally and most pages are the same everywhere. However, there are some cases we may might want to change a specific block on a page, and occassionally the full page.

  • Support page for country A
  • Support page for country B

What varies by country is pages relating to products sold in each country, and news/event pages. For example:

  • Oranges - sold in country A
  • Apples - sold in country B
  • Bananas - sold in both A and B
  • Carrots - sold in both A and B, but need to provide slightly different conten
Mar 29, 2018 7:23