Planning Variation Configurations

Now that you are familiar with the concepts of the variation system and some big-picture planning considerations, you need to determine the options to take when configuring your variation hierarchy.

Configuring the Variation System

Figure 4-1 illustrates configuration choices on the behavior of variations discussed in this section.

Figure 4-1: Variation process settings

Six planning decisions that are global to the variation system of the site collection must be made on this page:

• Variation Home

• Automatic Creation

• Recreate Deleted Target Page

• Update Target Page Web Parts

• Notification

• Resources

Variation Home

All variations must share a common root within the site collection. This root can be at any level, but the variations must all be at an equal level just below the root. This becomes a very important planning issue because users normally never see the root site of the hierarchy.

Once a site is designated as the root of the variation hierarchy, the default page is changed to a special page, variationroot.aspx, which contains the redirection logic to detect the browser language or mobile setting and redirect to the appropriate site. This decision cannot be changed later without completely rebuilding the variation hierarchy. This can be the root of a site collection or any location lower in the site collection tree. This home site should not be used for content other than the redirecting page and the default reusable content libraries because users will not normally access this site. This site can be a publishing site or a publishing and collaboration site. Other subsites of this variation home can still be used normally. To specify the root of a site collection, type a slash (/) in the dialog box (as shown in Figure 4-1).

Automatic Creation

Do you want content to be created on targets automatically or manually? Manual publishing allows the content editors and administrators of the source variation to control what is pushed to the target site or sites. Automatic publishing pushes all published content with a matching content type to all target sites. In both instances, however, the target site administrator or workflow approvers can reject content or modify the publication of content.

The moving of content can be configured to be either manual or automatic when publishing. Your business needs will drive this decision. If you select the Do Not Automatically Create Site And Page Variations option, you need to trigger the process manually or with a schedule.

To initiate the manual variation process, complete the following steps:

1. From the Action menu, select Manage Site Content And Structure.

2. The shortcut menu of the published object in the source variation contains the option to initiate a new variation as shown in Figure 4-2. For a site, select New, and then select Site Variation. For a page, select New Page Variation.

3. In the dialog box that opens, select the variation target and the name and location for the object in the target. While the automatic operation uses the same name on target variations as is used in the source variation, with the manual process you can use different names and URLs on each target and still maintain the variation relationships with the source.

Figure 4-2: Manually initiating a new variation object

Recreate Deleted Target Page

If the administrator of a target site decides that content is not needed on the target, she can choose not to publish it and to delete it. The default action, should the source content be republished due to content publication date changes, is to push the content to the target again. You can choose not to overwrite target choices. This option applies only to content that was deleted at the target site.

Update Target Page Web Parts

Do you want to overwrite Web Parts on target pages with those on source pages? A major consideration here is that Web Parts might need to be customized or rewritten for the language of the site where they are being used. These customizations and personalizations are lost when the Web Parts are overwritten by the variation system.

Notification

Do you want the variation system to notify the owners of the target site of any changes, or do you want to depend on the workflow process of the site? If a subsite is created, an e-mail message is sent to the owner of the parent subsite in which the new subsite is created. If a target page is updated as a result of a change made to its source variation, a message is sent to the owner of the site in which the page list exists.

Resources

Do you want the reusable content (resources) in the new pages to be links to centralized resources? You can choose whether the new page variations contain a link to the resources used in the original page or get a copy of the resources in the new page. Like all instances of links to resources, this choice permits changes in a single location to be instantly reflected throughout the sites. However, in a multilanguage scenario, the target owners might want to replace the content with pictures more appropriate for their audience or translated re-useable content.

Designating Source and Target Sites with Variation Labels

Next, you create a label for each site in the set of variations, including one that you designate as the source. Every other site becomes a target by default. Be careful here!

Important 

There is no method for correcting your choice once you create the variation hierarchy.

To create a variation label, open the Create Variation Label page shown in Figure 4-3.

Figure 4-3: Configuring variation labels

There are several planning issues involved with creating variation labels. Consider each before creating the variation label. You'll need the information to complete each of the following sections on the Create Variation Label page:

• Label Name This unique name serves to identify the label in the database and in management tools, but it also identifies the site in the URL. It should be short but identify the language and the locale. For instance, to identify US English, you can use the standard language name abbreviation, ENU, or the language ID, 1033. Because users will rarely be typing this value, the value should be useful to administrators and support personnel.

• Label Description Normally exposed only in the management tools, this text box is used to further clarify the purpose of the site.

