fix: normalize Unicode minus sign in GSP number formatting for locale compatibility

[jamesfredley]

Summary

Fixes #15178 - Negative numbers with Norwegian locale (and similar locales) produce Unicode minus sign (U+2212) instead of ASCII hyphen-minus (U+002D) when rendered in input type=number fields via the f:field tag. This violates the WHATWG HTML spec which requires ASCII hyphen-minus for valid floating-point number values.

Changes

Source (1 file):

• grails-fields/.../FormFieldsTagLib.groovy - Modified getNumberFormatter() to normalize DecimalFormatSymbols.minusSign to ASCII hyphen-minus. This method is called exclusively from renderNumericInput() which outputs input elements, making the fix isolated to the input rendering pipeline.

Tests (1 file):

• grails-fields/.../DefaultInputRenderingSpec.groovy - Added data-driven Spock test covering 5 locales (nb_NO, nn_NO, sv_SE, fi_FI, en_US) to verify negative number input values use ASCII minus.

Design Decisions

Per reviewer feedback, this fix is now scoped to only the FormFieldsTagLib input rendering path:

• No changes to FormatTagLib.formatNumber - This is a display tag (g:formatNumber) and should preserve locale-specific formatting including Unicode minus.
• No changes to ValidationTagLib.formatValue - This is used in both display and form contexts and should not be globally modified.
• Fix only in FormFieldsTagLib.getNumberFormatter() - This is explicitly input-specific, called from renderNumericInput() which produces input elements where the WHATWG spec mandates ASCII minus.

Technical Details

• Java DecimalFormat uses DecimalFormatSymbols.minusSign which varies by locale (e.g., Norwegian uses U+2212)
• The WHATWG HTML spec defines valid floating-point number for input type=number as requiring U+002D (ASCII hyphen-minus)
• The normalization is instance-local (per-formatter), not mutating any shared state
• For locales that already use ASCII minus, the assignment is a no-op

Verification

• All DefaultInputRenderingSpec tests pass (including 5 new locale tests)
• All existing grails-fields tests remain passing
• No changes to display formatting behavior (g:formatNumber, g:fieldValue)

[Copilot]

Pull request overview

Normalizes the minus sign used when formatting negative numbers in GSP-related taglibs so generated values are compatible with HTML <input type="number"> (which expects ASCII -), fixing locale-specific formatting issues such as Norwegian nb-NO emitting U+2212.

Changes:

• Force DecimalFormatSymbols.minusSign to ASCII hyphen-minus (U+002D) when formatting numbers (including fallback formatting paths).
• Apply the same normalization in ValidationTagLib.formatValue() and FormFieldsTagLib number formatting used for field rendering.
• Add regression tests (JUnit + Spock) covering negative numeric outputs under nb_NO.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
grails-gsp/plugin/src/main/groovy/org/grails/plugins/web/taglib/FormatTagLib.groovy	Normalizes minus sign in formatNumber and its ArithmeticException fallback formatter.
grails-gsp/plugin/src/main/groovy/org/grails/plugins/web/taglib/ValidationTagLib.groovy	Normalizes minus sign both for custom-editor formatting and DecimalFormat formatting in formatValue().
grails-fields/grails-app/taglib/grails/plugin/formfields/FormFieldsTagLib.groovy	Normalizes minus sign for NumberFormat used to populate numeric field values.
grails-gsp/plugin/src/test/groovy/org/grails/web/taglib/FormatTagLibTests.groovy	Adds JUnit regression tests ensuring ASCII minus output for negative values in nb_NO.
grails-gsp/plugin/src/test/groovy/org/grails/web/taglib/FormatTagLibSpec.groovy	Adds Spock regression test for Norwegian locale minus sign behavior in formatNumber.
grails-gsp/plugin/src/test/groovy/org/grails/web/taglib/ValidationTagLibSpec.groovy	Adds Spock regression test for ASCII minus in g:fieldValue under Norwegian locale.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jdaugherty]

These changes seem to not be the right approach:

1. they assume all output is for an html input
2. they do not handle only that locale case, but rather them all
3. they are not isolated and specific - we should be changing the property binding and output for only this locale and only where used in an input
4. they have side effect behavior; wouldn't it be better to implement or extend our own formatter and document these rules? how have others handled this? does the formatter already have an ascii solution?

This change feels rushed and hacky because its handling a specific case in generic code

[jamesfredley]

Addressed all review feedback. The fix is now scoped to only FormFieldsTagLib.getNumberFormatter() which is explicitly input-specific (called from renderNumericInput() for HTML input elements). All changes to FormatTagLib, ValidationTagLib, and functional tests have been reverted. Added data-driven Spock test covering nb_NO, nn_NO, sv_SE, fi_FI, and en_US locales.