Implementing Multiple Languages in SharePoint 2010
Two Approaches
There are two separate approaches that can be used when implementing multiple languages for a SharePoint site. The first is titled Multilingual User Interface (MUI) and there is just one site for all languages and only some of the content will be translated. The second option is titled Variations and each source site in the default language has a separate site for each language that you would like to display. There are pros and cons to both methods and they are laid out after the jump.
It should be noted that in neither approach will entail the user supplied content of the site be translated automatically. Regardless of the method chosen, it will require a resource to translate the content to the alternate languages.
Languages Available
Before you even begin, you must confirm that the languages that you wish to display the site as are supported. If you are looking for Pirate or Wookiee, then you are out of luck. For a list of languages available, click this link for a full table: http://technet.microsoft.com/en-us/library/ff464197.aspx
Installing Language Packs
In order to install a SharePoint language packs, you must first install the language on the server operating system and then install the SharePoint language pack. This process will need to be repeated on all servers in the farm. For the full detailed steps on this process, follow this link:http://technet.microsoft.com/en-us/library/cc262108.aspx
Multilingual User Interface (MUI)
The first option is titled Multilingual User Interface (MUI). This method involves a single SharePoint site for all of the languages that the user can decide which language to view the site.
PROS
- Ability to have separate navigation text, site titles, site descriptions, list titles, and column display texts displayed based on the language chosen by the end user. These alternate text needs to be supplied by an administrator as the translation doesn’t happen automatically.
CONS
- Requires publishing so therefore requires SharePoint Server and not just SharePoint Foundation.
- There is only one version of the content of the page and therefore the main part of the content pages can only be displayed in one language regardless of the language selected by the end user.
HOW TO CONFIGURE
To implement MUI, you first need to install the SharePoint language packs for the languages you wish to support on all the servers in your SharePoint farm. After this is completed, you need to go to the site settings for the site that you wish to implement this for. After the language packs have been installed, you will see an option for ‘Language Settings’ under ‘Site Administration’.
From here you will be able choose which alternate languages you would like to provide as choices for your end users. I have only installed Spanish but you will see choices for all the languages that you have installed.
This will then provide links for your end users to select which language they would like to see the site in. These links can be found by clicking on the welcome current user control.
Variations
PROS
- Variations give you the ability to have separate SharePoint publishing sites for different languages and therefore the entire site can be converted to that particular language. Just like with MUI, the translation is not automatic and will require a resource to translate the content.
- SharePoint timer jobs are used to create new sites for the selected languages and copy content from the source to the target sites.
- When users navigate to a site, they will be redirected to the language (if implemented) their internet browser is set to.
- Email notifications can be set up to notify users when changes have been made and translations need to be updated.
- When the variation page timer job runs and updates, the target site (alternate language) will be updated with the source site’s (default language) content. In my example, this will mean that when the default English page is updating the target Spanish page will have English content copied into (over the existing Spanish content) until the translating resource goes in and translates the content. However, the copied content will come in as a draft version of the page and will need to be translated and published before it is visible to the end users.
- Translators have the ability to see what has changed in the versions using an intuitive interface.
CONS
- Requires publishing so therefore requires SharePoint Server and not just SharePoint Foundation.
- The variations feature will only copy publishing pages that are stored in the Pages library of the source site. Any images and documents referenced will still point to the location at the source site. Lists and libraries will also not be copied.
- When setting up the variations labels, the source site and the target sites must be one level below the root site in the site collection. However sub sites from the source site will be synced to sub sites of the target sites.
- A site can only be a source site or a target site, not both. This means that if you have source English-US site and a target Spanish-Mexico site, you cannot have the Spanish-Mexico site also be the source for the Spanish-Spain site. You can however have the English-US site be the source site for both the Spanish-Mexico and Spanish-Spain sites.
HOW TO CONFIGURE
If the languages packs have been installed, the variations configuration settings can be found in the site settings of the root site of the site collection. There are three links to configure the variations are ‘Variations’ and ‘Variations Labels’. The ‘Variations Logs’ link will display the actions taken by the various Variations timer jobs.
First click the ‘Variations’ link to configure how you would like variations to be handled in your site collection. You are presented with various options such as would you like to automatically create the sites and if you would like the content to be automatically updated.
Then click on the ‘Variations Labels’ link to establish the site mappings between the languages. You have to establish the source site and the target sites for all of the languages you would like to support.
References
How to get all Variation Labels for SharePoint Site
While working with SharePoint Publishing sites we usually encounter use of Variations, and sometimes we want to work with them programmatically since Variations are the result of the SharePoint Publishing Infrastructure, so of course we need to use SharePoint Publishing APIs...
Using Microsoft.SharePoint.Publishing it is possible to use a simple single line of code to get variation labels programmatically.
ReadOnlyCollection<VariationLabel> _all = Variations.Current.UserAccessibleLabels;
The method above returns a read only collection of VariationLabels for the site, but wait...
This method returns the list of labels only when the variation site hierarchy for a label is created successfully and if a requesting user has permission to access the variation site but sometimes you might need to get all variation labels for a site even if you don't have access to those sites or when the variation hierarchy of the site is not created successfully.
Well then here is something that I found when I looked in our buddy the reflector.
In the SharePoint platform most things are in lists, where its OOB or while you do your development, and that is the case with Variations.
SharePoint internally maintains a hidden list where all of these variations are kept, does that sound good?
So the approach is fairly simple; you just need to get the list and query and that's all.
Here is sample code
Note : VariationLabelEntity is custom entity class
Reference: Waldek Mastykarz
class Program{
private static SPList _variationsList = null;
private static DataTable _allLabels = null;
private static List<VariationLabelEntity> _varLabels = null;
Using Microsoft.SharePoint.Publishing it is possible to use a simple single line of code to get variation labels programmatically.
ReadOnlyCollection<VariationLabel> _all = Variations.Current.UserAccessibleLabels;
The method above returns a read only collection of VariationLabels for the site, but wait...
This method returns the list of labels only when the variation site hierarchy for a label is created successfully and if a requesting user has permission to access the variation site but sometimes you might need to get all variation labels for a site even if you don't have access to those sites or when the variation hierarchy of the site is not created successfully.
Well then here is something that I found when I looked in our buddy the reflector.
In the SharePoint platform most things are in lists, where its OOB or while you do your development, and that is the case with Variations.
SharePoint internally maintains a hidden list where all of these variations are kept, does that sound good?
So the approach is fairly simple; you just need to get the list and query and that's all.
Here is sample code
Note : VariationLabelEntity is custom entity class
Reference: Waldek Mastykarz
class Program{
private static SPList _variationsList = null;
private static DataTable _allLabels = null;
private static List<VariationLabelEntity> _varLabels = null;
static void Main(string[] args)
{
try {
using (SPSite site = new SPSite("http://YourSite"))
{
using (SPWeb web = site.RootWeb)
{
if (PublishingWeb.IsPublishingWeb(web))
{
string _listIdString = web.AllProperties["_VarLabelsListId"].ToString();
{
try {
using (SPSite site = new SPSite("http://YourSite"))
{
using (SPWeb web = site.RootWeb)
{
if (PublishingWeb.IsPublishingWeb(web))
{
string _listIdString = web.AllProperties["_VarLabelsListId"].ToString();
if (!string.IsNullOrEmpty(_listIdString))
{
Guid _listId = new Guid(_listIdString);
{
Guid _listId = new Guid(_listIdString);
_variationsList = web.Lists[_listId];
if (_variationsList != null)
{
SPQuery query = new SPQuery();
query.Query = @"<Where><IsNotNull><FieldRef Name='Title' /></IsNotNull></Where>";
query.ViewFields = "<FieldRef Name='Title'/><FieldRef Name='Language' /><FieldRef Name='Locale' /><FieldRef Name='Top_x0020_Web_x0020_URL' />";
{
SPQuery query = new SPQuery();
query.Query = @"<Where><IsNotNull><FieldRef Name='Title' /></IsNotNull></Where>";
query.ViewFields = "<FieldRef Name='Title'/><FieldRef Name='Language' /><FieldRef Name='Locale' /><FieldRef Name='Top_x0020_Web_x0020_URL' />";
_allLabels = _variationsList.GetItems(query).GetDataTable();
}
}
if (_allLabels != null)
{
_varLabels = new List<VariationLabelEntity>();
foreach (DataRow row in _allLabels.Rows)
{
string _topWebUrl = row["Top_x0020_Web_x0020_URL"].ToString();
string[] _splits = null;
if (_topWebUrl.Contains(','))
{
_splits = _topWebUrl.Split(',');
_topWebUrl = _splits[0];
}
{
_varLabels = new List<VariationLabelEntity>();
foreach (DataRow row in _allLabels.Rows)
{
string _topWebUrl = row["Top_x0020_Web_x0020_URL"].ToString();
string[] _splits = null;
if (_topWebUrl.Contains(','))
{
_splits = _topWebUrl.Split(',');
_topWebUrl = _splits[0];
}
_varLabels.Add(new VariationLabelEntity {
Label = row["Title"].ToString(),
Language = row["Language"].ToString(),
Locale = row["Locale"].ToString(),
TopWebUrl = _topWebUrl,
});
}
}
Label = row["Title"].ToString(),
Language = row["Language"].ToString(),
Locale = row["Locale"].ToString(),
TopWebUrl = _topWebUrl,
});
}
}
if (_varLabels != null && _varLabels.Count > 0)
{
foreach (VariationLabelEntity label in _varLabels)
{
Console.WriteLine(label.Label + ".." + label.Language + ".." + label.Locale + ".." + label.TopWebUrl);
}
}
}
}
}
}
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
{
foreach (VariationLabelEntity label in _varLabels)
{
Console.WriteLine(label.Label + ".." + label.Language + ".." + label.Locale + ".." + label.TopWebUrl);
}
}
}
}
}
}
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
Console.ReadLine();
} }
} }
public class VariationLabelEntity{
public string Label
{ get; set; }
public string Label
{ get; set; }
public string TopWebUrl
{ get; set; }
{ get; set; }
public string Language
{ get; set; }
{ get; set; }
public string Locale
{ get; set; }}
{ get; set; }}
No comments:
Post a Comment