In the tech industry, we are interested in building products that can be adopted and meaningfully understood by a global audience. Development and product teams are often coming from diverse backgrounds and cultures and why should we assume our user base is any different?
As teams and products are becoming increasingly international, it is important for product teams to be mindful of reaching a broad audience. It is common for companies to refer to a vague offering of localization or internationalization without being clear in their own understanding of the relationship between these two concepts. They are inherently connected; however, localization and internationalization are two approaches to the problem of reaching a global audience.
#Localization (L10n)
Localization (often denoted as l10n) refers to a product or service meeting the needs and standards of a specific country, region, or userbase.
The most common example of localization is a product being translated into different languages to reach a broader user base. Successful localization can mean more than a direct translation of your website, which can be an excellent first step, to ensuring that the user experience is consistent across user bases and details such as currencies, units of measure, and numbering systems are consistent with the local standards.
Other important considerations are whether a language should be read left to right or right to left or even displayed in vertical columns. Beyond just interface differences, companies can also make distinctions based on differing legal frameworks, a key example being privacy. Privacy and information are valued and regulated very differently from culture to culture and in some cases where data is stored can be a key differentiator between products.
#Internationalization (i18N)
Internationalization (often abbreviated as i18n) is a step that often predates localization in product development. Internationalization is designing a product or website in such a way that it can be easily localized later down the line.
Essentially, internationalization implies that companies are planning ahead to ensure that their product can be easily localized further in the future. The most important parts of internationalization occur in the product design and the actual code to make sure that teams are planning ahead to support this functionality. Considering providing support for features that will not be necessary until localization occurs, separating localizable elements from source code are just some of the elements that will be critical during the internationalization of the product design and development process. Internationalization helps teams avoid retrofitting solutions or needing to start from scratch as their product grows.
#Why is it important and how do I make sure my team is not left behind?
Creating a seamless user experience that matches the expectations of the local environment can be critical in getting the broad user adoption that companies strive for. Teams should plan for the internationalization of their product from the start, even if they choose not to implement it until further down the line.
It is always easier to account for this functionality when making your initial tech stack decisions rather than having to migrate because the chosen system does not support the critical feature - an important consideration to make when looking for a Headless CMS with localization capabilities. Many companies, such as Hygraph, allow you to add more locales as your plan grows so that you are only paying for what you need when the project is just starting out. Hygraph allows teams to follow this best practice of starting with internationalization and moving to a localized project when they are ready. With Hygraph, teams can build a GraphQL schema with all of the localization capabilities so that teams can choose whether to use this functionality from the start of their project or easily add locales when they need them.
Extra locales can be important even within the same country, in places like Canada or Belgium, where there are multiple languages spoken or when you are targeting people who speak the same language but have different currencies or measurement systems, such as comparing the United States with Britain. Within the DACH region itself, simply supporting /de isn’t sufficient for granular localization, given the common conventions extend to /de_de,/de_en, /at_de, at_en, /ch_de, ch_en, /ch_fr, and /ch_it to further support for the language, as well as the locale.
Ultimately, internationalization, and later localization, are critical features that can just as quickly push users away if done poorly as it can draw more users when done properly. When users see standards and languages they are familiar with are offered, it automatically makes them feel more at ease and comfortable using the product and will help build user loyalty.
For more information on how to use locales with Hygraph, check out our documentation on localization here or reach out to our customer success team.