Uploaded image for project: 'ZK'
  1. ZK
  2. ZK-4198

Decimalbox implementation broken when using languages with comma as decimal separator

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • Major
    • 8.6.1
    • 8.6.0.1
    • None
    • None
    • ZK 8.6.1 S1

    Description

      On iDempiere project we made an implementation to allow entering numbers in Decimalbox with the comma separator corresponding to the user language.
      See IDEMPIERE-2003

      For example, if the user is logged in using language en_US then the default system works without problem.
      But when a user log in using language de_DE - zk has problems because the german keyboard returns a comma "," when using the numeric keypad - and zk is not able to interpret the comma as de decimal separator.
      So, our implementation figured out that situation and worked perfectly until version 8.5.0

      On version 8.6.0.1 we noticed that implementation is broken.

      After some debugging session I noticed the problem is in the commit 3bbb0da1 implemented to solve the ticket ZK-3704.

      The problem is in the line:

      final DecimalFormatSymbols symbols = new DecimalFormatSymbols(new Locale(localeName));
      

      That implementation looks wrong, because the decimal symbol is defined per country and not just per language.
      For example the same spanish language uses comma as decimal separator in Colombia (es_CO), but El Salvador (es_SV) uses a dot as decimal separator.
      So, the implementation in this case is just taking into account the language, not the country.

      Please note that:

      localeName = _locale.toString();
      new Locale(localeName);
      

      doesn't bring the same Locale, it could get similar locale if used something like:

      localeName = _locale.toString();
      Locale.forLanguageTag(localeName.replaceAll("_","-"));
      

      But I think that's not necessary, I found that the following patch solves the problem and even better implements the possibility to use locale per country too:

      diff --git a/zul/src/org/zkoss/zul/impl/NumberInputElement.java b/zul/src/org/zkoss/zul/impl/NumberInputElement.java
      index 02f8534518..3dada82d05 100644
      --- a/zul/src/org/zkoss/zul/impl/NumberInputElement.java
      +++ b/zul/src/org/zkoss/zul/impl/NumberInputElement.java
      @@ -146,13 +146,17 @@ public abstract class NumberInputElement extends FormatInputElement {
                      boolean useLocaleFormat = (format != null && format.startsWith("locale:"));
                      if (_locale != null || useLocaleFormat) {
                              String localeName;
      -                       if (useLocaleFormat)
      +                       Locale locale;
      +                       if (useLocaleFormat) {
                                      localeName = format.substring(format.indexOf(":") + 1);
      -                       else
      +                               locale = Locale.forLanguageTag(localeName);
      +                       } else {
                                      localeName = _locale.toString();
      +                               locale = _locale;
      +                       }
                              if (org.zkoss.zk.ui.impl.Utils.markClientInfoPerDesktop(getDesktop(),
                                              "org.zkoss.zul.impl.NumberInputElement" + localeName)) {
      -                               final DecimalFormatSymbols symbols = new DecimalFormatSymbols(new Locale(localeName));
      +                               final DecimalFormatSymbols symbols = new DecimalFormatSymbols(locale);
                                      Map<String, String> map = new HashMap<String, String>();
                                      map.put("GROUPING", String.valueOf(symbols.getGroupingSeparator()));
                                      map.put("DECIMAL", String.valueOf(symbols.getDecimalSeparator()));
      

      Can you please consider integrating this?

      Regards,

      Carlos Ruiz

      Attachments

        Issue Links

          Activity

            People

              rudyhuang rudyhuang
              RuizCarlos RuizCarlos
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - 4 hours
                  4h
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 4 hours
                  4h