i18n Key Naming Conventions: Dot Notation, snake_case, and camelCase

Q: i18n Key Naming Conventions: Dot Notation, snake_case, and camelCase

## i18n Key Naming Conventions Choosing a consistent naming convention for translation keys is one of the most important decisions when setting up internationalization in any project. The three dominant conventions are dot notation, snake_case, and camelCase, each with trade-offs in readability, tooling support, and ecosystem compatibility. ### Dot Notation Dot notation uses periods to separate key segments: common.buttons.submit pages.home.hero.title errors.validation.email_invalid This

Learn the three most common i18n key naming conventions: dot notation, snake_case, and camelCase. Understand when to use each style and how naming conventions affect maintainability of translation files.

Naming Conventions

Detailed Explanation

i18n Key Naming Conventions

Choosing a consistent naming convention for translation keys is one of the most important decisions when setting up internationalization in any project. The three dominant conventions are dot notation, snake_case, and camelCase, each with trade-offs in readability, tooling support, and ecosystem compatibility.

Dot Notation

Dot notation uses periods to separate key segments:

common.buttons.submit
pages.home.hero.title
errors.validation.email_invalid

This is the most widely adopted convention across i18n libraries. It naturally maps to nested JSON or YAML structures, making translation files easy to navigate. Libraries like react-i18next, vue-i18n, next-intl, and i18next all use dot notation as their default key separator.

snake_case

snake_case uses underscores to separate words within a segment:

common_buttons_submit
pages_home_hero_title
errors_validation_email_invalid

This convention is common in backend frameworks like Ruby on Rails (I18n gem), Django (gettext), and Laravel. It works well with flat key structures where the entire key is a single string without hierarchical separators.

camelCase

camelCase capitalizes the first letter of each word except the first:

commonButtonsSubmit
pagesHomeHeroTitle
errorsValidationEmailInvalid

camelCase is less common for translation keys but appears in projects where JavaScript convention influences all string identifiers. Some Angular projects and custom i18n setups prefer this style for consistency with their codebase.

Which Convention to Choose?

The best convention depends on your ecosystem:

React / Vue / Next.js / Svelte -- dot notation with nested JSON
Ruby on Rails / Laravel -- snake_case with nested YAML
Django / Flask -- snake_case with PO/gettext files
Spring Boot / Java -- dot notation with Java Properties files
Angular -- dot notation or camelCase depending on team preference

Consistency Matters Most

The specific convention matters less than applying it consistently across the entire project. Mixed conventions create confusion, make search-and-replace operations error-prone, and complicate migration between i18n libraries.

Use Case

Selecting a key naming convention is the first step when bootstrapping i18n in a new project. Teams migrating between frameworks (e.g., from Rails to Next.js) often need to convert between conventions. The i18n Key Generator lets you switch between dot notation, snake_case, and camelCase instantly to see which produces the most readable keys for your translation files.

Try It — i18n Key Generator

Open full tool →