Now it is the second time it happens that the search cannot return any results. This hickup is rare but it happens. To solve it I had to follow these steps:

1. Stop the Timer Service
2. Clear the configuration cache
   1. Find in \ProgramData\Microsoft\SharePoint\Config the folder where the file cache.ini exists
   2. Delete every file from this folder EXCEPT cache.ini
   3. Open cache.ini, delete the content and put ’1′ (without the quotes) in it and save the file
3. Restart the Timer Service
4. Index reset
5. Full crawl

Source: ITIDea. The linked blog post saved my afternoon today. Thank you, Anita Boerboom.

I Sverige är engelskan är väldigt stark. Speciellt i IT-branschen är vi vana att ha i princip allt på engelska, från kommentarer i koden till stora upphandlingar, rapporter och dokumentation. Trots det ser jag ett stort behov av att kunna prata om IT på svenska. Det gäller både lokala företag och globala företag. Det finns flera anledningar:

• Företag i Sverige följer svenska lagar som är skrivna på svenska, för att leva upp till kraven ska man kunna formulera sig på svenska.
• Modersmål eller det språk som man använder mest i vardagen (gäller mig bland annat) är den snabbaste vägen för kommunikation som ger en högre grad av nyansering. Att kunna nyansera krav och önskemål tidigt i projekt är guld värt (enligt många av mina korrespondenter). Man behöver spendera mindre tid på att formulera och tolka krav.
• En mer ideologisk anledning (men en viktig sådan) är att vi som bor i Sverige har skyldighet att utveckla och hålla svenskan levande, inte minst inom IT-sektorn.

Svenska är en stor möjlighet för att verkligen ge mervärde till våra kunder, möta dem på hemmaplan, prata ett gemensamt språk. Startpunkten till den här diskussionen har varit en ny webinar som jag planerar hålla den 14 april kl 10. Webinarens titel är SharePoint i molnet.Det finns ganska mycket information om SharePoint Online och Office 365 på engelska. Det är dock ganska sparsamt med information på svenska. https://www.eventbrite.com/e/sharepoint-i-molnet-tickets-15976529229 Det här är det som väntar dig som vill delta i webinaren:

In my post yesterday I showed how to publish Visio files as html image maps. That was one of the alternatives. Today I’ll present how to use SVG to achieve the same goal: publish Visio diagrams in SharePoint without having the Enterprise license. There are some alternatives:

1. Show Visio diagrams as pdf files on SharePoint Pages
2. Embed Visio diagrams as html image maps - Read more in my previous blog post
3. Embed Visio diagrams as svg pictures - This blog post.
4. Link to Visio files that are opened using Visio Web Viewer in a new browser tab.

SVG

SVG stands for scalable vector graphic, it is a xml-based format for defining images. It is supported in all modern browsers. Because SVG can be part of a page markup, it can be easily embedded into SharePoint.

I got a question from a customer: We have our processes defined in Visio, we don’t have SharePoint Enterprise CALs to use the Visio webpart. We have links in process maps. What can we do? Well there are three five ways to solve this business need:

1. Find money for SharePoint Enterprise - Very expensive
2. Show Visio diagrams as pdf files on SharePoint Pages - Expensive.
3. Embed Visio diagrams as html image maps - Least expensive
4. Embed Visio diagrams as svg pictures - Separate blog post.
5. Link to Visio files that are opened using Visio Web Viewer in a new browser tab.

If the business needs other features available only in Enterprise, just use the solution 1. Stop reading. If you are looking for alternatives, then consider pdf and image maps. I have seen projects where pdf files were embedded in the SharePoint Pages. It required a pdf plugin in IE, a lot of time to make it look the same in different browsers and the scroll and fixed size was still there. It was expensive because of the development and configuration time. In this blog post, I want to show the alternative number 3: embedding Visio diagrams as html image maps. This is only a Proof-of-concept so far.

The parts of the CSOM for updating Taxonomy fields are really cumbersome. I mean, look at this code, nicely provided by Vadim Gremyshev (@vgrem). To set a value in a taxonomy field we have to assemble a text representation, and adding a “fake” lookup id. What is needed is a wrapper for handling Taxonomy fields. SPMeta2 and PnP don’t seem to have it yet. Another issue that I have struggled with today was the missing Microsoft.SharePoint.Client.Taxonomy.dll. If you see this error (set customErrors=“Off” in the Web.config), then you have update the reference in the Visual Studio project: Open Properties for the reference called: Microsoft.SharePoint.Client.Taxonomy and ensure that Copy To Local is set to True: For some reason, this reference added through “App for SharePoint Web Toolkit” nuget package adds a reference to an assembly from your computers GAC.

The Chuvash keyboard layout has been the Russian keyboard layout with 4 Chuvash letters that are typed by pressing the right Alt button plus the base letter. Some of the arguments have been

1. Users don’t need to switch or learn a new keyboard layout. They can keep on typing Russian texts and sometimes Chuvash texts
2. It is easy to communicate about how the right Alt button works. The Right-Alt-technique is also used in Esperanto, Polish and other languages.
3. The letters are placed according the labels

Recently two major events happened that made the question about the Chuvash keyboard layout important:

In my spare time I am currently working on a Chuvash-Tatar phrasebook. I have used the Chuvash and Tatar keyboard layout on Linux. They work fine, but switching between them takes time. So I decided to add Tatar letters (right Alt + combinations) to my Chuvash keyboard layout. While adding it I found a combined Russian-Ukranian United keyboard layout and I thought:

• What if I create a new keyboard layout for Russian that will have almost all additional Cyrillic letters? A Russian Extended keyboard layout could be based on the Russian keyboard layout and have other non-Russian letters.

This is what I have come up to so far. The definition can be found on my project at github: russian-extended-kbd. I will update it more and provide more info about how it is organized and how to install it. I’ll also try to implement it for Windows and maybe for Mac (I doubt it, everything is so locked-down there). This is just a proof-of-concept so far. It only works on Linux (with xkb). Nevertheless, some key characteristics of this layout:

Recently I wanted to add Chuvash localization to the jQuery UI datepicker. Unfortunately, my pull request was rejected. The reason is that jQuery UI will be using Globalize framework: The jQuery Globalize framework relies on CLDR, so What is Unicode CLDR (Common Locale Data Repository)?

The Unicode CLDR provides key building blocks for software to support the world’s languages, with the largest and most extensive standard repository of locale data available. This data is used by a wide spectrum of companies for their software internationalization and localization, adapting software to the conventions of different languages for such common software tasks

Reblogging this useful code sample for updating multi-value lookup columns using CSOM in C# in SharePoint 2010, but also valid for SharePoint 2013.

Client Side Rendering (CSR) and jslink are great for customizing lists and forms in SharePoint. In my current project we use it a lot of it. A disadvantage of that path, although, is that it might occur javascript errors, during the development phase, but also in production. We do, of course, our best to leverage the best jslink code, but unfortunately we have to live with the fact that errors can occur, especially when we use it for NewForm, EditForm, DisplayForm and View (in list and grid). If an error occurs, it won’t stop the rest of javascript (it is wrapped in try and catch by SharePoint), but the fields will still not function as intended. It can also be some “corrupt” or old data in the field value that will “break” the jslink code. I would like to suggest one little fix, an idea I’ve come up to in my jslink-heavy project: