Feeds:
Posts
Comments

Posts Tagged ‘SP2010’

Using export translations and import translations.

Posted in Branding, Layout, look and feel, SharePoint, SharePoint 2010, SharePoint 2013, tagged , , , , , , , on March 10, 2013 | Leave a Comment »

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.

Read Full Post »

Tool: Application Tool manager 3.0

Posted in SharePoint, Tools, Uncategorized, tagged , , , , , on September 3, 2011 | Leave a Comment »

Quick description

Application Tool Manager (APM) is a great utility when programming for SharePoint 2010 (and general (IIS) web development) . Very handy if you want to attach your debugger to a specific w3wp.exe Process ID (PID)

The description on their website

This freeware application is a System Tray utility for providing quick access to common IIS tasks which are useful on a SharePoint development box. It may also be useful to others working with IIS. In essence, it enumerates the app pools on your box and lets you right click ‘em to bounce ‘em!

You can download the tool here<: http://www.harbar.net/articles/apm.aspx

 

Read Full Post »

The ‘Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine

Posted in Development, SharePoint, Uncategorized, tagged , , , , , , , on August 24, 2011 | 2 Comments »

We often get Excel files with content to import into SharePoint. Most of the time I fire up Visual Studio and write a small console application to import the Excel data. However with SharePoint 2010 I got the error “The ‘Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine”.

The idea

When I need to import content into SharePoint using the oledb data is far the easiest way to read Excel files without having to install office on your SharePoint server.

You simply add an OleDbConnection , an OleDbCommand, an OleDbDataAdapter and a correctly formulated select statement.

            string ConnectionString = @"Provider=Microsoft.Jet.OLEDB.4.0; Data Source=c:\Import\Sample.xslx; Extended Properties=""Excel 8.0;HDR=Yes"";";
            string CommandText = "SELECT * FROM [Services$]";

            OleDbConnection connection = new OleDbConnection(ConnectionString);
            OleDbCommand command = new OleDbCommand(CommandText, connection);
            connection.Open();

            OleDbDataAdapter adapter = new OleDbDataAdapter(command);

            DataSet dataset = new DataSet();
            adapter.Fill(dataset, "Excel");

The cause

SharePoint 2010 is 64 bit so you need to compile your custom SharePoint code as a 64-bit applications. However the default Jet Library does not support 64-bit applications and thus results in the following error:

The ‘Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine.

Solution

Luckily Micosoft has released a solution in the form of the Microsoft Access Database Engine 2010 Redistributable

  1. Download the Microsoft Access Database Engine 2010 Redistributable
  2. Install the package on your development machine
  3. Modify your OleDb Connection string from:
    Provider=Microsoft.Jet.OLEDB.4.0; ….
    to
    Provider=Microsoft.ACE.OLEDB.12.0;….
  4. rebuild your application
    note    : make sure your application is set to compile as a 64 bit application

Don’t forget to install this redistibutable on your SharePoint server as well.

Read Full Post »

Follow

Get every new post delivered to your Inbox.