4

One of our clients is requiring that we use language-specific sub-domains instead of sub-folders on their multi-lingual site. They know all of the reasons why this shouldn't be done from an SEO perspective, but still want to go this route. Will Sitecore allow this, natively?

Conceptually, they would be looking for something like the following:

<site name="website-en" hostname="examplesite.com" 
    rootPath="/sitecore/content/sites/example site"
    startItem="/home"
    language="en"
    ... />
<site name="website-fr" hostname="fr.examplesite.com" 
    rootPath="/sitecore/content/sites/example site"
    startItem="/home"
    language="fr"
    ... />
<site name="website-es" hostname="es.examplesite.com" 
    rootPath="/sitecore/content/sites/example site"
    startItem="/home"
    language="es"
    ... />

The problem is that I am fairly certain that the above will break the SiteResolver for the Experience Editor and Preview mode. I am currently testing in 8.0.1 and while I don't see any errors, when I open EE/Preview the page always loads in the language on the current URL, rather than the language I was editing in on the previous item or in the Content Editor.

To make the Content Author's life easier, I would prefer to work around this with as little effort as possible, due to timeline. Does anyone know how I can get this to work?

  • Why do you think this will break the site resolver? I've used this setup a number of times and it works fine. – Richard Seal Nov 1 '16 at 22:32
  • @RichardSeal, you've configured multiple <site> definitions that point at the same rootPath and startItem, and only differ based on the language attribute value? I would have thought that would cause issues with the site resolver for things like Experience Editor and Preview, at the very least. – Zachary Kniebel Nov 1 '16 at 22:38
  • 1
    Yes, it works fine. For the EE/Preview my authoring sites are normally a different subdomain anyway, so it works it out based on the version of the item you have selected. Never had an issue with it before. – Richard Seal Nov 1 '16 at 22:40
  • Have you at least tried it out? Don't just guess that it might not work. Give it a go first. – Richard Seal Nov 1 '16 at 22:40
  • I did try it, but I got errors in the Experience Editor and Preview editors. The reason why I didn't want to say that it definitely happens is because I tried it on an 8.0.1 instance, and not a 8.2 instance. The EE/Preview wouldn't open in any language other than the language that I was logged in as. That would be rough on the international Content Author (having to log in for each site) – Zachary Kniebel Nov 1 '16 at 22:44
2

I think your original configuration would work OK. I have had a similar setup, albeit in sc 6.5 pre-page editor worthy sites.

So I have just tried this out on a clean install of sc8.2. I setup 3 languages, en, fr-FR and es-ES - the sites resolve as you would expect them to.

When logged into the Content Editor, if I select a language, fr-FR for the home item and then click the Experience Editor button, it opens the page up with the French language version selected.

Also, once in the Experience Editor, you can click the Versions tab and change the language from there.

Here are some screen shots to demo that:

Select the language in the Content Editor Experience Editor opens in the selected language Change the language in the Experience Editor

The same things worked for the preview mode.

| improve this answer | |
2

While the approach in the OP will work, the one problem that you will encounter is that the Content Author will have to log into the same site that they wish to edit if they want to use the Experience Editor or Preview mode without changing the language version being edited every time they go to a page.

To avoid this, you could instead configure a single site and customize the way that Sitecore generates links and resolves the requested language to support the language sub-domains.

Site Configuration

The first thing that you will need to do is configure the site's hostname to match against the domain and the language sub-domains. To do this, you will want the hostname of the <site> config node to be a regular expression. As such, the <site> config node should look something like the below:

<site name="website" hostname="(www.)?((en|fr|es).)?examplesite.com" 
    rootPath="/sitecore/content/sites/example site"
    startItem="/home"
    language="en"
    ... />

Generating Language-Specific Links

You will need to write a custom LinkProvider in order to generate the correct language-specific links for your page items. Your extended LinkProvider will need to append the appropriate sub-domain, based on the language. You could also include support for excluding the sub-domain if the language requested is the same as the site's default language.

Resolving the Correct Language

Lastly, you will need to write a custom LanguageResolver in order to set the correct Context.Language, based on the present (or absence of a) language-specific sub-domain. Remember to make your LanguageResolver default to the default language, if no language sub-domain is present.

| improve this answer | |
  • 1
    This looks like a very clean way of implementing the requirement. I think a single site definition makes much more sense if you are going to translate a single content tree. It's very common to programatically derive the site from an item, and with multiple site definitions that becomes complicated. – Dylan McCurry Nov 2 '16 at 15:51
2

You can definitely run into trouble with this if you have any code or modules that attempt to resolve the site definition based on the current item (rather than the Site in context).

For example, you might have a custom workflow action which loads a configuration from the site definition. Since the action executes in the context of the 'shell' site, it needs to use the item going through workflow to determine the site. In your case, the item would resolve to multiple site definitions.

You'll need to make sure that any such logic that you have also takes into account the language of the item version in order to find a 'best' match.

Additionally, you'll likely need to enforce embedded language codes to redirect to your other site definitions. For example, you don't want users to see french content by travelling to 'example.com/fr'. You'll need to make sure that redirects to 'fr.example.com' to ensure your site resolves correctly.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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