I came across this report of a bug with iOS Messages voice transcription feature and found it to be rather interesting. Cutting to the chase: Messages will silently fail if voice transcription tries to use an ampersand (“&”) as part of a proper name.
The example that started the investigation was a message containing “Dave and Busters”. This is the name of a U.S. restaurant chain with the proper name “Dave & Busters”. The Apple transcription feature smartly applies the correct trademark name using the ampersand, but Messages silently rejects the message containing the “&” as invalid XHTML.
Oh dear, Apple: that is embarrassing. But also all-so-human.
The problem with special characters
I worked for years as a professional programmer. One of “common” errors made in code is caused by inputs that are not properly ‘sanitized’ in various ways. “Sanitizing” is a general term that covers making sure text inputs do not contain characters that can cause unintended operations: things like SQL injection that cause entered text to be interpreted as commands.
One category in this ‘sanitizing’ process that is a regular hassle is that of special characters. Things like ampersand (“&”) and slash (“/”), but also including accented characters in various languages. Users in particular will often cut and paste strings containing such characters with no ill intent whatsoever: for example, to include a properly accented French phrase.
But none of these characters are actually ‘legal’ in XHTML, and must be converted to ‘escaped’ (coding) form. This becomes a pain after proper conversion because later viewing of that same data may not render the expected characters. For example, “Dave & Busters” becomes “Dave & Busters” which is not what the user expected, so you have to be careful to make sure that the UI elements you use present the escaped content the way your users expect it.
This whole process is one that oftentimes gets broken in complex development chains: basically, even very smart people make mistakes particularly when multiple teams are involved. That is exactly what happened here: very smart people worked on the translation logic to correctly convert voice input into proper names, and very smart people worked on the message display logic to prevent incorrectly formed XHTML from displaying to avoid security flaws.
But these very smart people produced a very dumb error by not necessarily working together when they should have. Either the translation logic should have escaped the characters, or the message display logic should have done so. At a minimum, some kind of error should have been displayed e.g.: “Message cannot be displayed due to improper XHTML.” That would have at least given the user a clue that a message had been lost.
Strangely, it warms my heart to know that even a very rich and very detail-oriented company like Apple can make a silly mistake like this. Having worked through a few such bugs on a much less well-funded project I can feel at least slightly vindicated that such things can happen even with all the expertise money can buy.