Plus sign on positive numbers

[balticSD]

The should be an option to show plus sign on positive number.

Example: +3535.3534
Option: LeadingSign

[rxaviers]

Please, can you check if UTS#35 Number section has any reference to this? Does any specification/library/language implement this property?

What's your use case please?

[balticSD]

• 2.3 Number Symbols
  • minusSign - Symbol used to denote negative value.
  • plusSign - Symbol used to denote positive value.

Case:
Formating a percental missmatch = -0.1067 | 0.3412 = "-10,67%" | "+34,12%" (Germany)

[rxaviers]

The plusSign you have mentioned above has nothing to do with your use case. It is for Scientific Notation use only (note the "localized plus sign" mentions).

Anyway, you can "tell" Globalize that you want such a custom pattern by using the below overload (after you have loaded the standard CLDR data, this code will overload the percentage pattern in memory).

Globalize.load({
  "main": {
    "en": {
      "numbers": {
        "percentFormats-numberSystem-latn": {
          "standard": "+#,##0%;-#,##0%"
        }
      }
    }
  }
});

Globalize("en").formatNumber(0.5, {style: "percent"});
// > '+50%'

Globalize("en").formatNumber(-0.5, {style: "percent"});
// > '-50%'

@srl295, @JCEmmons, please does ICU provide any mechanism to allow what @balticSD asks?

[srl295]

@rxaviers sorry for the late response! Yes, it does allow it. It's just a positive prefix, so pattern +#;-# works as you noted. In C++ you can call setPositivePrefix(UnicodeString("+")).. does that answer the question?Not sure what you are asking for.

[srl295]

There are unscheduled bugs for this: CldrBug:2295 and IcuBug:7085 - please comment on the CLDR one (for use case) and the ICU one (for API suggestions…)

edit That's the wrong bug number, actually see CldrBug:8732 ( and my later comment below)

[rxaviers]

@srl295 Thanks, it definitely helps.

@balticSD, so the quick way to accomplish what you need (i.e., using Globalize now) is to load the pattern as suggested above. This is cumbersome if you need to support several locales. Because, it would require you to patch the data for all such supported locales.

The long-term (though more solid) way to accomplish this is to weigh in the CLDR ticket that @srl295 has posted above, push for a UTS#35 update, then we get it implemented on Globalize. I know this doesn't sound much fun. But, it's also not as impossible as it sounds. 😝

[srl295]

Doesn't have to be that long a term. Once cldr clarifies you could implement in anticipation, as you like. You might want fallback behavior if back level cldr is used anyway.

[srl295]

@rxaviers @balticSD OK so! The ticket CldrBug:8732 is actually already in review for CLDR. The other was a duplicate which got missed (now closed).

See spec changes at here (tr35.html) and here (tr35-numbers.html) - please feel free to review (it's in review) and comment on the original ticket.

[rxaviers]

Thanks @srl295, I've left a couple of comments there ☺️

[rxaviers]

Note to self: html link: http://unicode.org/repos/cldr/trunk/specs/ldml/tr35-numbers.html

[balticSD]

Sorry for my late response. What is the conclusion now? "Globalize.load({" is no solution for me because I have to format different numbers in different way. And "load fomat 1 > format > load format 2 > format..." is a messy workaround. So as option it is not planed?

[rxaviers]

@balticSD, please see http://unicode.org/cldr/trac/ticket/8732. All my questions have been answered by Mark Davis and CLDR has been updated accordingly. So, I think we are good to add this feature for Globalize. Would you be willing to champion it? If so, I encourage you to start by suggesting how the Globalize API should look like, then to submit a pull request with the implementation.