Welcome
In today's globalized society, launching a product into multiple markets is becoming more and more a matter of "when" rather than "if". As such, it's important to architect and design software in such a way that it will be easier to support different market needs. This includes not only different languages and cultural conventions (like numbers and dates), but also different regulations and business needs (like different taxation and payment methods). The practice of making these design choices is called "internationalization" (or "i18n" for short) and is the focus of this course.
Why another resource about i18n? Software i18n has been around for several decades and lots of resources about it are already available. Alas, for someone new to global software development it may be daunting to distill the plethora of information out there and make decisions tailored to their company and product. Some great i18n information and best practices written some time ago are no longer applicable in a world of continuous delivery and fast iteration. Other resources are good introductions and may have a good academic background but are hard to apply to real-life projects.
In i18n there's no single recipe that should be followed for all products. Different product categories, media, and companies will likely have different i18n requirements and will need different approaches. Launching a global product can be a long journey. This course is intended to help set up a solid foundation that can be built upon. There are plenty of "how-to" resources online that can help solve technical implementation problems. For the most part product developers already have i18n capabilities in the languages and frameworks that they use. This course is more about learning what problems lie out there, what questions to ask, and how to make some crucial decisions early on that will make it easier to ship a global product later. You'll learn not only the general i18n challenges and solutions but also how to go about making decisions optimized and specific to the realities of your company and product. In particular, we'll focus on:
- The basic problem we're trying to solve and different challenge areas that your product may present
- The commodities we can build our solution on
- The general architecture challenges and decisions to make for a modern product (we'll assume a service-oriented architecture, Web + iOS + Android UX)
- Develop practical solutions for your product, including operational considerations for the whole application lifecycle (continuous testing and deployment).
Terminology
In this course we'll use the following definition:
- internationalization (i18n): the act, techniques, processes, tools, and libraries used to write global code that can be easily adapted to different market needs keeping the codebase maintainable (for example, without major duplications or spaghetti code).
- localization (l10n): the act, techniques, processes, tools, and libraries used to launch in different markets. It may include support for new languages, number, date formats, but may not be limited to that (for example, it may involve complying to legal requirements like GDPR). This traditionally refers to "geo-expansion" into new countries but depending on the product it may be bigger or smaller in scope. For example, some products may be global in nature and launch in all countries on day 1 but add more languages later on. Other products may be ultra-local and may launch in a single city. For them geo-expansion to another city may involve complying to different city regulations, or integrating with different systems.
- globalization (g11n): this is the combination of the above two and brings the classic g11n = i18n + l10n formula. Effective globalization involves additional activities beyond software development. For example, language strategy, marketing strategy, and support strategy.
The irony of an industry whose mission is to help connect different cultures, is that it has not agreed and standardized on a common terminology. As there is a fine line between these categories and they're open to interpretation, you will often hear these terms used in the wrong context. Be also aware that some companies may standardize on a different meaning. For example, Microsoft uses "internationalization" for g11n and "world-readiness" for i18n.
Let's get started
I18n can be overwhelming to someone new to the problem because it's one of those fields where things are not always unmistakably right or wrong. While some definitely are, other are debatable and multiple acceptable options may exist. There is also a level of pragmatism that is acceptable for certain products when trying to not get perfect in the way of good enough.
Because every product and company may need to make different decisions and compromises based on their situations, it good to first understand what are the most common problems we most likely need to solve. We'll then move on to see what different alternatives may be and what best practices and industry solutions may be applicable.