• Display Name Because the display name is used by both the Master Pages and the Navigation controls as the name of the site, it should be a short but descriptive name.

• Site Template Language The language selected represents the language ID, and the language ID determines the language that is used to display text and interpret text that is input on the site. This language selection determines the language pack templates and resources to use in creating the site. More than one site can reference the same language ID. SharePoint will support 36 languages at its release.

• Locale These settings reflect languages and cultural conventions as they are used in different parts of the world. These variations can occur within languages, such as "English US" and "English UK". The Locale ID controls the numbering, currency, sorting, calendar, and time formatting for the Web site. Locales expand the languages supported by SharePoint. SharePoint supports 135 separate locales. Although the language cannot be changed later, the locale can be changed by the site administrator in Site Settings. However, it cannot be changed in this interface.

  Best Practices 

  Determine the language support you might need for your farm and establish a standard naming convention based on industry standards. For example, English might not be sufficiently distinctive because your farm could have 13 different English language sites serving the various English locales supported.

• Hierarchy Creation The three options here control only what portions of the source variation site will be used to create the target site initially:

  q	Publishing sites and all pages This option specifies the entire site, including subsites and pages. This includes copying reusable content used in existing pages if the variation rules specify copying this content. However, if the reusable content of the source site is contained in nondefault document libraries, the containers must be manually created with the same names on the target sites before the content can be copied. Publishing sites are created at the target label using the site templates of the language specified for the label. The default content of the site is whatever is specified in the template, including the empty  Default.aspx file for the sites. Therefore, if the source label has a customized  Default.aspx file, the customizations of that page will not appear in the target variation until it has been modified again at the source or manually pushed to the target. Nondefault pages at the source will be pushed to the target as a separate operation once the site is created. Lists, document libraries, Web Parts, and features that have been created or activated on the source but that are not defined in the site template will not be created on the target.
  q	Publishing sites only The content of the source variation is not pushed to this target variation; only the publishing sites that exist on the source are created on the target. These sites are created according to the site definition contained in the corresponding site template of the language specified for the target or label. New content pages or modified content pages will be pushed to the target, as they are published at the source variation. Existing pages at the source can be manually pushed to the target later.
  q	Root site only Only the root site will be created at the target variation according to the site definition contained in the corresponding site template of the language specified for the target or label. Existing pages will not be pushed to the target variation. This selection is useful when creating a custom variation target that requires only certain subsites of a source variation. For example, the source variation contains subsite A, subsite B, and subsite C, but the variation needs only the tree structures of subsite A and subsite B. By selecting Root Site Only and then manually creating a site variation at this target for subsites A and B, all content (existing and newly published) will be pushed to the target. No content from source subsite C will be pushed to the target because no variation relationship exists for that subsite and this target. Other target variations for this variation system can be configured differently.

• Source Variation There can be only one source variation per hierarchy and only one variation hierarchy per site collection. Once this selection is made and the hierarchy is constructed, it cannot be changed without completely removing the hierarchy and reconstructing it. Only the source variation site presents the option to select the site template, and your choices are publishing the site with or without workflow. By default, only publishing sites can be created under this site. If you add collaboration features to a site or subsite, these features will not be copied by the variation system to target sites.

Important 

Of the choices available on this page, only the Display Name and the Description can be modified in this interface once the variation hierarchy is built. The locale can be modified in the Site Settings by the site administrator.

Building Sites with the Variation Hierarchy

Click the Create Hierarchies button shown in Figure 4-4 and SharePoint Server 2007 will build sites in the appropriate language with the template you chose. Because the source site is created as a new site during this process, you can choose to build the hierarchy with only the source variation label defined. This option permits you to complete the basic structure of your source site, test it, and obtain approval from your stakeholders before adding variation targets.

Figure 4-4: Managing the variation hierarchy

The variation hierarchy can be modified by adding or removing variation labels at any time. After you create the new Variation Label, click Create Hierarchies to create the new sites from the current source label.

Propagating Content from Source to Target Sites

Based on the choices you made on the page shown in Figure 4-4, when content is published in the source site, a variation of the content will be created in all targets. Depending on the workflow settings of those sites, the content will be published immediately, a workflow will be initiated first, or the content publishing will wait for a manual workflow to be started. With auto-replication enabled, the delay should not be more than one minute for moving the pages to the other variation sites.

Only publishing content published on the source site is pushed to the targets. Publishing content will include any sub-sites created on the source site which have the publishing feature activated. This publishing feature is available for activation on all sites created in SharePoint Server 2007 but is not activated by default on sites designed primarily for collaboration. If the publishing feature is activated on a sub-site, that site will be created on the appropriate target sites and any publishing content of the site will be pushed to the target(s).

