Language packs only translate the default SharePoint functionality. Your own lists, content types, fields, etc.. are not translated. Since SharePoint 2010 there is an option in SharePoint to translate elements in the user interface and export them. This export can then be imported again on another server. In my case this is mainly between development, test and production machines (DEV, TST, PRD)

The following items can be translated

• Website title and description
• List title and description
• Contenttype name and description
• Field name and description
  • field names are also used in the columns of your lists
• …

How to enable?

• First you need to install the SharePoint Server language packs for the desired language(s)
  • Note: since SharePoint 2013 you do not need to install the “Foundation language packs”  anymore on a SharePoint Server
• After the language pack is installed. Go to site (Site Settings -> Language Settings)
  
• Enable the desired languages (in my sample: French and Dutch)
  
• To translate, sign-in with a user with the correct language set and start changing the titles, descriptions by using the default SharePoint interface.
  • you can set the user language by simply setting the browser language
  • or overrule the browser setting by editing the language settings in the user profile (User Profile is the new name of the “mySite”)
• When all the translations are done go to Site Settings- > “Export Translations”  (or  ”Import Translations”)
  
• Select the desired options to create an export file (which is actually an XML based resource file (.resx))
  
• Save the file on your harddrive
• Repeat the above step on your target server but now you select “Import Translations”

Note:  for easier testing/validating I always use 2 users with a different language setting. One user I sign-in while using the Google Chrome browser. With the other user I sign-in while using IE browser.

It’s all about the ids!

It’s important to know that the  translation seems to work with the ID of your SharePoint elements. This means that if you want to use this translations functionality, the id’s of your lists , websites, contentypes, fields, etc.. on both environments (source and target) must be the same!

So what will not work?
If you create your SharePoint elements manually in both ( source and target) environments. All the elements will have different id’s. The translation will not happen.

What will work.

• If you have deployed your content types and fields with a SharePoint solution.  On every server where you deploy this solution the id’s of the content types and fields will be the same. You can translate them on one server and bring the translation over to another server.
• If you build your sites on one server, create a content backup of this and restore the backup on another server.
  • The restore will use the same id’s on the target server.
  • Note: If you delete for example a list on the target server and manually recreate it it will not be translated anymore since the new list has a new id (even if you used the same name etc..)

How do I use it?

I always deploy my content types and fields with a SharePoint solution. This way all the ids stay the same on every server (DEV, TST, PRD) where the solution is installed. I do not bother with translating them in my (Visual Studio) SharePoint solution.

Why do I do this? Two main reasons:  my experience is that names of content types and fields get changed a lot during the development process. Often even the day before going live.  The other reason is that I find it too complex to manage resource files for n amount of languages in Visual Studio. I prefer that the content editors do the translations for me.

We simply build the other items (lists, websites, ….) on a dedicated web application and do a backup / restore from this to DEV, TST and even PRD. This is very workable in a development situation. When your solution is alive and kicking in PRD, the restore to PRD is not an option anymore of course.

On the personal site (user profile) users are able to create new tasks assigned to themselves. However when looking at the site content there is no tasklist to be found.

Turns out that the tasks in the User Profile are stored in a hidden list on the user profile site. The tasks are not even stored as a task contenttype.

Where is it stored?

The list where the user profile tasks are stored is called: ‘WmaAggregatorList_User‘. You can access it by using the default server model (have not tried client model yet)

using (SPSite site = new SPSite("http://my.wingtip.com/personal/administrator/"))
{
   using (SPWeb web = site.OpenWeb())
   {
      SPList list = web.Lists["WmaAggregatorList_User"];

      foreach (SPListItem item in list.Items)
      {
         Console.WriteLine(String.Format("{0} - {1}",item.ContentTypeId, item.Title));
      }
   }
}

The special contenttype

But there is more. Look at the contenttypeId of those items: ‘0x0056568DFBB054A24E9CD75205760A1195‘
It does not resemble the typical contenttypeId layout that we are used to. A content type always starts with ’0×01′ (=item) from which ,normally, all other contant types inherit. It seems that this is a special one.

For you reference here is a list with the default contenttypeId prefixes

The contenttype fields

Here is also a reference to all the fields included in this special ‘item’ contentype

How do you add a custom control to your master page (or page layout) using the Design manager? In my first attempts I continuously got ‘Unknown server tag ‘uc1:FeedbackControl’

Quick introduction

Using the new way of creating and deploying your branding with the Design Manager needs some getting used to. The idea is:

1. You start with a plain html page
2. SharePoint automatically converts it to a master page (or layout page)
3. You only edit the html page. SharePoint pushes your changes to the master page
4. Most of the SharePoint controls and web parts can be configured and added by copy + pasting snippets into your html
5. .NET server controls can also be placed on your page by using snippets.

In fact snippets is nothing more than a special kind of mark-up to put server controls in your html page.

