Where does programming come into play in terms of internalization and localization? I asked myself that question some time ago, and I’ve come to realize that it is a key part of communication talking to developers, engineers, vendors, and linguists in end-to-end localization. Without that technical understanding, there is a risk of missed opportunities and misalignment that can potentially affect the project as a whole. I wanted to do a quick recap before reflecting further on how programming intersects with internalization and localization.
Internalization (I18n)
It is usually a corporate strategy to make products and services as adaptable as possible, allowing them to enter different national markets with ease. For example, companies prepare software for multiple languages and regions during the development stage so that it can easily adapt to any language or region later without rewriting the code. With a strong foundation of good internalization, companies can now achieve simultaneous shipping (sim-ship), launching all language versions of a product at once. Sim-ship is now standard operating procedure.
DO✔️
- Storing all text in resource files (e.g. JSON, XML, .properties, PO files)
- Use reusable keys from a separate language file instead of embedding text directly in your code
DON’T✖️
- Hardcode text into the source code
Localization (L10n)
Localization is the process of making a product or service globally operable, marketable, and recognizable, typically following internalization. While internationalization designs a product to be easily adaptable for global audiences, localization adapts that product to make it highly relevant and engaging for a specific target market.
How are they relevant to programming? It is somewhat self-evident now that tasks such as rewriting code, software updates, sim-ship, etc., are part of defining i18n and l10n. Without getting too technical, I view programming, as a localization professional, as the ‘language’ I needed to learn in order to communicate effectively with a cross-functional team—resolving language-related bugs, proposing ideas on scalability and efficiency, and sometimes evangelizing the need for the localization team to be involved as early as possible. I’d like to provide more specific examples from my actual work experience where this applied in the following posts.
Additionally, practical exercises and lessons learned on web localization involving programming will be archived here in the Learning section, with more posts to follow in this series.
(Source: Lionbridge; Troyer, Programming for Internalization and Localization)