In a globalized world, our software companies serve the needs of customers that happen to have their business in multiple geographical regions. Hence we developers need to ensure that the software we build is usable in different languages and cultural contexts. In other words, our software must be designed with internationalization (i18n) in mind. This includes the employment of Unicode character sets, flexible layouts (allowing bi-directional texts), or externalizing strings that vary across languages. Localization (l10n) is a process of using i18n to adapt the software to the locale, language, and cultural requirements of a given market. Very good definitions of internationalization and localization can be found in this W3C article.
Moreover, UX, Engineering, Product Management, and other relevant stakeholders must ensure that the level/depth of i18n and l10n is consistent across the product suite. For example, it can be very user-unfriendly if one part of the UI is in Spanish while another is in English. It can be even misleading if one product uses commas as a thousand separator while the other as a decimal separator. Not to mention the American date format mm/dd/yyyy vs. the European dd/mm/yyyy. This is especially problematic in embedded use cases, where the user has no way of telling where one UI ends and the other begins.