Internationalization · 4 min read
Internationalization Starts in the Data Model
A product becomes easier to localize when its data, language, and interaction rules were designed to adapt from the start.
# Internationalization Starts in the Data Model
Localization is visible in the words people read. Internationalization begins earlier, in the structures and rules that determine what the product can express. If an address only fits one country's field order, or a price assumes one currency format, translation cannot make the experience feel local.
I have worked across five Staples brands, 16 languages, and 20 countries. In ACS planning, I applied that systems perspective to the design questions that appear before the first translation is commissioned. The details look small on a screen, but they shape whether the underlying product can adapt without splitting into a collection of market-specific exceptions.
Model the information people actually use
An address should be structured so country-specific formats can be represented, not forced into one U.S.-first template. A phone number should be stored and validated independently of how it is displayed. Money should carry an explicit currency and be formatted for the user's locale; the same amount can use different symbols, separators, and decimal conventions.
Language needs similar care. Labels grow when translated. Scripts need fonts that can render them. Text should not be baked into images, and teams need a shared glossary so product copy, support material, and AI-assisted responses use the same terms. These are practical design-system decisions because they determine how reliably teams can extend the experience.
Dates, names, calendars, time zones, holidays, and preferred communication channels also carry local assumptions. A date such as 03/04 can mean different days. A single “first name / last name” rule does not fit every naming convention. If a product ignores those differences, people have to translate the interface back into their own context before they can act.
Keep one product, with room for local rules
Internationalization is not a request to build a separate product for every country. It is a way to keep the core experience coherent while allowing local information and conventions to be handled deliberately. In the ACS planning work, that meant treating locale as useful product context—language, region, time zone, calendar, and channel—rather than a flag that only changes strings.
The same principle applies to AI features. If an assistant appears in a localized experience, it should answer in the expected language, use content the signed-in person is allowed to see, and make its sources clear. The model cannot supply the product's missing context; the content and permissions underneath still have to be designed.
A good internationalization foundation makes the next market less expensive to consider and less likely to surprise the people who use the product. It gives design and engineering a shared set of rules, then leaves room for local research and review to shape the final experience.
Source note: This article draws on the internationalization recommendations in ACS product-planning decks prepared in October 2026. The examples describe proposed design principles, not shipped global functionality.