Guide on i18n: Process and Tools to Use

To make your product or service easily available in international markets, you need to implement internationalization (i18n). I18n is fundamentally an architectural process of designing code that can be easily adapted to different languages and regions without changes to the source logic.

If you are a business aiming to reach different target markets, this guide is for you.

In this article, we will discuss what i18n is, why it is important, the phases of the i18n process, and the main integrations for establishing efficient processes and achieving accurate outcomes. Let’s get started.

What is i18n?

I18n is a commonly used abbreviation where 18 is the number of letters between “i” and “n” in the word internationalization.

At its core, internationalization is an architectural and engineering process. It involves designing software so that it can be adapted to different languages and regions without requiring changes to the source code.

Basically, i18n is the process of preparing your code to handle multiple languages and regions.

This approach allows for saving money later in the production cycle, improving overall time-to-market, and preventing common roadblocks. Successful internationalization involves designing products in a specific way early on so that there is no need to make big changes when the company decides to expand.

i18n, l10n, and g11n

Aside from internationalization, there are other terms closely related to the process of adapting a product to foreign markets. They may seem similar, but it’s important to understand them.

• Localization (l10n) is the content adaptation to a specific locale. This includes text translation, cultural adjustments to imagery, time formats, and currency. Learn more about i18n vs l10n.
• Internationalization (i18n): As we wrote above, this is the technical preparation of code that makes the product capable of handling multiple languages. (e.g., using specific libraries, externalizing strings, handling dates/plurals).
• Globalization (g11n) is more about a business strategy that combines both i18n and l10n. It covers legal, marketing, and operational requirements for a global launch.

i18n is what the developer does to the codebase. L10n is what a linguist does to the content. A translation management system (TMS), such as Crowdin, manages the L10n workflow.

Why Successful i18n Is a Must-Have

With the customer being at the center of any sales funnel, adaptivity to different cultures is a requirement rather than a suggestion. Internationalization ensures it is flexible to accommodate the requirements of every market, which offers numerous benefits.

For any company focused on growth, adaptivity to different cultures is a requirement. Internationalization ensures your application is flexible and ready for any market.

Benefits of i18n in Software Product Development

Creating an internationalized software allows you to create a user-friendly app that makes it easy to adapt the website without making changes in the source code. Key benefits include:

• No Language-Dependent Code. Moving all user-facing text into separate resource files. This keeps your code clean.
• Dynamic Adaptation. Allows the app to switch languages based on user settings, location, or URL without code deployment.
• Handling Complex Grammar. Using libraries to correctly manage complex linguistic rules like pluralization and gender (which vary widely between languages).

Main Phases of Internationalization

Internationalization is a complex process. Here, we focus on the core technical steps necessary to achieve an easily localizable product.

Phase 1: Planning and Designing for Adaptation

The primary focus is on engineering a flexible UI/UX:

• Remember about text expansion/contraction. Different languages take up different amounts of space (e.g., German is often 15% longer than English). The design must use flexible layouts so the UI doesn’t break when text length changes.
• Design for Bidirectionality (RTL). Plan for layout mirroring required by Right-to-Left languages (Arabic, Hebrew). This architectural decision affects the entire application layout, from navigation menus to icon placement.
• Prevent hardcoding strings. Make sure that all text, including button labels, error messages, and image captions, is designed to be pulled from a separate language file.

• Use culturally appropriate visuals and styling. Plan for placeholders in your code that allow images, colors, and even layout direction to be swapped out easily per locale.

You can implement design stage localization, so teams should start translating and testing text length directly in design tools. This practice helps validate layouts before development even begins. Read more about Design Stage Localization with Figma.

Phase 2: Technical Implementation

This is where developers implement i18n in the codebase using dedicated tools.

1. Implementing an i18n Library (e.g., LinguiJS)

Instead of building your own string extraction and pluralization logic, modern web apps use light-weight libraries like LinguiJS, which uses ICU MessageFormat to handle linguistic complexity.

Example: Defining a String with Pluralization (Using Lingui)

Instead of hardcoding the message, you use a library component to define the source string and its plural rules:

import { Plural, Trans } from "@lingui/macro";
function CartSummary({ itemCount }) {
  return (
    <Trans>
      You have <Plural value={itemCount} one="# item" other="# items" /> in your cart.
    </Trans>
  );
}
// This is automatically extracted to a key like:
// { "message.key": "You have {count, plural, one {# item} other {# items}} in your cart." }

2. Externalizing and Extracting Strings

The key i18n architectural step is moving text out of the code. The library’s command-line tools automate this process:

• Extraction: The library scans your source code and creates a master file (often a .json, .po, or .pot file) containing every translatable string.

  npx lingui extract

• Formatting: This file is the single source of truth for all content that needs to be localized.

3. Handling Date, Time, and Currency

