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

Decimalbox implementation broken when using languages with comma as decimal separator

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 8.6.0.1
    • Fix Version/s: 8.6.1
    • Component/s: None
    • Labels:
      None
    • gh.sprint.customfield.default.name:
      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

        Issue Links

          Activity

          Hide
          rudyhuang rudyhuang added a comment - - edited

          Fixed since 2019/01/21

          Show
          rudyhuang rudyhuang added a comment - - edited Fixed since 2019/01/21

            People

            • Assignee:
              rudyhuang rudyhuang
              Reporter:
              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

                  Agile