Disable/change thousand separators in Inputs.table?

Community Help
1

I wonder if there is an option to disable the automatic thousand separators for Inputs.table. These automatically placed separators appear as comma characters for me, which are often not interpreted as thousand separators but as decimal separators in Europe. Thus, in addition to the option to disabling the thousand separators, having the possibility of changing them from commas to dots would have been very useful.

So far, I have been using the {format: myVariable: d=>d} trick, but I do not find having to do this for every table an elegant solution, and this approach does not allow me to change commas to dots.

I couldn’t find an answer on Google, documentation on Observable, and in the API docs of Input.table (could be my bad); I would appreciate any tips.

1 Like
2

You can pass in a locale option, e.g.:

Inputs.table(penguins, {locale: "de"})

Unfortunately this option does not currently seem to be documented for Inputs.table().

3 Likes
3

Thank you very much for the suggestion mootari.

Although the locale argument solves the problem for the tables where it is specified, it would have been great to have the option to set the characters for decimal and thousand separators notebook-wide. For instance, in this use case, locale: 'de' argument serves only as the first step of reaching the desired behavior (i.e., no thousand separators + decimal separator as a comma):

CleanShot 2022-12-15 at 13.27.55@2x
CleanShot 2022-12-15 at 13.27.55@2x2084Ă—494 83.3 KB

The full solution requires quite a bit of fiddling:

CleanShot 2022-12-15 at 13.38.30@2x
CleanShot 2022-12-15 at 13.38.30@2x2078Ă—604 70.9 KB

I think a global locale setting (e.g., in Observable’s user preferences or as a notebook-wide style parameter) would have made this less painful. Turning off the thousand separators completely or having the option to use a custom character (e.g., apostrophe (')) probably would have been useful features as well.

(Of special note: I generally represent years as numeric values instead of as dates, and having to hack each table to turn the thousand separators off for year columns is often my only issue with the otherwise stellar Inputs.table method.)

Maybe this has become more of a feature request now, but any further tips/shorter workarounds would still be appreciated. Thanks in advance!

1 Like
4

The problem here is that you specify a custom formatter and thus override the autoformatter that makes use of the locale option. I don’t see a generic way to solve this and would instead recommend that you define your own formatting helper.

To give an example:

raw = d => d

// ...
format: {
  Min: raw,
  Max: raw
  // etc
5

If you find that you have “column types” where you often define multiple properties in the same way (format, width etc), you may want to take a look at the helper pluginPerColumnOptions in this notebook: Sortable Notebook List / Fabian Iwand | Observable

6

I know. It is a use case with a custom formatter, which demonstrates a situation where two locale settings clash. It is a use case, an example; not the problem I have been discussing.

The problem I have been discussing and the features I would have loved to see as solutions are:

  1. Ability to completely turn off thousand separators, so that every table (e.g., with numbers as years) do not need to be hacked
  2. Ability to customize the characters for decimal/thousand separators, so that the users can achieve the desired separator less painfully
  3. Optionally/side issue: Set a global locale parameter notebook-/Observable-wide, which would apply to every locale setting in the notebook (incl. formatters and Inputs.table), so that they do not clash (as in the example). I am aware that doing this without introducing implicit behavior to JS may not be feasible, and thus, this is not a behavior I would defend strongly in the exact form I suggested. Once again, this is not my main issue.
7

Thanks a lot! pluginPerColumnOptions seems like a possible solution. I will check it.

1 Like
8

Please also note that Issues · observablehq/inputs · GitHub is likely a better place for your feature request.

9

Thank you for your suggestion. My question spontaneously became a feature request during the thread, but I do not have the time/intention to re-iterate and advocate it on GitHub. If you or someone resonates with it, please feel free to pass it on to the team. Otherwise, it can fall through the cracks I suppose.