mHealth trouble shooting: multiple languages
Insights from the Medic Mobile development team
By Marc Abbyad, Product Manager at Medic Mobile
Recently Medic Mobile built and launched its first Android application. Seeing a need from partners and users to use their smart phones to submit their monthly reports, we were quickly able to prototype and deploy an Android app based on ODK Collect — an Open Data Kit tool that is well supported by the Open Source Community. We added some extra functionality that catered to the needs of our users, such as submitting reports via SMS, and integrated it to the Medic Mobile toolkit.
After several internal iterations we felt confident that it was ready for a partner to test it with some users. Like with any new tool, we started with a small scale test to clear out any issues. Everything seemed to be working well for a couple of months — until last week. We heard from our partner that no reports were being sent for the past couple of weeks, which is always troubling to hear. I could reproduce the error on only one of my test phones, and I was stumped. Luckily, our partner’s tech staff had a key find; the error would disappear if the phone’s language was set to English instead of French.
With renewed focus we found that the difference between a successful and unsuccessful report was that the HTTP POST date header sent with the report was sent in French. This hadn’t been an issue before, so why now? Well, as the month of August rolled around it exposed a couple of issues, none of which were related to the weather. In French August is août, and somewhere along the line that special character û wasn’t encoded properly and the server rejected the report.
Given that we’ve had deployments of our tools using a variety of languages (eg français-French, español-Spanish, हिन्दी-Hindi, नेपाली-Nepali), we’ve often had to watch out for and deal with encoding issues in the past. This has made our dev team a bit of an expert on it. While we started testing the encoding theory we quickly realized we were solving the issue from the wrong angle. Aside from the ins and outs of character encodings, our team also likes to read w3.org standards, and realized that according to the standard the date should not be localized at all. For those interested, it is also case-sensitive and whitespace-sensitive. Ensuring that the date sent is properly formatted and in English fixed our issue.