backend-localization

Localize backend error messages across ca, es, and en via ILocalizationService.

2|1|Updated Feb 16, 2026

Search Tags:#backend #localization #i18n #errors #multilingual #status-constants #culture-detection

Ready to run

npx skills add https://github.com/MGurtD/lilith --skill backend-localization

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: backend-localization
Source: https://github.com/MGurtD/lilith/tree/main/.github/skills/backend-localization
Command: npx skills add https://github.com/MGurtD/lilith --skill backend-localization

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

The backend localization skill provides seamless, multilingual error messages and UI strings across Catalan, Spanish, and English, ensuring consistent user feedback and reducing language-related bugs.

Core Features & Use Cases

ILocalizationService integration in services to fetch localized messages.
StatusConstants-based references to avoid hard-coded lifecycle and status names.
JSON resource files (ca.json/es.json/en.json) for dynamic translations and culture-aware responses.
Use Case: add new localized messages for a failed validation and present the correct language to API clients.

Quick Start

Install and wire up ILocalizationService in your backend, add keys to ca.json/es.json/en.json, and call GetLocalizedString in responses.

Frequently Asked Questions about backend-localization

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I implement multilingual backend error messages in a web API?▼

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.

How does backend culture detection work for returning localized 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.

What is the best way to avoid hard-coded status names in a localized backend?▼

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.

Do I need to maintain separate JSON files for each language when adding backend translations?▼

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.

Can I use ILocalizationService to handle new validation error messages across different 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.

What languages are supported by default for backend localization in this setup?▼

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.