But how to you add a custom control?
I created my branding with the Design Manager. I also have a Visual Studio 2012 solution with custom web parts and custom user controls.
After deploying the Visual Studio solution to my server I tried to add some of my custom user controls to the master page.  All attempts I made resulted in “Unknown server tag”

Defining your control.

<!--SPM:<%@ Register Src="~/_controltemplates/15/AmToPm.Client.Intranet/FeedbackControl.ascx" TagPrefix="uc1" TagName="FeedbackControl" %>-->

Putting your control on your page.

<!--CS: Start Create Snippets From Custom ASP.NET Markup Snippet-->
<!--SPM:<uc1:FeedbackControl runat="server" id="FeedbackControl" />-->
<!--CE: End Create Snippets From Custom ASP.NET Markup Snippet-->

The solution

The trick is easy. Instead of registering your control on top of the html together with all the default SharePoint controls. You need to put the @Register statement and your code together

<!--SPM:<%@ Register Src="~/_controltemplates/15/AmToPm.Client.Intranet/FeedbackControl.ascx" TagPrefix="uc1" TagName="FeedbackControl" %>-->
<!--CS: Start Create Snippets From Custom ASP.NET Markup Snippet-->
<!--SPM:<uc1:FeedbackControl runat="server" id="FeedbackControl" />-->
<!--CE: End Create Snippets From Custom ASP.NET Markup Snippet-->

So you do NOT place the @Register-statement before the DOCTYPE declaration. Embed it directly into your html page together with your snippet.

One other tip.

I had some problems / errors with defining multiple controls with the same tag prefix. If you have multiple controls on a page give them all a different TagPrefix and you will be fine.

<!--SPM:<%@ Register Src="~/_controltemplates/15/AmToPm.Client.Intranet/FeedbackControl.ascx" TagPrefix="uc1" TagName="FeedbackControl" %>-->
<!--SPM:<%@ Register Src="~/_controltemplates/15/AmToPm.Client.Intranet/Notification.ascx" TagPrefix="uc2" TagName="Notification" %>-->
<!--SPM:<%@ Register Src="~/_controltemplates/15/AmToPm.Client.Intranet/DisplayStatus.ascx" TagPrefix="uc3" TagName="DisplayStatus" %>-->
<!--CS: Start Create Snippets From Custom ASP.NET Markup Snippet-->
<!--SPM:<uc1:FeedbackControl runat="server" id="FeedbackControl1" />-->
<!--SPM:<uc2:Notification runat="server" id="Notification1" />-->
<!--SPM:<uc3:DisplayStatus runat="server" id="DisplayStatus1" />-->
<!--CE: End Create Snippets From Custom ASP.NET Markup Snippet-->

.NET 4.0 has a new gac location

Today, I wanted to quickly update a dll from a custom SharePoint solution. I was baffled when I could not find the dll in the assembly ( “c:\windows\assembly ” ) folder.

Turns out that starting from .NET 4.0 and up there is a new ‘GAC’ folder in town. It is now located in “c:\windows\microsoft.net\assembly“. You can simply browse to that directory with Windows Explorer and view all the folders.  The new GAC folder does not hide version information (=folders) anymore like the old one did.

They introduced this new folder to avoid issues between CLR 2.0 and CLR 4.0 , the GAC is now split into private GAC’s for each runtime.  The main change is that CLR v2.0 applications now cannot see CLR v4.0 assemblies in the GAC.

So keep in mind there are two folder now. One for .NET versions 2.0, 3.0, 3.5 and one for .NET versions 4.0 and up.

For more information on installing dlls in GAC
http://msdn.microsoft.com/en-us/library/dkkx7f79.aspx

More information about the GAC
http://msdn.microsoft.com/en-us/magazine/dd727509.aspx

Unfortunately the plugin is not yet updated for Visual Studio 2012 / SharePoint 2013.  But the people at Mavention have created a small tool that mimics the “Copy to GAC” functionality. So it takes at least some of the pain away.

Read all the details on Weldak’s blog:
http://blog.mastykarz.nl/quickly-deploying-sharepoint-2013-projects-mavention-quick-deploy/

Download the tool here:
Mavention Quick Deploy

Update:
As Gary pointed out in the comments below. There is a new kid in town called Fishbone. The reviews, functionality and screenshots look promising. Let’s find out!
http://visualstudiogallery.msdn.microsoft.com/4784e790-32f4-455f-9228-53f537c03787

One word of caution: I learned the hard way today that the Content Search Web Part is only available in the SharePoint Enterprise (on-premise) installation.

I hope that the nice  folk @Redmond change their mind about this and also make it available for the SharePoint Standard and SharePoint online versions.

The on-premise feature matrix can be found here:
http://technet.microsoft.com/en-us/library/jj819267.aspx#bkmk_FeaturesOnPremise

The online feature matrix can be found here:
http://technet.microsoft.com/en-us/library/jj819267.aspx

Back to the drawing board…

