I’m Brighid; I’m an engineer at Flowroute, and I’m here to talk about an extraordinarily difficult problem: words. As an engineer, there are plenty of difficult problems one can take on, yet the most difficult of them are those that we think are easy. Problems like cryptography, distributed processing, and machine learning attract smart engineers hankering for a challenge. Amazing and important feats have been achieved by such engineers, and they’re rightly celebrated. By contrast, most engineers expect questions like “what time is it?”, “what country am I in?”, or “what is your name?” to have easy, tractable answers that can readily be translated into programmatic rules. As the links should suggest to you, though, all of these things are ferociously complicated problems that approach intractability because their roots are in the infinitely prickly thorn-hedge of human social relations.
We engineers do very well with complex algorithms when we expect them to be complex. However, when we expect problems to be simple, we build simple solutions—which break when exposed to the full complexity of the world. Engineers are merely grumpy about this. Business folks, on the other hand, tend to frown disapprovingly and say “You’re leaving money on the table” in the same what-the-heck-are-you-doing voice as they would use to say “Inhaling mud is bad for your health.” They’re right! A system that only understands the world through a simplification, cannot meaningfully engage with parts of the world that don’t fit the simplification—or to restate it, has artificially reduced the size of the market it can serve. Removing such artificial reductions is a sensible business move.
Developers must consider global language diversity
One of the harshest ways an Internet-based business can find its market limited, is by language barriers. American businesses that grow to serve a worldwide customer base often find that they have assumed that other languages in the world are more or less like English. This is not the case, especially not in terms of how those languages are translated back and forth from a living cultural machine to an encoding in computer-readable data. Worse, because of how engineers tend to assume that words are easy, businesses are prone to sending customer-hostile messages when their systems fail.
Avoiding this scenario can be far easier and cheaper than hiring a team of translators, which is what business folks tend to think of. You can make your service more hospitable to the worldwide market in gradual steps; huge sweeping changes are not your only option. One of the easiest things you can do is to change how your system talks about names. There are far too many systems in the world that, when confronted with Frau Langestraße, Sra. Muñoz, or Fru Bønne, tell them that their name is wrong. This is absolutely a customer-hostile experience: people’s names are extraordinarily personal, and it is alienating to be told that your name is somehow wrong. Avoid this pattern. Say “we don’t understand what you told us,” or use another phrasing that does not blame the user.
More broadly, assume as little as possible about the form of users’ names: for example, don’t assume a minimum length to names (Jo and Ng will thank you). Their name is what they tell you it is; their legal designation is not necessarily the same and should only be demanded if it’s absolutely essential to your business—and having to take their money doesn’t count as essential, all you need to do is pass on the name they told you to credit card processors.
Code to accommodate differences in alphabets, addresses, and context
On the engineering side, the challenge of handling names is not insurmountable when it is regarded directly as a challenge. American businesses are particularly likely to stumble, though, when confronted with Asian alphabets and with right-to-left scripts: therefore test your system with as many diverse languages as possible. Even if a piece of the system behaves undesirably and cannot yet be fixed, it is much better to know what happens when it fails than to be surprised.
You will often want to know customers’ locations along with their names: here too it’s easy to assume that things work in other places the same way they do in America. Don’t make a system that can only understand American addresses. Just as with other differences across language barriers, “where are you” not only has a different answer elsewhere, but a different kind of answer. Be prepared for many kinds of addresses.
Internationalization is a difficult task for all businesses, but it doesn’t need to be an intimidating monolith: there are cheap, easily-accomplished steps you can start with that tell your customers that you are not dismissing them and consciously rejecting their business. From there, you can proceed to the work of engaging with those customers—and not leaving money on the table.
