Note on change in behavior of inputs that use decimals

A new change is being currently rolled out that changes how decimal inputs are parsed in the Input element (any decimal input, so that includes Currency, etc). I wanted to write this post to explain how it works, the rationale, and answer any questions people may have in case something is unclear or ambiguous.

The current (soon to be previous) way decimal inputs are parsed is based purely on the app’s language, and a language convention (which we did not design). In practice this can be mildly annoying. In spanish, for example, someone could write “1.5” and the language convention dictates that “.” is the thousands separator, so that should not work at all, since technically it does not make sense as a number. We currently just get rid of the “.” and interpret it as 15 which is still not great because we could reasonably say that the user meant 1.5. There are plenty of such examples where relying solely on the language convention is too constraining for the users.

The new (soon to be current) way decimal inputs are parsed uses a combination of

a) trying to guess what the user intended to write and
b) the app’s language and a language convention

The new parsing mechanism basically looks at the number on its own and guesses what the user was trying to write, then, in combination with the language specific convention and the app’s language creates a final determination of what the user meant. In practice this looks like the following.

  1. ‘Common sense’ parsing: In all languages, “1,234.5” and “1.234,5” will be parsed as 1234.5 even though, say in spanish, these should be nothing and 1234.5 respectively.
  2. If there is no clear ‘common sense’ interpretation then we disambiguate based on the language settings. For example, in spanish “1.500” would be 1500 because, in spanish, the language convention is that “.” is a thousands separator and in that number it is placed in a position such that it can be a thousands separator. One could argue that the user meant 1.5 but because it is ambiguous, we default to the language convention.

Note that this can result in users experiencing some perhaps unexpected behavior. For example a user in spanish could type “1.51” and that would be parsed as 1.51 but then if the user adds a 2 at the end to make it “1.512”, it will be parsed as 1512, and then if the user added a 3 to make it “1.5123”, it would be parsed as 1.5123. We understand this is not ideal yet and we will keep working to improve this, but we believe the benefit from making the input more flexible and tolerant will be a better experience for users. Personally, I hate when I’m on a website and start writing a decimal number only to realize I should be using a “,” instead of a “.” for my decimals. This feature is intended to reduce the amount of times users find themselves in that situation.

Finally, note that you can avoid the potentially inconsistent behavior if you know that your users will only ever need decimals up to 1,2,3, or 4 digits you can set that up via the Decimal place dropdown in the Input element.

Any thoughts, questions or concerns are welcomed

6 Likes

Couldn’t we just set that for the input or as an app configuration? :thinking:
In an app of mine I have a user type 1,34 to mean a decimal. However, one user had his android phone only allow him to type 1.34, no comma was given to him.

I had then to make a plugin that swaps values, in this case I used it to whenever that user (or any other with the same issue) typed a dot, it would be instantly replaced by a comma.

It would have helped if I had a setting to say “always treat comma and dot as a decimal separator” and forgo the ability to understand thousands separators, as I’d have then my users to simply type 1500 for that.
Having options would be at least more reliable than that unexpected behavior. I mean, how could I tell what behavior would be applied? Looking from the outside as a user this seems inconsistent and doesn’t actually helps.

Anyway I’m a fan and I always like the improvements you make, I’m just commenting on this one to maybe get a more consistent feature since this has always been an inconsistent point to me and a few people that I talked to.

Or maybe this can be somehow used to get a consistent behavior from the number input and I just need additional explanation, who knows.

7 Likes

I agree with @vini_brito. I am currently localizing my app and I agree this would be the safest approach.

1 Like

Note that this can result in users experiencing some perhaps unexpected behavior. For example a user in spanish could type “1.51” and that would be parsed as 1.51 but then if the user adds a 2 at the end to make it “1.512”, it will be parsed as 1512 , and then if the user added a 3 to make it “1.5123”, it would be parsed as 1.5123 .

How in the world can we code something that works with the above situation? Typing in 1.512 and parsing it as 1512 is really like watching a comic book being unfolded.

I hope I’m exaggerating and that we won’t notice a big difference, good luck to all people using Stripe btw :smile:

1 Like

Hi, thanks for the feedback and suggestion. I think you bring up a good point. I’ll look into it on our end.

Well that behavior specifically has not changed. In english 1.512 will still be interpreted as 1.512, in spanish both the old and new behavior would interpret 1.512 as 1512

With regards to the specific example you brought up, your user should now be able to type 1.34 or 1,34 and they will both be interpreted as 1.34. The inconsistent behavior only happens when a user uses the language’s thousands separator and it is placed in such a way that it actually makes sense as a thousands separator

1 Like

Hi, Gerry, This is great. will this be on the next dedicated box update?

Also note that, if you enforce a limited number of decimal digits, you do not get inconsistent behavior. If you know that your users will only ever type numbers of up to 1,2,3 or 4 digits you can set that up in the Decimal Place dropdown

@muneer.hameer yes this should be updated on dedicated boxes sometime tomorrow morning automatically

1 Like

Okay, I’m still a bit confused, if I allow users to type as many digits as they want, how would that go?

Depends on both the language setting of your app and the character they are using for their decimals. If the app is in english and they are using “.” it will behave as you would expect, always interpreting the “.” as a decimal. If they use a comma instead, whenever the comma splits the number by thousands, it will be interpreted as such. So 1,2 will be 1.2 but 1,234 will be 1234.

I realize this is not ideal but the old behavior in english would have ignored commas alltogether, so both 1,2 and 1,234 would have ignored it and 1,2 would have been 12. Now only 1,234 ignores it

Got it! I think this phrase nailed it. An improvement, for sure, will help with decimals.
Well, thanks for that.

2 Likes

Concerning the particular model you raised, your client should now have the option to type 1.34 or 1,34 and the two of them will be deciphered as 1.34. The conflicting conduct possibly happens when a client utilizes the language’s thousands separator and it is put so that it really bodes well as a thousands separator

1 Like