“Isn’t internationalization premature optimization?” This is an objection that I’ve seen repeatedly, and one that I’d like to challenge. Premature optimization is building for use cases that aren’t requirements yet. Global reach is a general requirement. The choice of geographies hasn’t been made yet at the time you’re building your product. But if you don’t make it possible for users around the world to pull your company toward them, you’ll be forcing your company to bulldoze into those markets later on. You want to enable the gravitational pull of the market toward your product, not force an unnatural push. Localizability is a Type of Extensibility The purpose of extensibility is to build modular, maintainable software that can be customized by others. Knowing that local customization is a potential market enabler for you, why wouldn’t you build it in from the start? Internationalization, which is the process of making your software easy to localize, gives you the ultimate field of dreams effect. If you build it, they will come. But what if those users who want your product come from other markets, but they simply can’t get in because you’ve locked the doors? All too often, teams unintentionally tie bricks to their product’s feet by hard-coding things that prevent global adoption from happening later on. Internationalization is the skeleton key that can unlock the doors and enable your expansion into local markets whenever your company, or your global users, decide the time is right. All you need to do is make slight modifications to how you build your product from the beginning (see “27 Web Application Localization Best Practices.”) It might take some time to learn how to make them a standard and automated part of your development process, but once you do, you’ll be making your software internationally extensible. This is a pretty powerful concept! Imagine if you could make your software available quickly and easily to the world. What if you could give the power to the users to bring your product into their own local market? What if the software were written in such a way that people could drop in their own currency or date format, flip the interface around from right to left instead of left to right, and it were so easy to localize that local markets were empowered to pull you in? It would be one of the major market dynamic shifts of our times. Developers build extensibility into their software in order to be good citizens for future needs that they and others may have. They want to make it easy to make changes in the future, and extensibility supports that goal. Internationalization is no different. It’s all about making it easy to extend software into new markets someday. But engineers often think that localization is only about content, not about code. They see localization as something that can wait until later on. They often view it as just a marketing exercise, the act of bringing the software to market in a new country and language. The average engineer simply doesn’t know that the software they are building has to support localization from the most basic and fundamental layer of all — within the very lines of code they write. In reality, the engineers and UX researchers who build the product are the ones who have the most power to help the product reach its full global potential. Only they, and the work they do today, can prevent tomorrow’s blockers to local markets from being embedded in the software. Why Internationalization Basically Means Open APIs Developers have seen incredible success and adoption of their technology when they build clean, modular, and open APIs. Look no further than the well-known success stories of API-first company Stripe and the vibrant ecosystem of Slack. An easily localizable product can create the same ecosystem effect as those companies achieved. It enables others to create new offerings for different locales, so that people can hook into your software more easily and offer the same technology for different user groups in new geographies. Companies like Zapier have built a phenomenal offering by exposing business value from one service and enabling it to pass into another domain just by connecting different technologies together. Wouldn’t it be amazing if we could “bolt on” Japanese, French, German, and so on in a similar way? What if a software product didn’t have to be localized with so much hassle, but simply “locale-enabled” as easily as you can install an integration? We often think of APIs in terms of data, but not in terms of international user experiences. Yet the principle is the same — making it easier to connect two things together. All you need to do is prioritize making things easy to localize, and you’ll enable those other markets to connect with your product in a more seamless way. The market forces should pull your software in their direction. No more bulldozing your way into new markets to try to convince them to buy your software. Those markets should pull you in, simply because you’ve made it exceedingly simple and easy for them to do so. The reason I’d ask developers to reconsider internationalization and to view it like you view extensibility and open APIs is because the goals are ultimately the same. Truly great development teams want to enable others to do unexpected things with their software someday, so that it can achieve expanded reach. Because you want to enable your software to be a toolbox. Not a black box. Tweet WhatsApp Email Print