Feeds:
Posts
Comments

Introduction

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)
    lang01
  • Enable the desired languages (in my sample: French and Dutch)
    lang02
  • 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”)
    lang01
  • Select the desired options to create an export file (which is actually an XML based resource file (.resx))
    lang03
  • 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.

The problem

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-->

 

Sometimes it is a lot handier to just update one of the dll’s in the GAC rather than go through the pain of deploying an entire SharePoint solution. In fact it’s one of the key features that makes the CKSDEV Visual Studio plugin so valuable. Not best practice, to copy directly to the GAC, but very handy in a dev environment.

.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.

assembly

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

SharePoint 2013 and CKS:DEV

I use the Visual Studio CKSDEV plugin so much that I almost forgot it’s not standard Visual Studio functionality. It’s no doubt the number one tool when creating SharePoint solutions with Visual Studio.

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

The content search web part is just brilliant. Not only does it let you aggregate, filter and find content and their metadata. The new way of styling with the new display templates is a huge relieve after all the xslt horror in the SharePoint 2007 and SharePoint 2010 versions.

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.

CSWPFeature

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…

SP2013. Adding breadcrumbs

For some reason breadcrumbs are disabled in the default SharePoint master pages.  Luckily it is very easy to add them.

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:
Crumb

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.

Crumb2

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.

Crumb3

Follow

Get every new post delivered to your Inbox.