Changing SharePoint List Template Language

​Problem

When creating a list template within a variation site, the list template gets tagged with the site’s language it was creating in, and prevents the users from using it within a site that has a different variation label. E.G. a list template created within an English site cannot reused as a template to create the same list in a French site.

Reason

A list template is represented by a .stp file. When saving a list as a template in SharePoint, a .stp file gets created at the site collection’s list template document library. A .stp file is nothing more than a .cab file containing a single manifest.xml file containing information about the list instance and about its associated list items. By default, the manifest file gets tagged with its parent site’s language id. This prevents the list from being made available in sites having a different language id (e.g. different variation label).;

Solution

Start off by extracting the manifest file from your .stp:
1 – Rename your .stp file to .cab;
2 – Double click on your .cab file to browse its files. In there you should only see a single file, manifest.xml

1.png

 

3 – Double click on the manifest.xml file, and when prompted, pick a location to extract it.
4 – In windows explorer, browse to the location where you extracted the file, and open your manifest.xml file with an editing tool such as notepad;
5 – In there, look for the XML tag <Language>. This is where you specify to what variation label your template applies. In my example, the value was 1033 for English;

2.png

6 – Modify the Language tag’s value to reflect the id of the language you want. In my case, I wanted the template to display in French, so I changed its value to 1036.
7 –Save your modified .xml file;
8 – Open a new command prompted window;
9 – Browse to the folder where your modified .xml file is located;
10 – Type in makecab manifext.xml [pick a name].stp . This command will repackage a new .stp file containing the language changes you specified.

3.png

 

11 – Browse back to the list template gallery in SharePoint, where you first downloaded the .stp template file. Upload your newly created .stp file created at step #10;
12 – Voilà, you are done! Your list template is now accessible in the alternate variation label!

The Surface Challenge – Part 3: Development

In this article, I will be going over the development process I follow to get a SharePoint 2013 app ready for Prime time using a Surafce Tablet device.

Development IDE

As main main development IDE I use Visual Studio 2012. In order to be able to do any SharePoint 2013 App development, one requires Visual Studio 2012 Update 1, as well as the Office Developers Tools nuggets. Overall, my Visual Studio installation takes close to 7Gb of Space. It has all been installed on my Sandisk extra storage.

Process

All code is written directly on the device, and by that I mean I don’t use the device to connect to any remote Virtual Machines. I develop all my apps using the SharePoint-Hosted app model, which doesn’t require any server side hosting bits. Once my code is ready to be tested, I simply publish it from within Visual Studio 2012 onto my free MSDN Office 365 developer site. This allows me to do F5 debugging of my app. For those not familiar with this concept, what I mean by F5 debugging is that since all my apps are written using javascript, I can simply make some modifications in my code within Visual Studio, save them out, and simply refresh my Office 365 page to view the changes. Visual Studio keeps a connection to the remote site in the memory, and is smart enough to push any changes to the code in the background, allowing developers to debug remote apps in real time.

Deployment

Once my app has been successfully tested, all that remains to be done, is to grab the .app file that has been compiled locally by Visual Studio, and to send it out to the team responsible for the on-premises SharePoint servers. They will then go and add my .app file to the organization’s App Catalog.

Switching Solution Type of a Web Part Causes Errors

I had been working on a sandboxed web part for some time, and had it deployed onto a development server for testing purpose. Then some requirements changed, and I had to change it from being a sandboxed solution into being a Farm one. I made sure I uninstalled my sandboxed solution from the solution gallery before trying to install the new one. The Farm solution’s WSP installation went through fine, without any errors. I was also able to activate its associated feature without a problem. However, whenever I was trying to go and insert the web part onto a page, I would get the following error (“The request could not be completed because the specified solution was not found):

errorsandboxfarm.png

Basically what happened here, was that the server still had a reference to the sandbox’s assembly, and the webpart reference couldn’t be found when trying to insert it on a page. The solution to this error was to go in the Web Part’s gallery at the root of my site collection (/_catalogs/wp/Forms/AllItems.aspx), and to delete the entry for my web part in there, because it still referenced the sandbox version. After that entry as removed, all I had to do was reactivate my feature, and I was then able to add my web part without any issues!