uc_taxes fails to insert/save new tax rates

I just installed Ubercart on a fresh Drupal 6.15 install, and the uc_taxes module seems to be unable to add any tax rates.

Raw error in the drupal log:

Column count doesn't match value count at row 1 query: INSERT INTO uc_taxes (name, rate, shippable, taxed_product_types, taxed_line_items, weight) VALUES ('MVA', 0,25, 0, 'a:1:{s:7:\"product\";s:7:\"product\";}', 'a:0:{}', 0) in /home/sigve/sandbox/drupal6/includes/common.inc on line 3467.

Made a little more readable:

INSERT INTO uc_taxes 
 (NAME, rate, shippable, taxed_product_types, taxed_line_items, weight) 
 VALUES ('MVA', 0,25, 0, 'a:1:{s:7:\"product\";s:7:\"product\";}', 'a:0:{}', 0)

As you can see the rate is not being properly quoted in the query - so "0,25" is interpeted as two values, 0 and 25 - causing a mismatch between the number of columns and values. For the record I entered 25% in the rate field, and the same issue also occurs if I use the decimal form of .25. I also tried .06 (which is the example rate in the desc for the field), with the same result.

I took a look at the code, and it appears like you do a floatval() on the submitted rate before passing it to uc_taxes_rate_save() which used drupals drupal_write_record() against uc_taxes. The rate field there is set to float (which is what the floatval() returns). I therefore tested the return of "floatval($form_state['values']['rate']) / 100" on my webserver with the rate set to 25%, which is float(0.25) with a var_dump. I am not quite sure where the value turns from 0.25 to 0,25 - but it does happen somewhere along the way. I can't really see anything in Drupals database layer that should cause it either, at least not as long as it properly applies the %f placeholder when building the query. I tested %f replacement with the float value using both sprintf() and preg_replace() (which is similar to what drupal does, with preg_replace_callback() in db_query()) - and none of them resulted in use of comma as separator. Perhaps it runs as deep as php language settings (this is on a Norwegian server) and it's mysql module, I don't know

Either way; There's an issue with using a float value in this manner under some kind of condition - so it might be a good idea to consider an alternative method of handling/storing the rate value to avoid this issue and ensure highest possible compatibility. Perhaps storing it as a string, or serializing it (although this format will be a little bloated with floats IIRC).