Trying to make a point. or: You must have too many stickers

Because I found another bug you hid in the iOS app.
It starts at this screen:

Now you want to bump the time down a bit because reasons:

But behold! You don’t live in the United States but a country where decimal places are behind a comma rather than a dot. Bummer! The app will only accept something such as this:

Tough luck trying to enter that. You can’t. If you accidentally deleted past the “,” in the text box you are on your own. Also there is no “:” as in the other part of the app.


Weird. So the app gives you a keyboard that has a localized symbol on it instead of a period?

Weird indeed! I wish countries used something other than , or . as the decimal separator :stuck_out_tongue_winking_eye:

Jokes aside it’s probably just an oversight of the l10n setting:


1 Like

Thanks so much for reporting the bug! Is changing the region in iOS settings a workaround? (Not to say it’s necessarily an acceptable workaround, just to help confirm the diagnosis of the bug.)

It is indeed:


There’s gotta be some locale that has some weird symbol instead…

So is the right answer to allow comma entry, or change the keyboard?

I would argue that it is nor should it be the business of Beeminder to care for how the datapoint looks (= the visible textual representation). Instead the only thing Beeminder should care about is what the datapoint actually is (= the value).
English is just one language on the planet and such is the cultural expectancy to use “.” as a decimal separator.
Operating systems and programming languages abstract over this and have in fact done so for a long time (e.g. Windows 98 if memory serves).
Commonly your programming language of choice offers some way to parse texts in a locale aware way.

Again this is just my opinion. And Beeminder is not the first one to fall into this. In fact also on iOS MyFitnessPal is notorious for messing this up, too. Which is especially dumb because instead of outright refusing it tries to make sense of it (You know, just remove these funny dots from those letters, who cares even! Murrica!). And then instead of adding 1.5 bars of chocolate you added 15 bars. Because… let’s just remove everything that’s not a digit or “.” right? Locale pff, who gives a damn.
But wait, there is more: Google Maps on Android. When you start typing in an address it suggests to complete it and then immediately zooms in on it. Now where’s the problem with that? I ma tell you where’s the problem: Not all countries have their house numbers in front of the street name. Some have it afterwards. And the auto completion does not care for house numbers. Fortunately with Google Maps even in Europe you can put the number in front and it still works even though that’s clearly not a valid address.
Oh I got another one: Google Calendar (Yes, Google is really bad at this): You can (on the website mind you – because “of course” the “native” apps have different functionality) you can sort of free form enter a new appointment in a text box.
Except… try that with anything else than the US date format. You can set your OS, browser, your google account, your calendar settings, everything to German and it still will assume you use the US format.

Related: One example where the representation would matter is house numbers: You can find house numbers with letters attached (e.h. 10a next to 10). These are normally the result of a property being split after the fact and so you find a 10a wedged in between a 10 and a 12.

Unrelated: I once was a very avid Android user but all these annoyances just piled up. Eventually my Nexus One once started to read out aloud XML code (1) it received from the Google servers while navigating. This is not a joke. It was reproducible so I was actually able to catch it on video. Go watch it. As you might be able to make out Android did actually go to the trouble of using a German text to speech engine. And also messed up the sampling rate. Which is why the pitch is so low.

(1) it’s just a string, right? I can read strings out aloud! Yay! I hate stringly typed code.

Types matter!

1 Like

So the keyboard should have a locale-aware key for the decimal separator, and Beeminder should parse the text entered in a locale-aware way?

That’s going to lead to problems when the two don’t match up…

:us: :us: :us:

What’s wrong with modifying the text so it uses English letters instead of umlauted ones and Eszeds?

We have fractions here sometimes, so you might see a 2315 1/4, 2315 1/2, and 2315 3/4 in between 2315 and 2345.

So does every other bug in the operating system that you are running on. Because that’s what that would be. The keyboard is provided by the OS (which is why you see a “,” in there in the screenshot). Right now Beeminder expects a “.” because it does not parse this in a locale aware way. If you instead use the methods provided by your programming language that respect the OS settings it is guaranteed to match up.

1 Like

Sorry my reply earlier got so long and ranty. Just don’t get me started on all the multitude of ways the world gets text encodings and locales wrong. Also @zedmango go watch that video I added just now. You won’t regret it.

1 Like

Wait, what? I would think Beeminder is telling the OS what keys to put on that keyboard and Beeminder has the option to tell the OS “period,” “comma,” or “locale-aware decimal separator.”

No I would love to hear more!

Typically the app developer does have some leverage about details of the keyboard. But the keyboard itself is provided by a different entity.
On both Android and iOS you can actually add 3rd party keyboards which are essentially other apps providing a keyboard on demand.

The standard keyboard on iOS does respect the locale and I am willing to bet that the Apple Design Guidelines rightfully demand the app developers should do the same. But I have not actually ever developed an app for iOS (for Android I have though) so take everything I say with a grain of salt :wink:

1 Like

Also this is really great lecture on the subject of the “ugly American view of strings”:
leading to:

1 Like

Well look at it like this. Suppose Beeminder wanted to use a format that included a tilde as a separator. So users would enter, say, 2~4~7.

Beeminder should then tell the OS “generate a keyboard with 0-9 and tilde keys” and parse the received text assuming a tilde is a separator.

It’s fine for Beeminder to choose a comma or period instead of a tilde. It’s even fine for Beeminder to query the OS for a locale and choose a symbol based on that locale.

But what seems like a recipe for disaster to me is to separate the questions of what symbol to put on the keyboard and what symbol to use to parse the input. That seems like what’s happening now, right?

Yes and no.

I of course don’t know what whoever made the iOS app was thinking but I propose that it simply did not occur to them (no offence meant) that this problem existed and that there would ever be anything other than “.” on these keyboards.
Hence the question what symbol to use to parse the input likely never got asked in the first place.

1 Like

Agreed. They probably called an OS function that brought up a decimal entry keyboard, which referred to a locale setting somewhere.

Now the problem is that Beeminder needs to figure out what that exact locale setting the keyboard used, as opposed to querying on its own, which may give different results.

And how is that a problem?
Just ask your friendly runtime environment:

1 Like