hoverformat/tickformat overwrites separators

It's not possible to set the separators of thounds and comma when also setting the tickformat or hoverformat.

Settings:

data = [{x:[0],y[2323.45]]
layout={
  separators: ',.',
  yaxis: {
    hoverformat: ',.2r'
  }
}

Expected output:
When hover, following number should be printed: "2.323,45".

Example: Codepen

I want to reformat ticks and hover to not show "k" as thounds, but also keep the localized thousand separator and comma.

[Romainpetit]

Indeed, surprisingly.

hoverformat and tickformat are using D3 Format, which is configurable with a custom locale.

var myLocale = {
  "thousands": ".",  // specify that thousands are separated with a dot
  // .. other rules
}

Then used like

// create custom locale formatter from the given locale options
var localeFormatter = d3.locale(myLocale);

// create a formatter for the number (grouped thousands with two significant digits). By default ',' means 'thousands' but we switched that into a '.' in our custom localization
var numberFormat = localeFormatter.numberFormat(",.2r");

Which should do the job. I'll try to use it and keep you posted here

[rreitmann]

We are experiencing this as well. Is there any workaround or plan to fix this?

[rreitmann]

I have found a workaround for displaying numbers correctly with a german locale if you are using xaxis.tickformat:

var germanLocale = Plotly.d3.locale({
    decimal: ',',
    thousands: '.',
    grouping: [3],
    currency: ['€', ''],
    dateTime: '%a %b %e %X %Y',
    date: '%m.%d.%Y',
    time: '%H:%M:%S',
    periods: ['AM', 'PM'],
    days: ['Sontag', 'Montag', 'Dienstag', 'Mittwoch', 'Donnerstag', 'Freitag', 'Samstag'],
    shortDays: ['So', 'Mo', 'Di', 'Mi', 'Do', 'Fr', 'Sa'],
    months: ['Januar', 'Februar', 'März', 'April', 'Mai', 'Juni', 'Juli', 'August', 'September', 'Oktober', 'November', 'Dezember'],
    shortMonths: ['Jan', 'Feb', 'Mär', 'Apr', 'Mai', 'Jun', 'Jul', 'Aug', 'Sep', 'Okt', 'Nov', 'Dez']
});
Plotly.d3.format = germanLocale.numberFormat;

[etpinard]

cc @alexcjohnson would may or may not come across the same code paths in his i18n work.