Why does Perspective Table ignore the es-ES number locale?

Symptom and Working Answer

A Perspective Table keeps rendering numbers as 1,234,567.89 when the target is 1.234.567,89. Setting the session locale to es-ES leaves the comma grouping unchanged, and changing the locale from a script has no visible effect.

The workaround that holds has two parts:

• Set the session locale to it-IT. Italian uses the same convention as Spanish: period for thousands and comma for decimals. In field use, it-IT is the locale that switches Perspective number formatting reliably.
• Place a Numeric Entry Field in the same view and hide it. Its presence triggers the locale number format for every number displayed on the page, including numbers in Table cells that otherwise stay in the default format.

This is a known defect. Inductive Automation tracks it internally as IGN-7305, open since 2023. A related defect covers the Numeric Entry Field decimal separator for Swedish, Spanish and Catalan (BUG-3267, IGN-11874). Treat the workaround as permanent until the release notes for your Ignition version list one of these tickets as fixed.

Locale Resolution in Perspective Number Rendering

In this article, locale means the session-level locale property, session.props.locale. The term format string means the pattern in a Table column's numberFormat property, such as 0,0.00.

Perspective uses numeral-style format strings. In that syntax, , and . are pattern tokens. The comma means "group thousands" and the period means "decimal point here." They are not the characters printed on screen. At render time, the client-side formatter replaces those tokens with the delimiters defined for the active locale.

That replacement works only when the formatter has the locale's delimiter data loaded and selected. If it does not, it falls back silently to the default English delimiters. No error is raised. This explains both symptoms:

• The locale property holds the correct value, but the Table output does not change. The property and the formatter's active locale are out of sync.
• Adding a Numeric Entry Field fixes the whole page. That component's initialization causes the formatter to apply the session locale, and every number rendered afterwards picks up the new delimiters.

One wrong practice follows from this. Do not rewrite the format string as 0.0,00 to force period grouping. That swaps the meaning of the tokens and produces misplaced decimals. It breaks as soon as the locale switch starts working.

Diagnostic Decision Path

1. Check 1: identify the rendering layer. Confirm the number sits in a Perspective component, here a Table inside a Perspective view. It must not be in a Vision component, a Report, or a Gateway page, because each of those formats numbers through a different path. If it is Perspective, go to Check 2. If it is not, this defect and workaround do not apply.
2. Check 2: read the column configuration. Open props.columns and find the entry for the numeric field. Expect render set to number (or auto with numeric data) and a numberFormat that uses standard tokens, such as 0,0.00.
   • If the column renders as string, or the data arrives already formatted as text, locale settings cannot affect it. Fix the data type first.
   • If the column is numeric, go to Check 3.
3. Check 3: read the live session locale. In the running session, read session.props.locale. You can bind a Label to it for a quick readout.
   • If it does not show the locale you set, the write is not reaching the session. Set it in the session props, or write it from a session-scoped event.
   • If it shows the locale but the Table still groups with commas, you are looking at the formatter defect. Go to Check 4.
4. Check 4: substitute it-IT. Change the session locale from es-ES (or sv-SE, ca-ES) to it-IT.
   • If the Table switches to period grouping, apply the procedure below and stop.
   • If some or all numbers still show commas, go to Check 5.
5. Check 5: add the Numeric Entry Field trigger. Drop a Numeric Entry Field into the same view and reload the session.
   • If every number now renders 1.234.567,89, keep the field and hide it.
   • If numbers still render wrong, move to the string-formatting fallback in the pitfalls section.

Workaround Procedure: it-IT Locale and Hidden Numeric Entry Field

1. Open the session properties in the Designer and set locale to it-IT. If the locale is chosen per user at login, write it-IT to session.props.locale in the session startup logic instead.
2. Leave the Table column numberFormat in standard token form, for example 0,0.00 for two decimals or 0,0 for integers.
3. Add a Numeric Entry Field to the view that contains the Table. It does not need a binding or a meaningful value.
4. Hide the field by setting its display position property to false inside a flex container.
   • Keep the component mounted. The trigger depends on the component existing on the page.
   • Other ways of hiding it may prevent it from rendering at all. If you hide it another way, repeat Check 5.
5. Repeat steps 3-4 in every view that displays formatted numbers and can be the only view on screen. A popup or docked view shown on its own does not inherit the trigger from a view that is not loaded. Putting the field in a docked view that is always open is a workable alternative.
6. Add a note in the view documentation that references IGN-7305, so the field is removed deliberately once the defect is fixed, not by someone cleaning up an "unused" component.

Pitfalls and Fallback

The last-resort fallback bypasses the client formatter. Build the display string in a script transform on the Table data binding, with the period and comma inserted explicitly, and set that column's render to string. Keep the raw numeric value in a hidden column if downstream logic needs it.

Verification Checks

1. Check 1: bind a Label to session.props.locale in the running browser session. Expect it-IT.
2. Check 2: put a test row with the value 1234567.891 in a column with numberFormat 0,0.00. Expect 1.234.567,89.
3. Check 3: temporarily delete the hidden Numeric Entry Field and reload. Expect the value to revert to 1,234,567.89, which confirms the view depends on the trigger. Restore the field and confirm Check 2 passes again.
4. Check 4: click the numeric column header to sort. Expect numeric order, for example 9,50 before 100,00. Alphabetical order means a column was converted to a string.
5. Check 5: close the browser tab, open a fresh session, and navigate directly to the view without passing through any other page. Expect 1.234.567,89 on first render.

FAQ