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. </rant>
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.
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.
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.
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
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?
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.