Skip to main content
Severity: Warning — does not affect exit code or fail CI builds.
Glot detects translation values in non-primary locales that are identical to the primary locale, which may indicate they haven’t been translated yet.

What Are Untranslated Values?

An untranslated value occurs when:
  1. A key exists in both the primary locale and a non-primary locale
  2. The value in the non-primary locale is identical to the primary locale
This typically happens when:
  • Locale files are copy-pasted and translations are forgotten
  • A new key is added to all locales but only translated in the primary locale
  • Translations are incomplete or rushed

Example

Primary locale file:
messages/en.json
{
  "common": {
    "submit": "Submit",
    "cancel": "Cancel"
  }
}
Non-primary locale with untranslated values:
messages/zh.json
{
  "common": {
    "submit": "Submit",
    "cancel": "Cancel"
  }
}
Glot output:
warning: "Common.submit"  untranslated
  --> ./messages/en.json:3:0
  = note: ("Submit") identical in: zh
  = used: (no usages found)

warning: "Common.cancel"  untranslated
  --> ./messages/en.json:4:0
  = note: ("Cancel") identical in: zh
  = used: (no usages found)

✘ 2 problems (0 errors, 2 warnings)
The output shows:
  • File location: Points to the primary locale file (en.json) as the source of truth
  • Note: Shows the value and which locales have identical (untranslated) values
  • Used: Shows where the key is used in code (clickable in IDEs), or “(no usages found)” if unused

Detection Rules

Glot applies these rules when detecting untranslated values:

Only Non-Primary Locales Are Checked

The primary locale (defined in .glotrc.json) is skipped since it’s the source of truth:
.glotrc.json
{
  "primaryLocale": "en"
}
With this config, messages/en.json is never checked for untranslated values.

Values Must Contain Alphabetic Characters

Pure numbers and symbols are skipped since they’re often legitimately the same across locales:
{
  "common": {
    "year": "2024",
    "separator": "---",
    "currency": "$"
  }
}
These won’t be flagged even if identical across locales.

Exact Match Required

Only values that are exactly identical to the primary locale are flagged:
messages/en.json
{
  "common": {
    "greeting": "Hello"
  }
}
messages/de.json
{
  "common": {
    "greeting": "Hello"
  }
}
This would be flagged. But if the German value was “hello” (lowercase), it would not be flagged.

Severity

Untranslated values are reported as warnings (not errors) because:
  • Some values legitimately remain the same across languages (brand names, technical terms, etc.)
  • They don’t break functionality
  • They’re informational and may not require action

Running Untranslated Detection

bash npx glot check untranslated
Or run all checks including untranslated:
bash npx glot check

Fixing Untranslated Values

1

Run Check

npx glot check untranslated
2

Review Issues

For each flagged key, determine if it needs translation or should remain the same.
3

Translate Values

Update the non-primary locale files with proper translations:
messages/zh.json
{
  "common": {
    "submit": "提交",
    "cancel": "取消"
  }
}
4

Verify

Run the check again to confirm translations are applied:
npx glot check untranslated

Common Scenarios

Legitimate Same Values

Some values should remain identical across locales:
{
  "brand": {
    "name": "Acme Corp",
    "tagline": "JavaScript"
  }
}
In these cases, you can safely ignore the warning.

Partial Translations

When adding new features, it’s common to copy keys from the primary locale and forget to translate some:
messages/ja.json
{
  "newFeature": {
    "title": "New Feature",
    "description": "Check out our new feature"
  }
}
These should be translated to Japanese.

Placeholder Text

Sometimes developers use English placeholder text intending to translate later:
messages/fr.json
{
  "dashboard": {
    "welcome": "Welcome back!"
  }
}
The untranslated check helps catch these before they reach production.