i18n Inside a Configurator Engine's Constraints

For an engineering leader, i18n in a procurement platform is rarely a translation problem — it's a structural one. On Zammit, the product spanned roughly forty configurators across ten categories plus twenty-five e-commerce flows, all on web and mobile, and all built within the DriveWorks configurator engine. That last fact shapes every i18n decision. Configurator-driven UI means a lot of the user-facing language and option logic originates in the engine's data model, not in a tidy front-end string table you fully control. So the design had to treat localizable content as a first-class concern across that boundary: option labels, units, edge-profile and dimension terminology, validation and error messaging from the manufacturing rules, and the quote-account-OTP-checkout-tracking flows where legal and transactional phrasing matters most. The practical guidance I'd give R&D: decide early what is localizable versus engine-bound, because retrofitting that split is expensive. Account for layout reflow on mobile when strings expand. And keep domain terminology — the words a contractor versus a retail professional actually uses — consistent across both the configurator surface and the commerce surface, so one product doesn't speak two languages.