Add configuration for locale in Numbro

[felixmw]

In order to have numbers and currencies formated according to local standards it would be very helpful to have a configuration option in Turnilo for this matter. E.g., setting it to "de-DE" makes Turnilo use "€" as currency symbol, "," as decimal separator and "." as thousandts separator.

[mkuthan]

I'm afraid that Numbro locale aware formatting is only the peak of the iceberg. We should at least inspect Turnilo code for other places where localisation is important (e.g. date formatting). If not the UI experience will not be logical and consistent.

The second question is how to configure locale? I'm not sure that static (and global) configuration for Turnilo instance is the best what we can do. Perhaps Turnilo could set locale based on browser preferences (http headers) but user should be able to change the locale from UI (exactly like timezone) and finally we need a fallback to locale set in Turnilo configuration file.

Let's discuss the Turnilo localisation before we start coding :) At least prepare the plan with milestones.

[adrianmroz]

Perhaps Turnilo could set locale based on browser preferences (http headers)

Nope, don't do this. Let user pick locale. Default is provided by configuration. Just like timezone.

I'm afraid that Numbro locale aware formatting is only the peak of the iceberg. We should at least inspect Turnilo code for other places where localisation is important (e.g. date formatting). If not the UI experience will not be logical and consistent.

Numbers and dates are low hanging fruits and we should focus on them. But some research wouldn't do any harm :)

[mkuthan]

Perhaps Turnilo could set locale based on browser preferences (http headers)

Nope, don't do this. Let user pick locale. Default is provided by configuration. Just like timezone.

Agree

I'm afraid that Numbro locale aware formatting is only the peak of the iceberg. We should at least inspect Turnilo code for other places where localisation is important (e.g. date formatting). If not the UI experience will not be logical and consistent.

Numbers and dates are low hanging fruits and we should focus on them. But some research wouldn't do any harm :)

Yep, search for dates and numbers "formatted" manually without libraries.

[felixmw]

Guys I am pretty impressed how fast requests for enhancements are driven forward. Thanks a lot. Unfortunately I am not a developer so I cannot help with the heavy lifting.

[KarolakJakub]

Hello. :) What we are after is the ability to define multiple custom csv and tsv exports - with our own formatting, which would be defined in the config.
We are not that bothered with how dates and numbers are presented in the app itself, but would rather like to define something along the lines of 'excel friendly' export. For my locale (pl-PL) it would mean no thousand separators and "," used as decimal separators.

Right now (refrence - #533), I'm using moment.format() for dates and .toLocaleString() for numbers. This is a bit inconsistent, so I'd like to discuss if we should stick to moment & toLocaleString combo or maybe switch to something like Intl and localeString or numbro and moment.
@adrianmroz mentioned that you guys would like to stick to consistent formatting between the app and exports, but we really need those excel friendly exports for our business.

In my PR, exports defined within the config have this structure:

- title: "excel friendly export to TSV" # name displayed in the share menu
    format: # "tsv" | "csv"
    separator: # "\t" | "," | ... 
    lineBreak: "\r\n"
    finalLineBreak: # "include" | "suppress"
    columnOrdering: # "keys-first" | "as-seen";
    locale:
      NUMBER:
        locale: # "pl-PL" | "us-EN" | ...; en-US by default
        localeOptions: # Only applicable to NUMBER type. Each value is optional. Described here https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toLocaleString
            localeMatcher: # "lookup" | "best fit";
            style: # "decimal" | "currency" | "percent" | "unit";
            unit: # string;
            unitDisplay: # "long" | "short" | "narrow";
            currency: # ISO 4217 currency codes, e.g. "USD", "EUR" etc. Must be defined when style is set to "currency".
            currencyDisplay: # "symbol" | "code" | "name";
            useGrouping: # boolean; this variable controls whether number values should be exported with thousand separators applied, e.g. 1 000 000, 1.000.000; false by default
            minimumIntegerDigits: # 1-21;
            minimumFractionDigits: # 0-20;
            maximumFractionDigits: # 0-20;
            minimumSignificantDigits: # 1-21;
            maximumSignificantDigits: # 1-21;
            notation: # "standard" | "scientific" | "engineering" | "compact"
      TIME:
        timeFormat: # e.g. "DD-MM-YY HH"; "YYYY-MM-DD[T]HH:mm:ss.SSS[Z]" by default
      TIME_RANGE:
        timeFormat: # e.g. "DD-MM-YY HH"; "YYYY-MM-DD[T]HH:mm:ss.SSS[Z]" by default

- title: "excel friendly export to CSV" # name displayed in the share menu
    format: csv
    separator: ","
    lineBreak: "\r\n"
    finalLineBreak: include
    columnOrdering: as-seen
    # .... etc 

If nothing is defined in shareOptions: section, Turnilo will switch to default options, defined within the code:

export const shareOptionsDefaults: ShareOptions = [
      {
        title: "export to CSV",
        format: "csv",
        separator: ",",
        finalLineBreak: "suppress",
        columnOrdering: "keys-first",
        lineBreak: "\r\n",
        locale:
        {
          NUMBER: {
          locale: "en-US",
          localeOptions: {
            useGrouping: false
          }
          },
          TIME: {
            timeFormat: "YYYY-MM-DD[T]HH:mm:ss.SSS[Z]"
          },
          TIME_RANGE: {
            timeFormat: "YYYY-MM-DD[T]HH:mm:ss.SSS[Z]"
          }
      }},
      {
        title: "export to TSV",
        format: "tsv",
        separator: "\t",
        finalLineBreak: "suppress",
        columnOrdering: "keys-first",
        lineBreak: "\r\n",
        locale:
        {
          NUMBER: {
          locale: "en-US",
          localeOptions: {
            useGrouping: false
          }
          },
          TIME: {
            timeFormat: "YYYY-MM-DD[T]HH:mm:ss.SSS[Z]"
          },
          TIME_RANGE: {
            timeFormat: "YYYY-MM-DD[T]HH:mm:ss.SSS[Z]"
          }
      }}]; 

These are designed to resemble current default "Export to TSV" and "Export to CSV" formatting as closely as possible.
As I understand, to keep everything consistent, default options should be auto-generated when config.yaml is being created for the first time, so shareOptions: section would always be mandatory.
Please let me know what you think - if having a split between the formatting in the app and the exports is possible and which technologies are preferred (Intl and localeString vs numbro and moment).