backend-localization

Multilingual backend error messages are implemented by injecting ILocalizationService into your services, adding translation keys to ca.json, es.json, and en.json resource files, and calling GetLocalizedString to return culture-aware API responses.

Backend culture detection determines the output language by checking a specific order of precedence: query parameters first, then the JWT locale claim, and finally the Accept-Language header to select the correct translation resource.

The best way to avoid hard-coded status names is to use StatusConstants-based references alongside ILocalizationService, ensuring that lifecycle and status strings are dynamically translated across Catalan, Spanish, and English.

Yes, you need to maintain separate JSON resource files, specifically ca.json, es.json, and en.json, to store the dynamic translations for each new error message or validation string added to the backend services.

Yes, ILocalizationService is designed for integration across services and data models to fetch localized messages, allowing you to add new validation error strings and present the correct language to API clients consistently.

The default setup supports Catalan, Spanish, and English, ensuring consistent user feedback and reducing language-related bugs by maintaining corresponding ca.json, es.json, and en.json resource files.