Learn from Our Language Fallback Experience
6 novembre 2017 • 9 Minute Read • Elizabeth Spranzani, Chef de la direction technologique
In my recent posts I have talked about how Sitecore provides an out-of-the-box with version 8.1+ to support Language Fallback, an overview of Language Fallback, a how-to on configuration, and the questions you should be asking for your strategy.
Just knowing what questions you should be asking is half the battle! But I'm sure you would love a little insight into what some of the answers to those questions would be. Although every scenario is different, I can at least try to give you some guidance based on my own experience and callout some good-to-know gotchas.
Sitecore Content Strategy
There is only one shell site (the Sitecore Content Editor) where you can enable fallback.
- What this means: If some of your sites fallback and some don't, and you continue to only use one shell site, you may see fallback in the content editor for sites that won't actually fallback on the front-end.
The fallback language for each language can only be set at the entire Sitecore Instance level.
- What this means: All your sites in the instance will need to adhere to the same fallback chains.
You can use both item-level and field-level fallback in the same site and even on the same item, if you'd like.
- What this means: You get the benefit of not having to create extra versions for items if you don't have a translation but ALSO can have the granular ability to only translate certain fields and not others if you do decide to create the language version. HOWEVER, you also will lose the ability to Enforce Version Presence.
- When in doubt, use Field fallback, it is ultimately far more flexible.
Enforce Version Presence necessitates the existence of the language version
- What this means: There is no point in using Item-Level fallback, which only works if no version exists, with Enforce Version Presence.
If you enforce version presence on an item, it means you must add a version in a language to make it exist in that language.
- What this means: You don't want to enforce it if you don't have to, since it will force you create a lot more versions of items. Every language version needs to be published and indexed, and depending on the number of items you have, that can start to take significant time.
- Generally speaking, only enforce version presence on page templates and assume if the page exists, then all the modules and media on it should be served up. Don't enforce it on media, data templates, modules/callouts, etc.
If you select to use item-level fallback and NOT to use field-level fallback, you will have to set the content for ALL fields on that item, none will fallback anymore.
- What this means: you want to use only Item Fallback on content that you know you will always be translating all the non-shared fields.
- A perfect example is the Dictionary Entries template, there is only one non-shared field. Therefore out-of-the-box Sitecore has enabled Item-Level fallback on this template.
'Versioned' field level fallback means that you will create additional language versions of your templates and turn fallback on and off for each item and template at a language level (German falls back, Spanish does not) as an exception to whatever you set site-wide.
- What this means: Overly complicated fallback strategy, that I've personally never found a reason to use, AND can have performance implications. It is unlikely you ever need to do this.
If a value is set into the Standard Values field of your template, that means whenever an item is created from that template, the field will be EXPLICITLY SET with that value (or the dynamic value of the token like $name).
- What this means: Fallback won't be used on these fields! The value will be explicitly set on all your language versions and therefore fallback will be overridden! Now if the user updates this field on the English version (for example), the German version won't also be updated, because it is no longer falling back, it will have whatever that first value was. You would have to go in and update it on each language version OR reset that field on those language versions to null so it falls back.
- Therefore, if you don't want this to happen, don't set any values into the standard values on fields you want to fallback!
Always plan for your Sitecore sites to be 'Translation-Ready', even if you aren't sure you won't need a translation.
- What this means: Don't output static text ANYWHERE in your code or files. Always use the Dictionary. Therefore, if the situation comes up, you will be ready and won't need to touch code. You also get the added benefit of that authors being able to change that content on their own.
Sitecore by default stored media as UnVersioned templates. And if you change this configuration to be Versionable templates, it will only affect NEW media that is added, media already in the library will stay Unversioned.
- What this means: UnVersioned Media templates share all fields across languages and that means you can't have different media files uploaded for the same media item for different languages. And if you decide later you don't like this and want to version it, you will have to write a script that goes through all of your media and changes the template. This is not only extra effort, but could open the door to user error on a massive scale.
System fields and standard values items cannot be set to fallback.
- What this means: The Display Name field is a standard field. If you were intending to use it as the URL of the page, then you will need to make sure to set it on every single language version!
With a small customization to the item created pipeline, we can automatically create all language versions set for a site when an item is created.
- What this means: Your content authors won't forget to add the other language versions and end up with no content on the site in those other languages. They can decide to remove a language version if it shouldn't exist in that language. It makes their lives easier!
Sitecore Search Strategy:
Items with item-level fallback will be added to search index for every language that is set to fallback. Items with only field-level fallback will NOT be added to the index if the language version is not there EVEN IF ENFORCE VERSION PRESENCE IS NOT TURNED ON.
- What this means: With field level fallback, the crawler will not save the fallback English content into the German index. So even if the user can SEE the English content on the German version of the website (because we aren't enforcing version presence), if they search for it, it will not show up in the results.
- You will have to add the German language version to the item to make it get included in the index. BUT if you add item-level fallback as well, it will get indexed in that scenario.
- This is a good reason why you might want to consider both. Remember, the more language versions you have to have, the harder the publisher and indexer have to work.
Internationalization Strategy:
Fallback is only between one language version of an item to another language version of the same item.
- What this means: if you want to share that content across country sites, having a single site node that uses fallback is the path of least resistance. Otherwise you might need to consider putting that content in a global area or cloning it, and that can lead to a lot of extra work (developmental as well as authoring) and headaches (ugh, presentation on shared items is not fun!)
Use the 90% Rule to decide if you want to use the same site node for your country versions of your site.
- What this means: if 90% of the architecture, presentation, and functionality should be the same across all countries/languages of the site, then use a single site in Sitecore with language versions added for each piece of content.
- If you start to see requirements for different presentation and more importantly different site map architecture and functionality, start to seriously consider different site nodes. Perhaps you don't have to break it out for every language but just certain ones or groups.
- Avoid code exceptions based on country/language and too much presentation deviation across language versions!
Tool to consider: Verndale's Language Reporting Tool, available in the Sitecore marketplace now:
- This will allow you to visually see what your Sitecore tree looks like for different languages, by allowing you to filter it by languages that exist for each item, and specifying if fallback qualifies or not with that.
Consider using a default global language (like ‘en’) that all other languages fall back to, when using Language Fallback. This default language would not be used publicly on the front-end of the website.
- What this means: From the start, even with just one language, you are using fallback and have worked out the kinks and processes that content authors will need to follow for additional languages. All the languages that are being used for the front-end are treated ‘equally’ with the same content author experience.
Country-specific domains are powerful!
- What this means: You may want to consider buying domains (or keeping them if you have them already) that are specific to the country your site represents. If you decide to do that, it is easy for Sitecore to point those different domains at the SAME site node in the content tree and just define a different default language. And then you may not need to embed language in your URL at all.
Changing your domain strategy after the fact is not easy.
- What this means: You will need to set up 301 permanent redirects for every single URL on your site and make sure the search engines are aware of it. It is time intensive and not always easy.
Google Translate is just machine translation.
- What this means: The translation is going to be wrong, don't use this!
Translation Service Partners are important if you don't have someone on staff to do the translations.
- What this means: You most likely need to package up the content and send it off to the partner to translate it and then they will send it back to you. Exporting and important that content into Sitecore could be a big manual headache for your authors. And building something to do it for you from scratch will be EXPENSIVE.
- Therefore, you should either pick a partner that has a Sitecore Connector already (GPI or translation.com) or leverage a middle man broker (Clay Tablet).
A Clay Tablet will be more expensive if they must build a connection to a Translation partner that they haven't integrated with yet.
- What this means: If you don't already have a translation partner in mind, then ask Clay Tablet who they would recommend and go with one of those options.
Forcing a user to a country site because of where they are currently is frustrating to them typically, especially if their network IP isn't even accurately providing their country. Educating them in an unobtrusive but noticeable way that there might be a country site more applicable to them for your organization, would be very helpful.
- What this means: Sign up for Sitecore's geolocation service through Maxmind, geo-locate your users and design a nice experience for them. Make it easy for them to switch between country sites.
Cookie laws are strict in Europe and the US won't be far behind.
- What this means: You must factor in designing and building functionality to make users aware that you use cookies and obtain their consent to do so, potentially for EACH individual cookie.
Personal Data must be stored within the user's current country for some countries./p>
- What this means: Additional server costs and customizations to your Sitecore implementation. Find out asap if this affects you.
Some regions such as Quebec require businesses operating there to provide their website content in a specific language
- What this means: You WILL get dinged if you don't follow this (we have a client that was called out!), and you'll have to get that language added to your site and translated asap. If this affects you, don't procrastinate and put it in place from the start.
EU General Data Protection Regulation (GDPR): after four years of preparation and debate the GDPR was finally approved by the EU Parliament on 14 April 2016. It will enter in force 20 days after its publication in the EU Official Journal and will be directly application in all members states two years after this date. Enforcement date: 25 May 2018 - at which time those organizations in non-compliance will face heavy fines.
- What this means: We need to give users a way to opt out of anything Personally Identifiable. Sitecore will be releasing with Sitecore 9 a way for us to do that. Stay tuned!