The code must rely on built-in internationalization APIs (like JavaScript’s Intl object) or the i18n library to format numbers, dates, and times automatically based on the user’s detected locale, rather than manually formatting them.

Implementation Across Frameworks

The principles of i18n are universal, but the specific libraries and methods vary by language and framework. You can find detailed guides for popular languages and ecosystems, like:

• Java: Complete Java i18n and Localization Tutorial
• Svelte: Developer Guide on Svelte Apps Localization with Svelte-i18n
• React: Complete Tutorial on React i18n with i18next
• Angular: Angular i18n and Localization: The Full Tutorial
• Node.js: Node.js i18n and Localization: The Developer Guide
• JavaScript: JavaScript Localization Guide
• Python: Localize Python Apps Using the Gettext Python Module

Phase 3: Translation and Localization Management

Once the code is properly internationalized, the next step is managing the localization process. A developer-friendly translation management system like Crowdin may help you with that.

Managing translation manually via spreadsheets is slow and prone to errors. Crowdin allows centralizing all localization efforts and automating developer workflows.

Automating the Workflow with the Crowdin CLI

Crowdin CLI is the developer tool that acts as the bridge between your code and the localization platform. It lets you automate sending source strings and receiving finished translations without leaving your terminal.

Crowdin CLI ensures that developers can continuously integrate new strings into the translation process as they write code, maintaining a smooth-running i18n pipeline.

Crowdin API Clients

For developers who require complex, custom integrations, programmatic access, or the ability to manage users, projects, and custom workflows, the Crowdin API is available.

You can interact with the API directly or use one of the officially supported API clients (SDKs) in various programming languages to build powerful automation scripts.

Translation Management System (TMS) Features

Once content is in Crowdin, the localization team uses powerful tools to improve quality and speed:

• Integration with repo: Connect Crowdin directly to developer repositories (e.g., GitHub, GitLab, Bitbucket).
• Translation Memory and Glossary: keeps all terms consistent.
• In-Context Editing: Translators see their work live within the actual website or app layout, which is critical for checking text length and visual placement.
• Collaboration: developers, translators, and localization managers collaborate in one place.
• One source of truth: keep your product consistent and up to date across all languages.
• I-Powered Features: like AI pre-translation and AI quality assurance for catching subtle errors before review.
• Over-the-Air (OTA) delivery: Instant delivery of translations directly to mobile apps and websites without requiring an app store update or code redeployment.

AI-Powered Workflow with Crowdin

As with any other technology, when applied correctly, AI improves the entire internationalization process. Here’s how you can apply Crowdin’s AI features to minimize translation time and enhance the output quality.

AI-generated Context

You will get poor results if you start translating without context. Crowdin has a Context Harvester CLI that scans your code and attaches AI-generated context to each string.

It will be useful whether you are translating with AI or with human translators. Translation quality will improve from the start.

Pre-translation with AI

Before a team of translators starts working on a text, AI translates the source material into the chosen language. The team expects to revise the 100% AI-translated text to ensure accuracy.

One of the real-life examples is Polhus. They used Crowdin AI tools to create a complete machine translation. After the experts’ reviews, only 25% of the entire text had to be adjusted.

AI-Powered Quality Assurance

In-editor AI Assistant and Agentic AI can do QA checks across all your files. Translators can interact directly within the editor interface to request rewrites, tone adjustments, or definitions for ambiguous terms.

Agentic AI takes this a step further by orchestrating complex, multi-step reviews, ensuring quality is managed holistically across your entire localization project. Read more about Agentic AI features in our blog post.

Compared to the common QA tools that can highlight only the basic errors, it can locate more niche mistranslations and correct errors.

Style Guide Management

Crowdin offers a Vector Cloud app, where you can upload your style guide or old text copies as a file. The AI will learn your style and preferences, producing more accurate results. s. This allows you to maintain consistency and brand voice.

I18n Best Practices

Achieving scalable internationalization requires disciplined engineering and adherence to logical design principles. These best practices ensure your application architecture is robust and ready for global expansion:

1. Test with Pseudo-Localization

Logic Check: Use pseudo-localization as a testing tool before human translation. This process replaces source strings with elongated text containing special characters (e.g., [Ĥéééļļļööö]).

This immediately reveals two critical flaws in your architecture:

1. UI/Layout Breakage: If the UI breaks due to text expansion, your CSS/layout structure is not flexible enough to support global languages.
2. Hardcoded Strings: If you see any un-bracketed or un-modified source text, it means those strings were hardcoded and missed during the extraction phase, failing the fundamental i18n principle of externalizing all text.

2. Enforce Complete String Externalization

Absolutely all user-facing text, including error messages, placeholders, tooltips, email templates, and logging strings intended for users, must be stored outside of the source code (e.g., in .json, .po, or .xliff files).

Logic: Any string left in the code is un-translatable, creating a non-localizable barrier for users speaking other languages. Utilize i18n libraries (like Lingui) that offer extraction utilities to guarantee completeness.

