If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/svenfuchs/rails-i18n shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 5w ago
• 27+ active contributors
• Distributed ownership (top contributor 48% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live svenfuchs/rails-i18n repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/svenfuchs/rails-i18n.

What it runs against: a local clone of svenfuchs/rails-i18n — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in svenfuchs/rails-i18n | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 64 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of svenfuchs/rails-i18n. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/svenfuchs/rails-i18n.git
#   cd rails-i18n
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of svenfuchs/rails-i18n and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "svenfuchs/rails-i18n(\\.git)?\\b" \\
  && ok "origin remote is svenfuchs/rails-i18n" \\
  || miss "origin remote is not svenfuchs/rails-i18n (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "lib/rails-i18n.rb" \\
  && ok "lib/rails-i18n.rb" \\
  || miss "missing critical file: lib/rails-i18n.rb"
test -f "lib/rails_i18n/railtie.rb" \\
  && ok "lib/rails_i18n/railtie.rb" \\
  || miss "missing critical file: lib/rails_i18n/railtie.rb"
test -f "lib/rails_i18n/pluralization.rb" \\
  && ok "lib/rails_i18n/pluralization.rb" \\
  || miss "missing critical file: lib/rails_i18n/pluralization.rb"
test -f "lib/rails_i18n/transliteration.rb" \\
  && ok "lib/rails_i18n/transliteration.rb" \\
  || miss "missing critical file: lib/rails_i18n/transliteration.rb"
test -f "rails/locale/en.yml" \\
  && ok "rails/locale/en.yml" \\
  || miss "missing critical file: rails/locale/en.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 64 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~34d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/svenfuchs/rails-i18n"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

rails-i18n is a centralized gem that provides locale data (translations, pluralization rules, transliteration, and ordinal rules) for Ruby on Rails applications across 100+ languages. It eliminates the need for Rails developers to manually define locale YAML files and plural form logic by bundling pre-built locale data in rails/locale/*.yml and pluralization rules in lib/rails_i18n/common_pluralizations/. Modular gem structure: lib/rails_i18n/ contains pluralization rules split by language family (east_slavic.rb, one_other.rb, etc.), lib/rails_i18n/railtie.rb provides Rails integration, and rails/locale/ contains 100+ YAML locale files (af.yml, ar.yml, etc.). Configuration via config/i18n-tasks.yml and a Thor task runner in locales.thor for locale management.

Rails developers building multi-language applications who need out-of-the-box locale support without writing custom translation files. Contributors maintain locale data for specific languages and ensure pluralization rules match CLDR standards.

Production-ready and actively maintained. The gem has stable versioning (currently 8.1.0+ for Rails 8.1+) with CI/CD via GitHub Actions, comprehensive locale coverage across 100+ languages, and structured tests via RSpec (.rspec config present). Last activity visible in the presence of Gemfile.lock and maintained version branches (rails-5-x, rails-4-x, rails-3-x).

Low risk for core functionality but moderate risk for locale accuracy: individual locale YAML files are maintained by community contributors who may have varying quality standards, and there's no obvious validation layer visible in the file list to catch missing or incorrect translations. Single-author reputation (svenfuchs) means long-term maintenance depends on community contributions for locale updates.

Unable to determine from file list alone—no recent commit dates or PR info visible. However, the presence of GitHub Actions CI workflow (.github/workflows/ci.yml) and multiple Rails version branches suggests active maintenance for compatibility across Rails versions.

git clone https://github.com/svenfuchs/rails-i18n.git
cd rails-i18n
bundle install
bundle exec rspec

Daily commands:

bundle exec rake
# or for specific locale validation:
bundle exec i18n-tasks health

• lib/rails-i18n.rb — Main entry point that loads the gem and registers Rails I18n locales with the framework.
• lib/rails_i18n/railtie.rb — Rails Railtie that integrates locale loading into the Rails initialization lifecycle.
• lib/rails_i18n/pluralization.rb — Core pluralization rules engine that defines how different languages handle plural forms.
• lib/rails_i18n/transliteration.rb — Transliteration rules for converting non-Latin characters to ASCII equivalents.
• rails/locale/en.yml — English base locale file that defines the canonical structure all other locales inherit from.
• rails-i18n.gemspec — Gem specification defining dependencies, versioning, and metadata for distribution.
• config/i18n-tasks.yml — Configuration for i18n-tasks CLI that validates and maintains locale consistency across files.

• undefined — undefined

Add Support for a New Language/Locale

1. Create a new YAML locale file in the rails/locale/ directory following the naming convention (e.g., rails/locale/xx-YY.yml for language-region) (rails/locale/xx-YY.yml)
2. Copy the structure from rails/locale/en.yml and translate all English strings to the target language (rails/locale/en.yml)
3. If the language has non-standard pluralization rules not covered by existing rules in lib/rails_i18n/common_pluralizations/, create a new pluralization rule file (lib/rails_i18n/common_pluralizations/custom_rule.rb)
4. Register the pluralization rule in lib/rails_i18n/pluralization.rb by adding a line that maps the locale code to the rule class (lib/rails_i18n/pluralization.rb)
5. Run i18n-tasks (configured in config/i18n-tasks.yml) to validate the new locale file for missing keys and structural consistency (config/i18n-tasks.yml)
6. Update CHANGELOG.md to document the new locale addition (CHANGELOG.md)

Add a New Pluralization Rule for a Language Family

1. Create a new Ruby class in lib/rails_i18n/common_pluralizations/ that inherits and implements the pluralization logic (lib/rails_i18n/common_pluralizations/new_rule.rb)
2. Define the rule as a module with a pluralize method that takes a count and returns the correct plural key (e.g., :one, :few, :other) (lib/rails_i18n/common_pluralizations/new_rule.rb)
3. Register the rule in lib/rails_i18n/pluralization.rb using the register_pluralization method with the locale codes that use this rule (lib/rails_i18n/pluralization.rb)
4. Add test coverage in the spec suite to validate the pluralization logic for edge cases (Rakefile)

Add Transliteration Rules for a New Language

1. Edit lib/rails_i18n/transliteration.rb and add character mappings for the language's special characters to ASCII equivalents (lib/rails_i18n/transliteration.rb)
2. Use the existing Transliteration module to define mappings as hashes that convert Unicode characters to their ASCII approximations (lib/rails_i18n/transliteration.rb)
3. Test the transliteration rules using Rails' I18n.transliterate method in the test suite to verify correct character conversion (Rakefile)

• YAML locale files — Human-readable format that's easy for translators to understand and edit; native Rails I18n format requires no parsing overhead
• Ruby modules for pluralization rules — Allows flexible language-specific logic while keeping rules isolated and composable; enables dynamic rule registration at gem load time
• Railtie integration — Seamless Rails integration without requiring explicit initializer setup; automatically loads locales during Rails boot process
• i18n-tasks for validation — Ensures consistency across 100+ locale files; catches missing keys and structural mismatches before deployment
• Thor tasks — Provides CLI utilities for maintenance tasks without requiring custom rake syntax; integrates with Rails generators

• Centralized single gem repository for all locale data rather than separate gems per language

  • Why: Reduces dependency fragmentation and ensures all locales stay synchronized with Rails release cycles
  • Consequence: Requires careful versioning and release process; community must contribute to single repository instead of maintaining independent locale gems

• Plural rules defined as Ruby modules rather than configuration data

  • Why: Allows complex conditional logic for languages with intricate pluralization rules (e.g., Polish, Romanian)
  • Consequence: Rules are not easily inspectable by non-Ruby speakers; requires code commits for rule changes vs. data-only updates

• Supporting 100+ locales in single gem

  • Why: Eliminates missing locale errors and provides translations out-of-the-box for most Rails applications
  • Consequence: Larger gem size and load time penalty for applications that only need 1-2 locales; all locales loaded into memory by default

• No runtime locale compilation or optimization

  • Why: Keeps gem simple and locale files human-editable without build step
  • Consequence: Slower I18n lookups for large applications with many pluralized strings; no opportunity for AOT optimization

• Does not handle application-specific translations—only provides Rails framework translations (error messages, date/time formats, etc.)
• Does not provide a user interface or translation management system—data is YAML files requiring git-based workflows
• Does not support automatic language detection or locale negotiation—configuration is the responsibility of the Rails app
• Does not provide real-time translation APIs or integrate with external translation services
• Does not handle language-specific business logic beyond pluralization and transliteration

No obvious environment variables or external service dependencies, but be aware: (1) locale YAML files must strictly follow Rails I18n structure or they won't load; (2) pluralization rules are tightly coupled to CLDR standards—modifying them requires understanding plural form categories (one, few, other, etc.) for each language; (3) the gem only provides defaults—Rails apps can override with custom config/locales/ files, which may mask version mismatches.

• CLDR (Common Locale Data Repository) — rails-i18n's pluralization rules and locale data are based on CLDR standards; understanding CLDR plural categories (zero, one, two, few, many, other) is essential for adding or modifying pluralization logic
• Pluralization Rules & Plural Forms — Different languages have different rules for plural morphology (English: one/other; Russian: one/few/many/other); rails-i18n encodes these in separate classes like east_slavic.rb
• Rails Railtie — rails-i18n uses a Railtie (lib/rails_i18n/railtie.rb) to hook into Rails initialization and auto-load locales; understanding Railtie is key to modifying when/how locales are registered
• YAML Locale File Structure — All locale data is stored in YAML with a strict nested key structure (e.g., en.activerecord.errors.messages.taken); incorrect nesting breaks Rails I18n lookups
• Transliteration — rails-i18n provides language-specific rules to convert characters (e.g., Cyrillic → Latin) via lib/rails_i18n/transliteration.rb; used for URL slugs and ASCII conversion
• I18n Backend & Locale Resolution — The gem extends Rails' I18n backend by registering locales that are then resolved via fallback chains (e.g., en-US → en); misunderstanding fallback chains leads to missing translation bugs
• Thor Task Automation — locales.thor provides CLI tasks for bulk locale operations; useful for contributors to automate updates across all language files

• ruby-i18n/i18n — Core i18n gem that rails-i18n extends; houses the I18n module and locale loading logic that this repo depends on
• rails/rails — Rails framework itself; rails-i18n provides default locale files for Rails error messages and default strings
• grosser/i18n-tasks — Companion tool for validating and managing i18n keys in Rails apps; configured via config/i18n-tasks.yml in this repo
• unicode-org/cldr — Source of truth for pluralization rules and locale data that rails-i18n implementations must conform to
• svenfuchs/rails-i18n-wiki — Historical documentation and contributor guide for rails-i18n locale additions and maintenance

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test coverage for pluralization rules in lib/rails_i18n/common_pluralizations/

The repo contains 9 different pluralization rule classes (east_slavic.rb, one_few_other.rb, etc.) but there's no visible test suite validating these rules work correctly for their target languages. This is critical since incorrect pluralization breaks translations in production. New contributors could write RSpec tests for each pluralization class to ensure they handle edge cases (zero, one, few, other forms) correctly.

• [ ] Create spec/lib/rails_i18n/common_pluralizations/ directory structure mirroring lib/rails_i18n/common_pluralizations/
• [ ] Write unit tests for each pluralization rule class (east_slavic_spec.rb, one_few_other_spec.rb, etc.) with test cases for boundary conditions
• [ ] Test against actual locale files in rails/locale/ to verify pluralization rules match their expected languages
• [ ] Update .rspec config if needed and ensure tests run in CI

Add integration tests for locale file validity and completeness in rails/locale/

The repo maintains 50+ locale YAML files (af.yml, ar.yml, etc.) but there's no visible validation that these files are structurally valid, properly formatted, or contain expected Rails keys. A test suite could catch malformed YAML, missing critical keys (activerecord.errors, helpers, etc.), or encoding issues before they're released.

• [ ] Create spec/locale_validation/ directory with a test suite that iterates through all rails/locale/*.yml files
• [ ] Add tests to verify YAML syntax validity and proper nesting structure
• [ ] Add tests to ensure each locale contains required top-level keys (activerecord, errors, helpers, number, datetime, etc.)
• [ ] Implement check for encoding (UTF-8) and lint common translation mistakes (untranslated English strings)
• [ ] Add this as a step in .github/workflows/ci.yml

Add documentation and tests for lib/rails_i18n/transliteration.rb

The transliteration.rb file exists but has no visible tests or documentation explaining which languages it supports and how to use it. This module is likely important for Rails apps needing transliterated slugs/URLs but is completely undocumented. New contributors could add RSpec tests and update README with transliteration examples.

• [ ] Write spec/lib/rails_i18n/transliteration_spec.rb with tests for transliteration of different language characters (Cyrillic, Arabic, CJK, etc.)
• [ ] Test edge cases: empty strings, mixed scripts, special characters, numbers
• [ ] Add a 'Transliteration' section to README.md with code examples showing how to use I18n.transliterate
• [ ] Document which locales support transliteration rules and provide examples for 3-4 major languages

• Review rails/locale/ directory for incompleteness: check if error messages for Active Record validations (e.g., 'taken', 'invalid') exist in smaller-population locale files like az.yml, be.yml, and add missing keys.
• Add test coverage for pluralization rules in lib/rails_i18n/common_pluralizations/: create RSpec specs in spec/ for each pluralization class to verify edge cases (e.g., zero, negative numbers, large numbers).
• Verify and document transliteration logic in lib/rails_i18n/transliteration.rb: test against real Rails app examples and add examples to README.md showing how to use transliteration with non-Latin alphabets.

The rails-i18n repository has a generally solid security posture as a locale data library with minimal attack surface. No hardcoded secrets, SQL injection, XSS, or critical misconfigurations were detected. Main concerns are routine maintenance items: keeping Ruby and dependencies updated, enabling automated dependency vulnerability scanning, and ensuring Docker images follow security best practices. The gem's primary function of providing locale data means it has limited exposure to typical web application vulnerabilities. Risks are primarily related to dependency management and container image maintenance.

• Medium · Ruby Version Pinning — Dockerfile. Dockerfile uses Ruby 3.2.2 which may have known vulnerabilities as it's not the latest patch version. Ruby patch versions should be regularly updated to receive security fixes. Fix: Update Ruby to the latest stable patch version (e.g., 3.2.x where x is the latest). Consider using a base image policy that automatically updates patch versions.
• Low · Missing HEALTHCHECK in Dockerfile — Dockerfile. The Dockerfile lacks a HEALTHCHECK instruction, which could make it difficult to detect container failures in production environments. Fix: Add a HEALTHCHECK instruction to verify the container is functioning properly, especially if this image is used in production.
• Low · No Security Headers Configuration — Configuration files. No evidence of security headers configuration (e.g., Content-Security-Policy, X-Frame-Options) in the visible configuration files. This is a locale data repository, but if served via HTTP, security headers should be considered. Fix: If this gem is used in web applications, document security best practices for gem consumers. Ensure downstream Rails applications implement appropriate security headers.
• Low · Bundler Lock File Not Verified — Gemfile.lock. The Gemfile.lock file is present but without visibility into its contents, we cannot verify that all dependencies are using secure versions. Fix: Regularly run 'bundle audit' or 'bundler-audit' to check for known vulnerabilities in dependencies. Consider using Dependabot or similar automated dependency scanning.
• Low · Executable Scripts in bin/ Directory — bin/ directory. Multiple executable scripts in the bin/ directory could potentially introduce supply chain risks if modified maliciously. Some scripts (bundler, rails, rake) are commonly targeted. Fix: Verify integrity of bundler binstubs regularly. Use lockfiles to ensure consistent versions. Consider using bundle exec directly instead of relying on binstubs in production.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.