Also, the site templates available by default for creating sub-sites of publishing sites are Publishing Site with Workflow and Publishing Site. Additional sites can be exposed in the Create Site page by adding them as follows: select Site Settings, then open the Page Layouts & Template Settings page of the root site of the Variation hierarchy.

Managing Variation Sites

Target sites are managed separately, with different users in the roles for the sites. What do the targets sites have in common? They have a Site Collection hosting the variation hierarchy, a root site that is redirecting traffic, Content Types, and content that is accepted by the other target sites. There are some issues to be managed either proactively or reactively.

Customize Web Parts for Variation Sites

Most Web Parts are not designed to be variation-aware, and for many types of Web Parts this is not an issue. Other Web Parts become dysfunctional if copied from one site to another. For example, the list Web Parts always reference lists using the site-level globally unique identifier (GUID), which is not modified when the Web Part is copied from one site to another. You can choose the option to not copy Web Parts as part of the variation system. Unfortunately, this is a global choice for all Web Parts, and you can't select it only for certain types of Web Parts.

Custom Web Parts can be written to be variation-aware in that they contain the logic to reset information and content during the variation process.

Managing Corrections

By default, the variation system cannot distinguish between a minor correction to a page and a major revision. It only recognizes that there is now a new major version published that needs to be copied to all target sites. By default, there is no process available to notify the target site administrator that the change consists only of a corrected spelling of a word in the source language, which has probably already been corrected during the translation process.

A solution is needed to avoid the unnecessary retranslation of pages. One solution is to create a custom Boolean column for the page content type that will be used by the content editors on the source site to mark new versions as "local corrections" not requiring republishing on target sites. On the target sites, a custom workflow is developed to check every new publishing page for that column and delete new pages where the attribute is set to True.

Customizing Search for Variation Sites

To enable users to conduct searches in their own languages, you can create a Search Center with Tabs site in the source site that will then be re-created in the target sites in the appropriate language. Or, target site administrators can individually create a Search Center on their site. You might then choose to hide the default search center. Your developer can modify the master page to remove the search box that appears on each page or simply redirect the advanced link to the local search center's advanced search page.

Note 

The Search Center template does not have publishing feature activated and therefore will not be pushed by the Variation process. The Search Center with Tabs does include publishing features and is pushed by the Variation process.

You might also need to set up different search scopes for your variation sites to limit the search to specific Language-Country IDs (LCIDs). Alternatively, your developer might be able to add special search criteria for languages on a custom search query. See Chapter 16, "Enterprise Search and Indexing Architecture and Administration," for more information on configuring search and on the resources provided to facilitate search and indexing in multilanguage scenarios.

Removing Variation Hierarchy and Sites

If you remove a site from the variation hierarchy, the following will be true:

• The site will no longer reflect any additions or changes made to the source variation.

• The site remains a fully functional site but must be accessed through normal navigation, as it is no longer listed in the redirection scheme.

• You cannot re-establish the site within the variation hierarchy because you have deleted the variation label. New variation labels cannot be pointed to established sites.

• If you delete the label for the source variation, the remaining sites still function and the redirection functions for all sites except the source. However, you cannot designate a new source variation, and any subsequent changes must be made manually at each site. There is a warning that you are deleting the source variation.

Removing a Site

To remove a site from the variation hierarchy, complete the following steps:

1. On the Site Actions menu choose Site Settings, Modify All Site Settings.

2. In the Site Collection Administration column, open Variation Labels page and in the drop-down menu for selected site's Label select Delete. You must confirm the deletion.

Removing a Variation Hierarchy

To remove the entire variation hierarchy, complete the following steps:

1. In the Site Collection Administration column, open the Variation Labels page, and delete all variation labels.

2. In the Site Collection Administration column, open theVariation Settings page, remove the root site designation and click OK. All sites now function independently.

Removing Redirection Functionality

To remove the redirection functionality, complete the following steps:

1. In Internet Explorer, enter the full URL for the root site including the name of the welcome page file in the URL. Normally, the Welcome page would be  default.aspx.

2. From the Site Actions page, choose Site Settings, Modify All Site Settings, and then click Welcome Page in the Look and Feel column.

3. Reset the Welcome page to a page other than the Variationroot.aspx. You can delete or hide the Variationroot.aspx.

Note 

Any site in the variation hierarchy cannot be deleted until the corresponding variation label has been deleted. Deleting the variation label does not remove the site or its content.