Using Kentico to Create Regional Multi-language Websites

By Mike Kren on June 13, 2016

Using Kentico to Create Regional Multi-language Websites
We have a number of clients whose websites have an international reach. That often means making sure the client is able to present a unified brand image regardless of the language the site is being viewed. For anyone who has done multi-market, and multilingual sites, you know what a challenge this can be.  As we approached one such project, we quickly identified creating good documentation (for us and our client) would be crucial to our success.

For reasons ranging from fine grain control over content in each region to unifying URLs (moving from domains like to so all regions are under one umbrella), we worked with one of our clients to lay out a plan that would implement individual “regional” sites. The plan included one regional site for each of their markets all based on the same designs and general site structure. One more monkey wrench: not all of their regions have a team of developers, so we would need to create documentation that would show a non-developer how to spin up an entire site with multilingual support in short order. Another requirement: They did NOT want to actually have different sites, they wanted each site to be a part of the sub-tree. Luckily, Kentico is great for this set of requirements. Challenge accepted.

Two of our team members sat down and talked about that project and what it took to put together a solution that was both flexible and easy for a non-developer to follow.

Chris: So, Mike, one does not simply start “building multiple sites using the same templates” without a plan, right?

Mike: No, when we started requirements gathering, our goal was to understand the needs of one site in one region, and then continually ask if the other markets in the same region had the same needs. When creating the pilot site, we had to keep in mind the bigger picture so our solution stayed flexible. The end goal always being to create a template the stakeholders approve of and roll that template out across the other regions, making minor modifications, as needed.  

Chris: What was an example of differences to consider?

Mike: One challenge is that not every Country has “States” on their contact form. So we had to create new Resource Strings to account for States, Regions, Provinces, etc.

Chris: How many regional sites did we end up with after all was said and done?

Mike: The region we focused on was Latin America. We started with the pilot site for Brazil, and ended up creating seven more. About mid-way through the process we invited our clients to create the next regional site and they also were able to successfully create a site on their own.

Chris: And you built one yourself, right?

Mike: Yep! I spun the whole thing up by myself. My background is not in web development, and my experience working with Kentico is definitely beginner level. However, by the creation of the second site, our dutiful and incomparable developer Chris had drafted impeccable documentation and I was able to get a site for Chile completely set up and ready for content.

Chris: Why thank you, Mike. I do have to say I appreciate the compliment and am glad you appreciate just how much work it took to take an extraordinarily complex procedure and distill down into simple enough terms for someone with your level of technical skills.

Mike:  Not only is good documentation vital for this kind of thing, but continually going through the process is great for getting new users more comfortable working with Kentico. You are following proven steps, and can always compare your work against a completed site in case you get stuck.  Chris, what are some of the more technical aspects that went into making the different sites?

Chris: Of course we relied heavily on Kentico’s Localization features to provide multilingual support but that only provides us with one translation for each given string. Like you mentioned, that becomes a problem when Brazil has states but Ecuador has provinces. Creating additional resource strings and forms isn’t difficult but we wanted to keep this as user-friendly for non-technical people as possible.

Mike: How did we achieve that flexibility to reuse as much as possible on each site?

Chris: The key was the ability to utilize custom macros within the settings on Kentico web parts. Take the contact form, for instance. Normally you drop the web part in and select a form you’ve already customized and you’re ready to go.  Instead of making the user clone the template form and then go into the web part and reselect the correct form (i.e. ContactUs_Brazil) all we have to do is use a custom macro that returns our country name in the Form Name field. In the end we have something that looks like the below:


As long as they followed the documentation and name the form correctly, the webpart will automatically grab the correct form.

Mike: If I understand correctly, you used this method in a lot of places?

Chris: Yeah, everything from Repeater paths and links to CSS List Menus and Resource Strings specific to each site. Being able to dynamically fill information that would otherwise be site-specific was the only way this works.

Mike: All that sounds pretty technical. How did you create documentation that was friendly to people who don’t have a background in development?

Chris:  Screenshots. Lots and lots of screenshots. Fortunately , Kentico’s user interface is very clean and easy to navigate so it was really no trouble to write documentation that basically said “click here, click here, change this, hit save”. I believe we ended up with about 27 pages but most of that was, again, screenshots. Visual examples can be much more useful and easier to follow than describing the location of a button in words. That included cover sheet, support info, and a worksheet to fill out to help guide them through the process.


Mike:  I think another key thing you did was to make sure the documentation was tested by a non-developer (me).

Chris:  Absolutely. Things that make sense to me may not necessarily to someone who isn’t working within  Kentico on a daily basis. You had some great suggestions for rewording things and even caught a step or two I missed. 

Mike: You wouldn’t deploy a site without thorough testing, and writing instructional documentation should be treated no differently. It is easy for a developer to get to a point where some tasks are just automatic when going through them. Having someone walk through a process that our client will also follow is crucial. It’s similar to writing a post for BizStream’s blog. A writer can get so wrapped up in their ideas and revisions, they might gloss over simple grammatical or structural errors. It’s only after they have someone else proofread it that some of those issues come to light.  

Kentico is great because it can be leveraged to address these unique client needs, without needing to build from scratch a full custom solution. This challenge is another example of why it is our CMS of choice, and why BizStream is conquering the web one (multi-lingual regional market) site at time.

Share This Post:

Twitter Pinterest Facebook Google+
Click here to read more Tutorials posts
Start a Project with Us

About the author

Mike has been managing large-scale projects for the better part of the last 11 years. His passion is bringing order to the chaos to keep everyone on the same page and the work moving forward. He has always enjoyed working as part of a team, and believes that team includes clients too. Mike loves spending time with his wife, 4 kids, and 2 dogs. He’s an avid film buff, amateur backpacker, and experimental cook, with flashes of brilliance around a pool table.

View other posts by Mike

Subscribe to Email

Enter your email address to subscribe to the BizStream Newsletter and receive updates by email.