principle-i18n

Enforce locale-aware formatting, UTC time-zone handling, and translation-safe string composition.

2|8|Updated Apr 20, 2026
One-click install
npx skills add https://github.com/lugassawan/swe-workbench --skill principle-i18n
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: principle-i18n
Source: https://github.com/lugassawan/swe-workbench/tree/main/skills/principle-i18n
Command: npx skills add https://github.com/lugassawan/swe-workbench --skill principle-i18n

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Prevents internationalization bugs that only appear after adding new locales, such as incorrect date/time/number/currency formatting, broken pluralization, and RTL layout issues.

Core Features & Use Cases

  • Locale-Aware Formatting: Use proper locale APIs for dates, numbers, and currency, avoiding hard-coded formats or manual string assembly.
  • Time Zone Correctness: Persist timestamps in UTC and render in the user’s local time at the display edge to avoid DST and comparison errors.
  • Plural, Grammatical, and Catalog Safety: Use CLDR-based plural categories and ICU/gettext-style message catalogs with reorderable placeholders, not concatenated strings.
  • Bidirectional Layout & Encoding Hygiene: Ensure right-to-left rendering uses correct directionality, logical CSS, and bidi-safe text isolation; enforce UTF-8 end-to-end.

Quick Start

Audit your UI strings and formatting code so dates, numbers, currency, pluralized messages, and RTL layout all use locale-aware APIs and translation-safe message catalogs before shipping another language.

Frequently Asked Questions about principle-i18n

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

FAQPage Schema
How do I format dates and numbers correctly for multiple locales?

Locale-aware formatting requires using proper locale APIs for dates, numbers, and currency instead of hard-coded formats or manual string assembly. This prevents internationalization defects when adding new languages to your application.

What is the best way to handle pluralization in internationalization?

Pluralization in internationalization requires using CLDR-based plural categories and ICU/gettext-style message catalogs with reorderable placeholders. Avoid concatenated strings to ensure grammatical correctness across all supported languages.

How do I manage time zones when rendering localized timestamps?

Time zone handling requires persisting timestamps in UTC and rendering them in the user’s local time at the display edge. This approach avoids daylight saving time and comparison errors across different regional settings.

How do I support right-to-left scripts in my UI layout?

Right-to-left rendering requires correct directionality, logical CSS, and bidi-safe text isolation. Ensuring UTF-8 encoding end-to-end maintains bidirectional layout hygiene and prevents display issues with RTL scripts.

When do I need ICU messageformat for my application strings?

You need ICU messageformat when composing translation-safe string copy that includes pluralized text or reorderable placeholders. It prevents internationalization bugs that appear after adding new locales with complex grammatical rules.

Why does my currency formatting break when adding a new locale?

Currency formatting breaks when using manual string assembly or hard-coded formats instead of proper locale APIs. Adopting CLDR/ICU-style message catalogs and UTF-8 encoding end-to-end prevents these localization defects.