Should Localization Ever Be Part of Domain or Business Logic?

Localization should generally stay at the presentation boundary. If the core logic starts depending on values like “en-US” or translated strings, changing languages can unexpectedly affect business behavior and make testing much harder. For rules involving geography, taxes, or compliance, use an explicit country code, region, or domain-specific enum instead of the user’s display locale.

A good separation is for the domain to return structured results, error codes, or validation keys, while the UI or document-generation layer turns those into localized text. That keeps translations from being scattered through service code and makes adding another language much easier.

There can be an exception when the domain itself is fundamentally tied to a particular language. Some industries use specialized terms that do not translate cleanly, so modeling those concepts in the language used by the subject-matter experts can be practical. That is more about choosing the domain’s terminology than ordinary UI localization.