Software internationalization checklist: 5 checks before localization

A software internationalization checklist answers a practical question before localization starts: is the product ready to be translated? Software internationalization (i18n) is the engineering and content-design work that enables a product to support different languages, locales, and writing directions without rebuilding it for each market. Doing it before localization reduces avoidable rework: defects in strings, formats, or layouts can otherwise affect multiple locale versions and require repeated translation or testing.

This checklist covers five checks to run before the first string is sent for translation, with the evidence to collect for each one. For the conceptual comparison between the two disciplines, see our guide to internationalization and localization.

What changes when internationalization comes first

Rework: early fixes cost less

A hard-coded label or rigid layout is cheapest to fix before translation. Once localized builds exist, a source change may also require updates to resource files, translation memories, screenshots, QA scripts, and locale-specific tests. Internationalization does not eliminate rework, but it prevents the same class of defect from multiplying across releases.

Translation quality, human and machine, starts in the source strings

Translators and AI engines can only work with the strings they receive. A sentence assembled from fragments, a label without context, or a message that ignores plural forms leaves human linguists guessing and machine translation engines producing fluent errors. If source strings are fragmented or lack context, neither human translators nor automated systems can reliably infer the intended grammar and meaning. We orchestrate AI models within localization workflows and add human review and functional and linguistic testing, but the quality of the input still sets the limit.

How to check readiness before the first translation

A five-point readiness audit

Run these five checks on a representative build and keep the evidence for each one; a single named owner should decide when the checklist is complete.

Check	What to verify	Evidence to collect	Suggested owner
1. Strings	Every user-facing string lives in resource files, not in code	A code scan showing resource-file coverage	Engineering
2. Messages	Messages are complete sentences with placeholders and plural-aware patterns, never assembled from fragments	A review of messages against plural rules	Engineering and localization
3. Unicode and fonts	UTF-8 is used from database to interface, with fonts that cover the target scripts	Test strings rendered in every target script	Engineering
4. Locale formats	Dates, numbers, currencies, and sorting come from locale libraries	The same screen captured in several locales	Engineering and QA
5. Layout	Layouts survive longer text and right-to-left display	A pseudo-localized build and right-to-left screenshots	Design and QA

Pseudo-localization as a pre-flight test

Pseudo-localization replaces source text with accented, lengthened characters, so that “Save” appears as “[Šàvéé]”. Text that stays in plain English is hard-coded, strings that are cut off signal layout risk, and garbled characters point to encoding problems. Published pseudolocalization guidance describes it as a way to verify that a product is localizable before translation begins. The test is automated and needs no translator; it reveals many localizability defects early, but it does not replace linguistic and functional testing of the translated product.

What breaks when a product is not internationalized

Hard-coded strings, concatenation, and plurals

Text embedded in code cannot be extracted for translation, and sentences built by joining fragments assume English word order. Plurals add another layer: in the Unicode CLDR cardinal rules, English uses two categories, Russian four, and Arabic six. Those categories are grammatical rules, not merely singular-versus-plural labels, so a counter such as “2 files selected” needs a pattern that each language can complete with its own forms.

Dates, numbers, currencies, and sorting

Formats vary by locale: the order of day and month, the decimal separator, the position of the currency symbol, even the first day of the week. Sorting varies too; in Swedish, for example, the letters å, ä, and ö come after z. Standard locale libraries encode these rules, whereas hand-written formatting code seldom does.

Text expansion, right-to-left scripts, and fonts

When English is the source language, many translations occupy more space, especially short UI strings. The W3C cites IBM guidance of 200 to 300 percent average expansion for English strings of up to ten characters, while also noting that expansion varies by language and by string. Interfaces for right-to-left scripts such as Arabic and Hebrew need bidirectional-text support: navigation, directional icons, and component order may need mirroring, while logos, media controls, charts, and other elements may not, so mirroring should follow platform and locale conventions. Every target script also needs a font with the right glyphs, and truncated buttons or overlapping elements are what testing finds when a layout was built around English alone.

When localization has already started: a retrofit path

Many teams discover the problem after the first release, and the way out is a sequence rather than a rewrite:

1. Triage defects by their effect on meaning: concatenation, plural errors, and missing context first, cosmetic layout issues second.
2. Externalize and restructure the affected strings, keeping stable identifiers so that existing translation memory matches survive.
3. Retranslate only the segments that changed, and run a pseudo-localized build to confirm that nothing else is hard-coded.
4. Retest the highest-volume languages first, then roll the fixes out to the rest.

What to look for in a software localization partner

Internationalization is an engineering task, yet the partner who receives your strings determines how many of its gaps surface in production. Look for localization engineering that can handle tags and code, functional and linguistic testing, and a willingness to review your process before the first project begins. Since 1989, we have supported multilingual products as a Language Intelligence Partner through software localization, localization engineering, and linguistic and functional testing, and our language consulting services can review translation processes and language technology before the first string is sent.

What product and engineering teams ask about internationalization

How early should internationalization start in a new product?

At the architecture stage, before the first interface text is written, even if only one language ships at launch. The effort is small when it is part of normal design decisions, and it grows with every screen built on English-only assumptions.

Can we localize first and internationalize later?

It is possible, and some teams do it with a single target market, but the first localization project then doubles as an internationalization project. The retrofit path above limits the damage; the cheaper course is to externalize strings, adopt UTF-8, and avoid concatenation from the start.

Does AI translation reduce the need for internationalization?

No: AI translation operates on text and does nothing for layouts, formats, encoding, or fragmented sentences, and it performs best on complete, well-contextualized strings. We orchestrate AI models through seprotec.ai and apply human review where risk is high, but the input still has to be prepared in the code.

Who should own internationalization in a product organization?

Engineering implements it, product defines the target locales and requirements, and the localization team reviews and tests the results. One named owner should hold the definition of done, such as no hard-coded strings merged and a pseudo-localized build passing before each release.

What is an example of internationalization?

Storing every message in a resource file with placeholders, and formatting prices from a number and a locale instead of typing symbols into the text, so that one checkout page can display $1,234.50 in the United States and 1.234,50 € in Germany without code changes. The guide linked above covers further examples.

If you are preparing a product for new markets, contact us to review your readiness before the first translation begins.