Tapestry
  1. Tapestry
  2. TAPESTRY-827

Incorrect parsing of decimals in French locale by NumberTranslator

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 4.0
    • Fix Version/s: 4.1.1
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      Tomcat 5.0, jre 1.4.2, ie 6.0

      Description

      When validating numbers using NumberTranslator with French locale incorrect parsing of a user entered decimal occurs. Example, 55 000 results in a String value of 55 being returned by NumberTranslator. Reason being that the user enters a space (0x20) as the grouping separator, however, java.text.DecimalFormat expects a non-breaking space (0xA0). The tranlsator should replace grouping separator spaces with non-breaking spaces?

        Activity

        Hide
        Jesse Kuhnert added a comment -

        Appears to be working correctly for me on both client and server.

        There is one catch though. By default DecimalFormat doesn't allow grouping separators to exist in the input string, so if you want that ability you'll have to give it a pattern like "#,###" where the comma will be replaced by whatever grouping separator is used in the current locale.

        Show
        Jesse Kuhnert added a comment - Appears to be working correctly for me on both client and server. There is one catch though. By default DecimalFormat doesn't allow grouping separators to exist in the input string, so if you want that ability you'll have to give it a pattern like "#,###" where the comma will be replaced by whatever grouping separator is used in the current locale.
        Hide
        Jesse Kuhnert added a comment -

        A very large company is adding i8ln support into dojo for us already, so the client side issue will be resolved by the time tap 4.1 comes out.

        Is there a resolution on this one? I'm a little confused from the comments what everyone is expecting.

        Show
        Jesse Kuhnert added a comment - A very large company is adding i8ln support into dojo for us already, so the client side issue will be resolved by the time tap 4.1 comes out. Is there a resolution on this one? I'm a little confused from the comments what everyone is expecting.
        Hide
        Leonardo Quijano Vincenzi added a comment -

        I don't think that's a good idea, since locale-based grouping of numbers is most useful precisely when entering data (money data, for example). It allows users to easily check if the number they entered is ok. For example, what's easier to read?

        1456879.34

        or

        1,456,879.23

        ??

        When editing large batches of data, not using the grouping separator would be error-prone.

        Show
        Leonardo Quijano Vincenzi added a comment - I don't think that's a good idea, since locale-based grouping of numbers is most useful precisely when entering data (money data, for example). It allows users to easily check if the number they entered is ok. For example, what's easier to read? 1456879.34 or 1,456,879.23 ?? When editing large batches of data, not using the grouping separator would be error-prone.
        Hide
        Raphael Jean added a comment -

        There is a related problem with client-side JavaScript validation code: it uses the isNaN() method to validate a number, which doesn't support localized decimal and digit grouping separators.
        What about disabling digit grouping altogether? (NumberFormat.setGroupingUsed(false))
        This would fix client-side and server-side parsing problems with integer numbers in all locales.
        Problems still remain for floating point numbers.

        Show
        Raphael Jean added a comment - There is a related problem with client-side JavaScript validation code: it uses the isNaN() method to validate a number, which doesn't support localized decimal and digit grouping separators. What about disabling digit grouping altogether? (NumberFormat.setGroupingUsed(false)) This would fix client-side and server-side parsing problems with integer numbers in all locales. Problems still remain for floating point numbers.

          People

          • Assignee:
            Unassigned
            Reporter:
            Michael Thronton
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development