Wednesday, November 5, 2014

You should use exponential notation when writing XRANK queries

I have previously mentioned a problem using decimal numbers on XRANK statements in my Freshness Boost post. The problem is that the decimal separator used differs on your locale.
For example in Norwegian the character used is , (comma) while in English the character used is . (punctuation). The issue arises when a query rules is written using one locale, and being used on a query in a different locale.
Say I have a query rule with the following XRANK statement where I use . as the decimal separator
{searchterms} XRANK(cb=0.5) title:test
If a user has their SharePoint locale or browser settings set to Norwegian, then the query will fail, giving you an error message that search didn’t understand the query. The reason for the error is that the query framework will use .Net to parse the number with Double.Parse(), and this function is culture sensitive when parsing, and the culture used is based on the users locale settings.

The solution, as I have implemented in the Freshness Boost Generator, is to instead use exponential notation when writing the numbers. This means 0.5 is written as 5E-1 and 0.25 would be 25E-2. The number behind the E character is the number of decimal places to move to the left. This ensures that parsing the number always work, regardless of the locale used.
Rewriting the above query you end up with
{searchterms} XRANK(cb=5E-1) title:test
As a conclusion you should always use exponential notation when writing decimal numbers in an XRANK statement to ensure it will work across different locale settings.


  1. I've been struggling with a similar issue: I have two search farms with the same content, but a search for 1.1 returns different results in each, I think because of the tokenization of that string. I've experimented with the regional settings of the search site, which seems to make no difference. What regional settings impact the tokenization of decimal numbers in a user query?

    1. I believe it might use the users setting in SP first, then the browser setting. You can try to set the query language to for example English (1033) in the .webpart properties and see if it makes a difference. See for how you can test this. Easiest is to add a &ql=1044 parameter to the URL