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

Decimalbox implementation broken when using languages with comma as decimal separator

XMLWordPrintable

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

      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

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

              Created:
              Updated:
              Resolved:

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