rule-frontend-i18n

Enforce frontend i18n standards for naming conventions and translation usage across codebase.

1|1|Updated Mar 31, 2026
One-click install
npx skills add https://github.com/btabaska/simpler-grants-documentation-automation --skill rule-frontend-i18n
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rule-frontend-i18n
Source: https://github.com/btabaska/simpler-grants-documentation-automation/tree/main/.claude/skills/rule-frontend-i18n
Command: npx skills add https://github.com/btabaska/simpler-grants-documentation-automation --skill rule-frontend-i18n

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Inconsistent frontend translations and ad-hoc localization practices lead to UI mismatches and maintenance pain; this rule enforces a single, predictable i18n approach across the frontend.

Core Features & Use Cases

  • Enforces a single locale and centralized message files to avoid scattered translations.
  • Guides key naming conventions (camelCase nested keys, PascalCase top-level namespaces) and consistent translation usage with useTranslations/getTranslations.
  • Ensures proper page title formatting and rich text handling with t.rich() for inline HTML.

Quick Start

Audit your frontend i18n usage and align keys, namespaces, and translations to the documented standards.

Frequently Asked Questions about rule-frontend-i18n

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

FAQPage Schema
What are the best practices for frontend i18n key naming conventions?

Frontend i18n key naming best practices enforce PascalCase for top-level namespace keys and camelCase for nested message keys to ensure consistent translation usage and maintainable localization files.

How do I standardize frontend translations across multiple components?

Standardize frontend translations by enforcing a single locale with centralized message files and consistent runtime translation calls using useTranslations or getTranslations across all components.

Why should I avoid per-page translation files in frontend localization?

Avoiding per-page translation files in frontend localization prevents scattered translations and UI mismatches by centralizing all messages into a single predictable i18n structure.

How do I handle rich text and inline HTML in frontend i18n translations?

Handle rich text and inline HTML in frontend i18n translations by using the t.rich() function to ensure proper page title formatting and consistent rendering of complex message structures.

Can I use this i18n standard with multiple locales in the same frontend application?

No, this i18n standard enforces a single locale per application to avoid ad-hoc localization practices and ensure predictable translation usage across the entire frontend codebase.

How do I audit my existing frontend i18n usage for compliance?

Audit your frontend i18n usage by checking all components using frontend/src/i18n to verify key naming, namespace structure, and runtime translation calls align with the documented standards.