whatever you did in February seems to have been only partial, as my experiments today showed. I am using 2010.1 build 422 on a German Win7 (64bit) with German Excel 2007 and English VS2010.
My RadGridView displayed some query results (marvellous, how easy this is and how fast it becomes once you add a single line for virtualization), one of them the numeric value "4.5". Running in a German environment this was displayed correctly as "4,5". However, exporting this grid to both CSV and ExcelML also pushed "4,5" out, which is wrong for ExcelML, as a "," in a number field seems to be treated as "thousands separator" during import (German Excel 2007 on German Win7) and the cell contains the number "45".
I came up with one quick, wrong, and extremely ugly fix, but this at least produces "correct" ExcelML, where the grid number "4,5" ends up as the excel cell with value "4.5" (displayed as "4,5" of course).
| Dim cc = System.Threading.Thread.CurrentThread.CurrentCulture
| System.Threading.Thread.CurrentThread.CurrentCulture = New CultureInfo("en-US")
| IO.File.WriteAllText("export.csv", MyGrid.ToCsv, System.Text.Encoding.Default)
| IO.File.WriteAllText("export.xml", MyGrid.ToExcelML, System.Text.Encoding.UTF8)
| System.Threading.Thread.CurrentThread.CurrentCulture = cc
So my guess is that you have to ignore the current culture during formatting the cell contents for ExcelML.
I also tried exporting to CSV or Text (==Tab-separated values), but this got too messy too soon and there basically is no way to export a csv, which is "correct by definition".
BTW: I'm also submitting a support ticket pointing to this post, as I'd like to have this issue cleared up quickly.