Mixed-stack teams routinely have to share user-facing strings between an i18next-driven Node or Next.js frontend and a Rails backend whose config/locales/*.yml files speak a different dialect. Both formats are nominally "key-value translations", but the Rails YAML convention requires every entry to live under a single locale root (en:, de:, etc.), and the YAML grammar disallows tabs, has its own escaping rules, and rejects keys that the JSON dialect happily accepts. Hand-converting between the two is a perennial source of bugs in projects that try to keep two ecosystems in sync without a TMS.
i18n-convert reads the flat i18next JSON object and emits a Rails-compatible YAML document with all entries nested under a single locale key (en: here, since that is the default source-language root for an English bundle). Keys are sorted alphabetically inside the locale root for deterministic, easy-to-review diffs across translation rounds. Special characters in values are escaped per YAML's safe rules — string values that would otherwise be misinterpreted as YAML scalars (numbers, booleans, the special words null, yes, no) get quoted automatically. Nested JSON objects, if present, become nested YAML mappings rather than dotted keys, so the Rails I18n.t('app.title') lookup syntax just works without manual reshaping.
Command
i18n-convert simple.json --to yaml-rails -o en.yml
Input
{
"welcome": "Welcome to our app",
"goodbye": "See you later",
"app_title": "My Application"
}
Output
en:
app_title: My Application
goodbye: See you later
welcome: Welcome to our app