Create branch of pages in non-default culture and not in default culture

Mike Wills asked on February 11, 2016 22:42

Hello,

I’m trying to support a scenario that looks identical to this one: http://devnet.kentico.com/questions/multiple-default-cultures

I am migrating a customer’s site from WordPress to Kentico 9. The WordPress site has separate sections (branches of pages) for different regions. However, these sections are not intended to provide translations of each other. Instead, they have completely different content, and any user should be allowed to browse it all.

This means that I’d like to setup multiple sections of a Kentico site, with each section assigned to only one culture. Here’s an example:

Site default culture: en-US

Pages	Supported culture
Root	en-US
- Page 1	(en-US)
- Page 2	(en-US)
- Page 3	(zh-CN)
- Page 4	(en-GB)
- Page 5	(en-GB)
- Page 6	(jp-JP)
-- Page A	(jp-JP)
---- Page i	(jp-JP)

Notice that many sections of the site should support a culture, without also supporting the site’s default culture. This appears to be contrary to Kentico’s design. It appears that Kentico expects all content of the site to be supported by the default culture, and then translated into secondary cultures. I’m hoping I’m missing something. The customer want’s sections of the site to be assigned a culture, so that no matter who is visiting the section of the site, the whole section is rendered using the appropriate culture (resource strings, date formatting, etc.). This means that if any user visits the Japanese section of a site, it is rendered completely in Japanese.

However, here’s what happens: If we create a section of the site in a non-default culture (e.g. Japanese), without also creating it in the default culture, a user with a non-JP browser visits a page in the section (i.e. “Page 6”, Page A, or Page i) in the example above and receives a 404 error. What the customer would like is that the user receives the content rendered using the jp-JP culture settings. How can Kentico be configured to support this?

Thank you,

Mike

kentico 9 cultures localization

Correct Answer

Jan Hermann answered on February 2, 2017 13:59

Kentico supports all 133 ISO world languages. What you are describing can happen only if a culture of the page is different than current culture or default culture and the page doesn't have its own culture-specific url.

It's not very SEO friendly if you have it set up like this (non-culture-specific url would return different than preferred/default url which is not good and could potentially lead to non-deterministic behavior -> but you can implement some custom logic for this using URLRewritingEvents), however, also in this case you can simply append a lang query string (?lang=jp-JP) to links that lead to those pages to enforce the culture.

It's always about generating a correct url of the given page, so please consider one of the following options that would solve your issue in a more proper way:

1) Turning language prefixes on: in Settings -> URLs and SEO you can turn the Use language prefix for URLs setting on which adds a language prefix to all of your pages to make their URLs culture-specific

2) Generating URLs from page names -> in the case your page names are translated to respective language as well you can tick the Settings -> URLs and SEO -> Use name path for URL path setting and then the URL will be also culture-specific, because it would be generated from its name

3) If you want to change this behavior just for those exatra pages or just to some subset of pages, you can switch to Properties -> URLs section of such a page and fill out the Path or pattern property witch some custom path to that page that also makes the url culture specific

In all described scenarios you get the jp-JP page instead of 404.

1 votesVote for this answer Unmark Correct answer

Recent Answers

Mike Wills answered on February 2, 2017 18:03

Hi Jan,

Thanks for this great information. The specific project I was on is complete, but I'll still hang on to your recommendations. I'm sure they'll be helpful at another time. In fact, I think recommendation #2 may be useful on one of my colleague's projects. The prior project was a migration project, which included a collection of blogs with different default cultures, so we had to use the pre-existing site structure, page names, and urls.

Thanks again,

Mike

0 votesVote for this answer Mark as a Correct answer