Modifying Spell Check for SharePoint Server 2007


SharePoint is Microsoft’s server dedicated to the interchange of information and thus a system where writing is a critical component. As with other Office family products, Microsoft Office SharePoint Server (MOSS) provides tools to check and correct the orthography in texts. The service is used in some default components of MOSS, allowing developers to utilize it in custom software, such as WebParts or specialized pages.

The SharePoint Object Model offers spell check as a WebService to control the orthography in different languages, providing suggestions and alternatives to correct errors. It’s important to point out that the service is not equal to the system used by other Office products. Consequently—as an on-line server—the SharePoint system is less advanced, and provides limited functionality in contrast to the default spell check of Word or Excel; for example, there is no possibility to check grammar nor does it offer a thesaurus.

MOSS uses spell check in various locations; for example, in each List where there are Text Fields there is a “Spelling” button in the horizontal tools bar. When you click the button, a popup window appears, allowing you to loop through the words on the page, making a comparison with the internal dictionary and displaying words with errors, together with suggestions to rectify them.

Figure 1: SharePoint List with the Spelling button and popup window

The same window allows users to select the Language and Dialect for the corrector (the configured default Language is initially used). The corrector only compares words with the internal dictionary, without grammar or syntax corrections. Another disadvantage is that it is not possible to add new words to the dictionary; to circumvent that situation, a list of words can be created that will be ignored by the corrector; in fact, it’s a specially designed dictionary.


All the corrector’s functionality is available as a default Microsoft Office SharePoint Server (MOSS) WebService. The “SpellCheck.asmx” WebService has three input parameters:

  • chunksToSpell: An array of strings with the texts to check
  • declaredLanguage: An integer that gives the Language Identifier to be used by the checker. This Identifier is not the same as that used by SharePoint for its internal configuration; the values can be found on the Microsoft site; use the value of the column “Decimal value”
  • useLad: A Boolean that indicates whether the spell check should detect the MOSS default language

At first glance, the WebService is very straightforward to apply following a simple sequence: create a reference, give the service user credentials, configure the input parameters, and execute the service. Unfortunately, the MOSS implementation has two crucial errors that hamper its use.

First, if the parameter “useLad” is employed in such a way that spell check uses the default MOSS language, the checker will apply the Language Identifier of MOSS, not the target Language Identifier to be checked. This is not a problem in English, because the two Language Identifiers are the same (1033), but in other languages it is always different. For example, in Spanish the WebService will use 3082 (MOSS Language Identifier for Spanish) instead of 1034 (Language Identifier for Spanish Spell Check). Consequently, the corrector never provides accurate results in languages other than English.

To avoid this problem, declare the “useLad” parameter as false and give the correct Language Identifier in the “declaredLanguage” parameter. The downside to this workaround is that you always need to use a constant identifier or you must create a lookup table with the necessary logic to link the MOSS Language Identifier to the spell check Language Identifier.

The second problem may be more serious. Because the WebService has irregularities in the code, vocabulary suggestions are not provided. To resolve this problem, it is obligatory to call the WebService using the methods of the class “HttpWebRequest” from the NameSpace “System.Net”, creating the SOAP envelope and XML query manually, as outlined in the following paragraphs.

In the source code where the WebService will be called, create references (“using” in CSharp) to System, System.IO, System.Net, System.Text and System.Xml. The following code lines call the WebService using the HttpWebRequest class:

StringBuilder myStringBuilder = new StringBuilder(EnvelopeSoap);
   IndexOf("</soap:Body>"), MyQuery);

XmlDocument EnvelopeSoapXml = new XmlDocument();

HttpWebRequest myQueryWeb =
myQueryWeb.UseDefaultCredentials = true;
myQueryWeb.Headers.Add("SOAPAction", AccionSoap);
myQueryWeb.ContentType = "text/xml;charset=\"utf-8\"";
myQueryWeb.Accept = "text/xml";
myQueryWeb.Method = "POST";

using (Stream myStream = myQueryWeb.GetRequestStream())
IAsyncResult ResultAsync = myQueryWeb.BeginGetResponse(null, null);

string ResponseSoap = string.Empty;
using (WebResponse ResponseWeb =
using (StreamReader myStreamReader =
   new StreamReader(ResponseWeb.GetResponseStream()))
   ResponseSoap = myStreamReader.ReadToEnd();

In the code, create a StringBuilder that contains the SOAP call to the WebService. The SOAP envelope is directly added by using the following syntax:

static string EnvelopeSoap = @"<soap:Envelope


Then, immediately before closing the envelope, add the XML query with the following syntax:

static string MyQuery = @"<SpellCheck >
   <string>This rou</string>
   <string> has an error </string>

There are two strings in the query that need to be adjusted, namely “This rou” and “has an error”, the Language Identifier is declared (1033) and the MOSS Language Identifier must be blocked with the code; useLead=false. As stated earlier, at this point you need to define the spell check Language Identifier if you are using a language other than English.

After the creation of the envelope and the query in a string, they are converted to a XmlDocument that can be used in the service call. The object “myQueryWeb” (of the “HttpWebRequest” type) is created using as input parameter the URL of the spell check WebService:

static string UrlChequerWS =

The object receives the default credentials of the user, the content type, the type of the method to be used, and finally, the form to send the envelope. The SOAP action type is added to the header in the following manner:

static string AccionSoap =

With this action, the envelope is assigned to the WebService call and using the interface, IAsyncResult, the anticipated result is asynchronous; this avoids a delay in the functioning of SharePoint while awaiting the response.

More by Author

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Must Read