Resolving Ignition Perspective NumericEntryField Locale

Problem Details: NumericEntryField Mangles Decimal Input Under Non-English Locales

On Inductive Automation Ignition 8.1.x (verified against 8.1.48, originally reported against 8.1.2), the Perspective Numeric Entry Field component mis-formats user input when the active session locale uses a comma (,) as the decimal separator. A user typing 1,500.5 on a system whose locale is es-MX (or pt-BR, de-DE, fr-FR, etc.) sees the value re-rendered as 1.500,5 the moment a numeric format pattern is applied. The comma decimal mark is silently rewritten to a period, and the thousands separator is inverted.

Two related defects produce the symptom:

• IGN-6943 – NumericEntryField disregards the selected es-MX/pt-BR locale when formatting on blur or commit.
• BUG-13153 – NumericEntryField ignores the selected locale entirely; component defaults to en-US for parsing.

Setting the format property to none preserves the typed string, but strips the thousands separator, making the field useless for any data entry screen that must match downstream tag conventions.

Root Cause: Locale-Aware Parser vs. en-US Formatter Mismatch

Inside the Perspective client the NumericEntryField uses two different code paths:

1. An Intl.NumberFormat formatter bound to the session locale is used to render the value when the field loses focus.
2. A parser that does not honor the same locale strips/replaces the decimal character before re-formatting.

The formatter interprets 1,500.5 as one-thousand-five-hundred-and-five-tenths under es-MX and correctly outputs 1,500.5. The internal parser, however, is hard-coded to split on . and discards the leading 1, leaving 5005 for re-format. Re-formatting 5005 under es-MX yields 5.005 or, when combined with the original thousands comma, 1.500,5 – the exact string the user observes. The bug is reproduced regardless of whether the field is bound to a tag, a property, or a parameter; it is a client-side defect in the component itself, not the binding.

Public confirmation is documented on the Inductive Automation Perspective – Numeric Entry Field manual page and was acknowledged by Inductive Automation staff as affecting multiple customers on ticket IGN-6943. The fixed-in-version field on related ticket BUG-13153 was tentatively marked as 8.1.2, but the user-reported regression in 8.1.48 indicates the parser/formatter split was not fully resolved in that release.

Workarounds and Permanent Solutions

There is no project-property toggle to disable the bug. Apply one of the following remediations.

Option 1 – Pin the Session Locale to en-US (Quick Mitigation)

1. Open the Project Browser in the Designer.
2. Select Project Properties → General.
3. Set the Default Locale to en-US.
4. Bind the Perspective session locale to en-US via system.util.setLocale('en-US') on session start, or use a startup script in a Perspective Session Event.

This restores correct parsing at the cost of requiring all numeric input to use a period decimal mark. Suitable for North-American deployments or English-only plant floors.

Option 2 – Build a Custom Numeric Entry with a Text Field + Property Binding

1. Drop a standard Text Field on the view.
2. Set its inputType to text and disable the built-in number pad.
3. Create a custom property parsedValue with the binding expression below to convert the typed string to a double using the active session locale, then re-emit a display string.

// Transform expression on the Text Field's custom property
// Replace \. with , based on session locale, then parseFloat
if(
  toDouble(
    replace(
      replace({this.props.text}, ".", ","),
      ",", ".", 1
    )
  ),
  {this.props.text}
)

This decouples parsing from the NumericEntryField entirely. The trade-off is loss of stepper buttons, min/max enforcement, and built-in number keyboard on mobile clients.

Option 3 – Use a Component Method Override with a Change Script

1. Add a Change Script on the NumericEntryField's value property.
2. Inside the script, normalize the incoming string before any binding downstream reads it:

# Normalize a value typed under es-MX / pt-BR back to canonical
# double form, then push the canonical value into a tag
incoming = event.source.value  # may be a float or string
if isinstance(incoming, str):
    # Convert es-MX style "1.500,5" to canonical 1500.5
    cleaned = incoming.replace(".", "").replace(",", ".")
    try:
        canonical = float(cleaned)
    except ValueError:
        canonical = 0.0
    system.tag.writeBlocking(["[default]Tank/Level"], [canonical])
else:
    system.tag.writeBlocking(["[default]Tank/Level"], [float(incoming)])

The script catches the value after the component has mangled it, reconstructs the original number, and writes the correct value to the tag. The displayed value will still be wrong; if the display must also be correct, attach a second NumericEntryField bound to a memory tag and feed the canonical value back into it for display only.

Option 4 – Upgrade to Ignition 8.3 (Permanent Fix)

Per the Inductive Automation support thread on IGN-6943, the fix is gated behind the 8.3.0 release train. Customers who can schedule the upgrade should target 8.3.0 or later. Always review the Perspective – Numeric Entry Field documentation page at the target firmware version to confirm the locale field exposes an explicit override property before redeploying HMI screens.

Verification Procedure

1. Open a Perspective session in a browser and switch the session locale to es-MX from the user menu (or call system.util.getLocale() from a non-Perspective scope such as a tag event script to confirm the gateway locale).
2. Place a NumericEntryField on a test view, bind value to a memory tag, and set format to #,##0.00.
3. Type 1500,5 and press Tab.
4. Expected output on a fixed build: 1.500,50 (or your configured pattern).
5. Buggy build output: 1.500,5 followed by an immediate revert to 1.500,5 on next focus, or a value of 5005 written to the tag.
6. Confirm with system.tag.readBlocking(["[default]Test/Value"]) that the underlying tag holds the expected double, not a truncated integer.

Related Component Defects

See also the Ignition Perspective NumericEntryField Locale Bug Fix community write-up and the companion Numeric Entry Field textAlign Workaround article for related defects in the same component.

FAQ