3. Avoid String Concatenation

Logical Flaw: Never build a sentence by concatenating multiple language keys and variables (e.g., "The total is " + price + " dollars."). This structure works only for simple languages like English.

Always embed variables within a single, complete translation key using ICU MessageFormat (the standard used by modern libraries). This allows translators to correctly handle word order, pluralization, and grammatical gender, which vary drastically across languages.

4. Design for Context Independence

When writing source text, ensure each phrase is self-contained and clear without reliance on implicit context.

Logic: A translator sees only the individual string ("Save") or component. If a button labeled “Save” in one context is meant to mean “Save File,” but in another means “Save Changes,” the translator needs two unique keys (e.g., button.save_file and button.save_changes) to accurately localize the meaning.

5. Separate I18n Data from Application State

The language files (fr.json, de.json) should be separate assets loaded only when needed. The application logic should use the user’s current locale setting to select the correct language data, but the core business logic and state management should never depend on the content of the translation files.

This separation ensures that changing or adding a language never introduces bugs into the core application functionality.

6. Display Relevant Local Formats

The application must automatically display local formats for dates, times, currencies, and units (e.g., using $\text{kg}$ vs. $\text{lbs}$, or $\text{dd/mm/yyyy}$ vs. $\text{mm/dd/yyyy}$).

Your code must rely on built-in **** (like JavaScript’s Intl object) to abstract all formatting logic, ensuring the UX presents data based on the user’s locale setting.

Final Words

As we discovered, internationalization is a part of software architecture development, not just translation. Separate your content from your code, use advanced i18n libraries like Lingui for handling complex grammar, and remember techniques like pseudo-localization.

You need to aim for a fast and efficient i18n pipeline. A localization management platform like Crowdin acts as the central hub for this pipeline. By leveraging tools such as:

• Crowdin CLI to automate the flow of source files.
• Git Integrations to synchronize localization with development cycles.
• AI-Powered features to guarantee translation quality and consistency.
• Design-stage integrations to catch layout issues early.

You ensure that localization is a continuous process, not a bottleneck.

FAQ

Why is it called i18n?

I18n is an abbreviation for “internationalization”. The number 18 stands for the number of letters between i and n in the word itself.

What is the difference between internationalization and globalization?

Internationalization involves designing products that can be easily adapted to the needs and preferences of customers in different countries. Globalization is a broader term that includes both localization and internationalization and covers processes related to different departments, including HR, marketing, legal, and more.

How many stages are in internationalization?

Generally, there are five internationalization stages, including:

• Domestic - production and operation within the home country.
• Export - export of the domestically produced products.
• Foreign operations - some of the company’s operations are moved to another country.
• Multinational - decentralized decision-making of the operation in numerous regions.
• Translational - a global enterprise that uses local resources and efficiently operates in the majority of the markets.

How can I use AI for i18n?

The primary goal of i18n is to make your code architecturally ready for localization. Crowdin’s AI features help to deliver high-quality localization content into that architecture:

• Context Harvester CLI scans your codebase to generate and attach context to source strings. This prevents ambiguity, ensuring the correct translation is delivered back to your i18n structure.
• Use AI for pre-translation to instantly fill your localization files (.json, .po). This speeds up the process between finalizing the i18n structure and having content ready for testing.
• In-editor AI Assistant performs deep contextual checks, verifying that translated strings comply with your technical requirements (e.g., correct placeholders, valid formatting) before they enter your live application.
• Vector Cloud allows the AI to learn your specific brand voice and terminology, ensuring the finalized localization files maintain consistency across all target locales.

What is an internationalization tool?

Internationalization tool is a specialized software used to manage internationalization processes. Crowdin is one of the top solutions used by companies all over the world to increase the efficiency of localization and internationalization processes.

What software to use for i18n?

Crowdin is the number one choice for the majority of the leading global companies. It allows you to centralize all localization and internationalization processes and increase efficiency by offering such vital tools as a translation memory system, workflow automations, glossaries, in in-context editing combined with AI tools. Native integrations with GitHub, GitLab, Bitbucket, and CI/CD tools like Jenkins or GitHub Actions. Automatically pushes new source strings and pulls completed translations. The Crowdin API and CLI tools allow developers to automate export/import, update resource files, and manage language versions programmatically.

What is an example of an i18n?

One of the examples of internationalization is adjusting time and date formats based on the customers of a specific country. For example, the date format in most of the works is dd/mm/yyyy, while in the US it’s mm/dd/yyyy. Internationalized software will automatically showcase the right data format for the user based on their location.

/date?lang=en_US → Locale: en_US → Oct 30, 2025, 2:30:00 PM

/date?lang=fr_FR → Locale: fr_FR → 30 oct. 2025, 14:30:00

/date?lang=de_DE → Locale: de_DE → 30.10.2025, 14:30:00