http://ch2.php.net/manual/fr/function.html-entity-decode.php):

function html_entity_decode_php4 ($string)
{
// Replaces numerical entities
$string = preg_replace('~&#x([0-9a-f]+);~ei', 'chr(hexdec("
1"))', $string);
$string = preg_replace('~&#([0-9]+);~e', 'chr("
1")', $string);
// Replaces litteral entities
$trans_tbl = get_html_translation_table (HTML_ENTITIES);
$trans_tbl = array_flip ($trans_tbl);
return strtr ($string, $trans_tbl);
}

Just one comment, I'd make some tests with the 3rd parameter in the function (encoding), because perhaps it's necessary to specify the UTF-8 if the string contains UTF-8 chars (try it with some non-iso chars in the string, like Chinese or so) to avoid getting broken strings (haven't tested it here).

Assigning to Mathieu... TIA and ciao

Note : function addslashes_js is called from mod/quiz/view.php, line 427. There is no mod/quiz/accessrules.php in 1.9 (there is one in head, though)

The problem happens because print_single_button (in lib/weblib.php) calls s() (line 4203), which calls htmlspecialchars, on the javascript confirm message. This makes the string get encoded twice. Any idea why this is necessary? Either the message is already encoded, or it's not : I don't think de-encoding it is the proper solution .. I would much rather prevent the call from happening twice.

Hmm.. after a bit more testing, I did in quick regexp-powered search through moodle core and found that this call to print_single_button is the only one using the javascript confirmation. And finally, removing the call to addslashes_js prevent the double-encoding, but it doesn't make the   show up as a space.

Thanks for the quick fix.