Thoughts about Building Multilingual Publishing Site on SharePoint 2013 - Part 2 of 3

This is a second part of the series describing my experience in planning and building a multilingual WCM site on SharePoint 2013.

Part 1 discusses basic requirements and architecture of the authoring site.
This part focuses on managed navigation for the authoring site.
Part 3 discusses cross-site publishing and publishing sites.

Term Set Organization

SharePoint 2013 Managed Navigation is at the heart of our solution. We have defined a global term set containing the navigation hierarchy. The terms at the top level correspond to the items at the top navigation bar of the site:

So there is no single root or parent term for the global navigation term set, rather - there are several top-level terms. It is important to note that every single page needs to have a corresponding term in the term set pointing at it:

Next, on the Site Settings >> Navigation configuration page we set the managed navigation to point at the global navigation term set for the source variation label. The root site of the site collection is still using structured navigation. This site is not going to be exposed publicly and is logically above the top level the Internet users will see.

Terms Sharing (Reuse)

When variations are created by clicking on Site Settings >> Variation Labels >> Create Hierarchies  the background job will automatically create site collection-scoped term sets and re-use the terms from the source term set to the target term sets. Going forward, when an information worker publishes a new page to the source variation label, the Variations Propagate Page Job Definition background job would propagate the page, and if the page is pointed at by a term, it will re-use this term from the target variations site (Term reuse scenario A). If a page is published first and propagated to target variations, and a term pointing at it is created at a later time, then the term will not be reused on target variations and would need to be manually reused by selecting Reuse Terms option on the parent term of the term to be reused.

Terms can also be reused by manually pinning top-level terms instead of relying on the variations propagation job. In this case, the terms created automatically by variations can be removed.  Next, terms from the source term set can be pinned along with the children using the Pin Term With Children menu option on the term set used for the target variation label's navigation top-level (Term reuse scenario B). The advantage of scenario B over scenario A is that regardless of when a page is published and propagated, the term will always get reused. The advantage of scenario A is that only terms for published pages get reused, which may better align with a publishing business process. The good thing is that you can mix both scenarios in a single term set as they are term-specific.

Terms Translation

In order to translate a term you need to change a value of current language in the Language drop-down box on a GENERAL tab, and enter a translated value for the Default Label. Regardless of which term set you do it on (global term set, the one for the en-CA label site or the one for the fr-CA label site), it updates the source term's value, i.e. the one belonging to the global term set. Below is an example of translating a term to Russian:

There is an interesting side effect of term translation. If a term is translated prior to being reused (scenario A) or pinned (scenario B) then the managed URL of the propagated page is created based on the translated label. Here is an example of how this looks for a Russian variation label:

The fix is easy: selecting the Customize check box does it. In case of the scenario B, the friendly URL to a page in a target variation will return 404, since Target Page Settings on a TERM-DRIVEN PAGES tab for the target term are not defined. The URL of the target page needs to be entered manually.

So as you might have noticed, terms connected via pinning or term reuse share certain properties, such as Default Label, which can only be changed in one place - on the source term, while you are allowed to independently customize term-driven pages settings. This opens up a possibility of having locale-specific URLs, especially in languages utilizing Latin alphabet: a page in source variation could have one term-driven URL, and a replica of the page in the target variation could have a completely different term-driven URL. This improves readability of the site and supports SEO.

On our project we  went ahead with the Scenario A, assuming our information workers would get training to make the following logical workflow happen:

1. The user creates a page in source variation;
2. The user creates a term in global term set;
3. The user points a term at the new page;
4. The page undergoes approval process and gets published.
5. Variations Propagate Page Job Definition timer job picks up the page and creates a replica in target variations. It also reuses the term pointing at the page, and correctly points reused term(s) at the page's replica(s).
6. The term can be translated now without a harm to the term-driven URLs.
7. User can optionally change the term-driven page URLs for the target variations' pages.

Should the workflow not be followed for whatever reason, the terms can always be manually reused, and incorrectly translated URLs fixed as shown above.

Search Indexing and Managed Navigation

I have noticed that a term needs to have either the Show in Global Navigation Menu  or the Show in Current Navigation Menu checkbox checked (or both of them) in order for the search to be able to index the page corresponding to the term. If the term is neither on global nor on current navigation, and Hide physical URLs from search field is set to True for the corresponding page, then the page will not get indexed. For the pages we did not want on the navigation, but still needed to be in the index we were able to workaround this behavior by selecting the Show in Current Navigation Menu checkbox, but using a page layout that does not render a current navigation control.

Global versus Local Term Sets

One last note about using the global term set. We could have used a site collection-scoped term set (aka local term set) instead. The strategy was to keep all terms used for navigation in one place and then reuse them. Even for the purpose of cross-site publishing it is not necessary to have a global term set. Still we have chosen a global term set on the basis of a "why not?" approach. It gave us greater flexibility and eliminated potential issues having to do with local scope.