In my first jobs out of college, I was part of software internationalization teams that were completely independent from the “core” teams. The core teams created the products for the original target locale (usually the United States), and the internationalization teams created branches of that product and performed all the engineering work to put the product in other markets. The core teams rarely worried about localization or data formatting. They didn’t concerned themselves with layouts or character sets. They rarely even allowed the internationalization teams to push the updated products back into their core code base. Weekly updates to the internationalization branch were always a merge-mess.
Those environments were frustrating and tedious. The worse thing is that those environments were common throughout the software industry. That was 25+ years ago.
After a few years out of college, I dreamed that internationalization would one day become everyone’s responsibility. I had hope that core product teams would take on internationalization work on their own and that my job as an internationalization engineer would eventually become obsolete. After more than two decades, the situation is better but not perfect.
After all this time, internationalization engineers are still required. I still find dedicated internationalization teams. The biggest improvement, however, is that core teams welcome code updates back into the core product repositories, and some teams even attempt to follow best practices. In the best cases, the internationalization teams provide globalization tools, best practice guidelines, and educational support. However, in most cases the internationalization teams still come in after all the core feature work is finished and retrofit existing code to be internationally-aware. This is almost always error-prone and expensive.
The ideal development environment is one in which internationalization is everyone’s responsibility. Retrofitting a product is simply not the best approach to add cultural awareness and localizability to products. It was time-consuming, expensive, and error-prone decades ago, and it still is.
Once every product and engineering team takes on the responsibility, internationalization actually becomes easier. Once the tasks become a regular, planned part of sprint deliverables, internationalization simply works better. That is, it’s easier to manage, integrate, and implement.
The truth is simple: when internationalization is everyone’s responsibility, you can create a better product.