Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Doesn't look like a mysql bug. See:

setlocale(LC_ALL, 'sl_SI.UTF8');
var_dump((string)19.9);

It's just how string conversion of floats works.

I disagree this is not a bug: mysqli_real_escape_string is supposed to convert PHP literals to SQL literals, and the representation of the floating number 0.1 in SQL is not "0,1" but "0.1" (the result is really a string and not a PHP float which would then converted to a string during output in the test script). Below a test script to show the result of mysqli_real_escape_string is "0,1" and it does not result of some processing during output.

As documented, the charset is relevant for the strings, but this is about the decimal mark and not the charset.

I experienced this issue in PHP 5.6.30, 7.0.23, 7.1.9, 7.2.0RC2.

I guess this is linked to bug #74779, where the result of an SQL statement implying a float is trucated to the integer part, possibly because of a wrong decimal separator.

Test script:
---------------
setlocale( LC_NUMERIC, 'fr_FR.UTF-8' );
$conn = new mysqli();
$number = 1/10;
$result = $conn->real_escape_string( $number );
setlocale( LC_NUMERIC, 'C' );
var_dump( $result );

Expected result:
----------------
string(3) "0.1"

Actual result:
--------------
string(3) "0,1"

The thing is that real_escape_string is declared like this (copied from PHP manual):

string mysqli::real_escape_string ( string $escapestr )


The consequence is that the following are equal:
$result = $conn->real_escape_string( $number );
$result = $conn->real_escape_string( (string) $number );

A more robust and probably the best way to insert parameters into SQL statements is probably usage of prepared statements + mysqli_stmt_bind_param. mysqli_stmt_bind_param can actually distinguish between integer/decimal/string/binary types in contrast to mysqli_real_escape_string.

all that examples are plain wrong code to start with - RTFM - the data type for the param is STRING and NOT FLOAT (besides that no one should use functions prefixed with mysql_ for many years now)

in PHP7 with strict-types this would simply raise an exception and without strict-types THE CALLER and NOT the receiver does implicit casting

so the function for which you wrote the Bugreport has no business at all with your problem

Indeed, I misread, sorry about that and thanks for the quick answers. I will then open a bug in the software I experienced the bug (MediaWiki).