QLocaleData handles number conversion by, first, mapping input characters to a canonical C-locale-based form, then parsing the result. In particular, support for bases greater than ten involves treating the letters as digits ten through thirty-five. To that end, upper-case letters are lower-cased. However, the mapping of locale-specific signs, separators and digits in numbers maps the exponential separator to a lower-case e. So lower-case e is used both as the digit for fourteen and as the exponential separator. This seldom presents problems, as I don't think we support floating-point conversions except in base ten; but, for example, if the input were meant to be a hex integer and contained an exponential separator (that isn't originally an 'e' or 'E'), we'll wrongly accept the text as an integer, interpreting the separator as a hex digit, where we should reject it.

Fixing this shall involve some trickiness, since some locales do use 'e' or 'E' as exponent separator, but their base > fourteen numbering also uses it as a digit. It is arguable that the whole design choice (convert to C-locale, then convert that) is wrong and the number parser should consult the locale to determine which characters are digits, separators and signs.