We had started the sitecore development in the Version 8.1 update 3 using Habitat.

There are plan to have localization more localization in feature. In this what will be the best option for creating localization.

  1. Can we create a new language in the same node for localization.


  1. Can we create a separate node for localization.

What is the pros and cons between these option.


  • There might be changes in the layout between the locales(hope this is sorted in the shared and final version)

  • Some pages will not be required between locales Example : page 1 is applicable for US locale and Page 2 is applicable for UK locale.

1 Answer 1


Both practices are valid. In the years I've been doing this; I think it's likely split 60/40 or so between the two approaches - with in-place versioning coming up slightly over the split content trees.

To summarise; these are the points to consider when deciding one approach over the other.

  1. Will there be major differences between multiple language versions of the site?
    • It's important to remember here (and often overlooked early on): Language != Country. Often content will vary from country (market) to country, but German as an example, will be used in Germany, Austria and Switzerland.
    • Make sure to separate the language versus market discussion early on
  2. Will the people working on the site for one market, be the same as for all other markets?
    • Sitecore security settings apply on Item level. If you want different groups of editors with restricted access to only the parts of the site related to their specific market, this calls for a split content tree.
    • If on the other hand, it will be one and the same Center of Excellence working with the site globally, this speaks in favour of a unified content tree (but again - only if they are largely similar)
  3. Are you expecting to use Language Fallback facilities? if so; only the unified tree really makes sense.

There is no real "right" answer here. I find that separate trees per site/language/market is more intuitive and easier to understand for content editors. However, given largely similar language versions, it also often is a preferred option to just have the one content tree and manage versions - be mindful that this approach requires more training and care.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.