Add breadcrumb

Simply add this snippet to your master page or page layout

<!--MS:<asp:sitemappath runat="server" sitemapproviders="SPSiteMapProvider,SPXmlContentMapProvider" rendercurrentnodeaslink="false" hideinteriorrootnodes="true">-->
<!--ME:</asp:sitemappath>-->

And when loading your page again you should see something similar like this:

Navigate up (breadcrumb fly-out)

If you are used to SP2010 or SP2007 you might also know the navigate up icon.  When you click it, a flyout appears with the breadcrumb

To add this one to your SP2013: edit the master page (or actually the html). Look for a div with the css class ‘ms-breadcrumb-top‘. In this div you find a SharePoint control called PopoutMenu.

For some reason this ‘PopoutMenu’ control has the  attribute ‘visible’ set to ‘false’. Remove the complete attribute or replace the visible=”false”  by Visible=”true”

The result will be an icon that when clicked results in a breadcrumb popout.

Manually downloading all the needed language packs from the Microsoft site can be handful. You have to download an extra pack when you have the SharePoint Server version installed. Multiply the amount of packs by 2 if you have a service pack installed. And you have to do this for all the required languages.

This can be confusing and if you don’t pay attention it’s easy to make mistakes. Luckily this tool downloads all packs automatically. A real time saver.

According to Bjørn Furuknap’s blog and the SharePoint Server 2013 Preview documentation you will need 24GB of RAM to develop for SharePoint 2013. (SharePoint 2013 Foundation: 8GB)

I was expecting an increase but 24GB was not in line of my expectations. On the other hand SharePoint development always was a memory hog. With SP2007 you needed at least 4GB. Even now not all laptops have 4GB. Back in 2006-2007, 512Mb was the standard. There are some rumors that by disabling SharePoint Server Search you can do development with a little less (12GB-> 16GB)

Like Bjørn is already stating in his blog: RAM is cheap.

btw Any tips on how to convince IT managers to buy new laptops.

If you ever had to implement some kind of visual change in SharePoint, you know that, with previous SharePoint versions, this could be a challenge. Even SharePoint 2010 is spitting out HTML that makes website designers cry.

I installed SharePoint 2013 Foundation Preview this week. And I decided to take a look at the changes in HTML with some of my past branding projects in mind

Notice: Although I’ve implemented quite a few custom look and feels in SharePoint. I do not consider myself an expert in CSS, HTML 5 or SEO. But I do recognize bad HTML code.

<head>

First thing you notice is that the <head> section is much cleaner. It is better aligned, I only counted 2 JavaScript script blocks. All the other JavaScript code is nicely stored in external JavaScript files and (dynamically) referenced on the page.

There seems to be a lot of this dynamic registering of JavaScript files going on ( RegisterSodDep ). These JavaScript files only load when they are requested. This significantly reduces the load time of a web page. This function was also available in SP2010 but to my knowledge it was not used this much.

I’m also missing some hidden input fields. I’m not sure if this is by design or if it’s due to my freshly installed SharePoint and my lack of enabled features.

The _layouts/15/

They have added an extra version number in the /_layouts path.
Examples:

<img src="/_layouts/15/images/spcommon.png" />
<link rel="stylesheet" type="text/css" href="/_layouts/15/1033/styles/Themable/corev15.css"/>
<script type="text/javascript" src="/_layouts/15/init.js"></script>

A good move as it will probably make future backward compatibility easier to maintain.

Web parts

In previous SharePoint versions, adding web parts to your page results in nested <table> elements embedded in the page. Styling these nested tables is a handful. Luckily the tables made way for <div> elements.

One word of warning though. The web part title and body are still wrapped in 4 levels of divs. IMHO They could have simplified it even further.

Another example is that the HTML of the web part title is rather complex.

<div>
  <span>
    <h1>
    <nobr>
      <span>A web part title</span>
    </nobr>
    </h1>
  </span>
</div>.

Personally I see no reason for this complex HTML structure. Except maybe for some compatibility issues with some older browsers?

The body

No funky load scripts anymore on the body element. They are still there though. They are probably replaced with jQuery alternatives. For example the “#s4-workspace” style attribute is still updated dynamically with each screen resize.

The HTML in the body is cleaner. SP2013 clearly steps away from the table layout which is a good thing. I did notice some <div> elements with css classes like ms-table and ms-tablecell.

The deep nesting of HTML elements is still present in SharePoint 2013. Probably due to the extreme flexibility that SharePoint offers to modify and extend almost everything that is on your page.

Conclusion

In general the SharePoint 2013 HTML code makes a big leap forward. The nested <table> elements that were over present in older versions of SharePoint are gone.

Huge clean-up in the head section, controls are rewritten to use HTML best practice guidelines (example <ul> instead of <tables>) .

Yes there is still some optimisation possible but overall designers will have it a lot easier when applying a corporate identity on SharePoint site.