Skip to main content
Glama
fabkho
by fabkho

Find Duplicate Translation Keys Across Layers

find_duplicate_keys

Find translation keys in both shared and app layers where the app value shadows the shared one. Compares a locale, reports divergent collisions, and identifies which side to delete.

Instructions

Find translation keys defined in BOTH a shared layer and an app layer that consumes it (e.g. the same key in a monorepo root layer and in app-shop). At runtime the app layer's value shadows the shared one — collisions with divergent values are the dangerous case, because the shared value silently never shows. Compares one reference locale and reports each collision with both values and a divergent flag. Fix by deleting one side, never by moving.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
localeNoLocale code to compare values in (e.g., "de", "en-US"). Defaults to the project default locale.
byValueNoWhen true, also groups different keys carrying the same value — e.g. common.actions.save and calendar.views.save both "Speichern". Each group says what to do about it: "reuse" (a shared layer already has it — delete the app copies and repoint call sites), "promote" (move one to a shared layer with move_translation_key), or "consolidate" (duplication inside one layer). Default: false.
outputFileNoAbsolute path to write full JSON output. Returns only a compact summary to the caller — use this for large outputs to avoid flooding the conversation context. Example: "/tmp/duplicate-keys.json"
projectDirNoAbsolute path to the Nuxt project root. Defaults to I18N_PROJECT_DIR, then server cwd. Example: "/home/user/my-app".
minValueLengthNoShortest value worth grouping when byValue is set. Default: 4 — below it, values like "OK" repeat across unrelated namespaces legitimately.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full disclosure burden. It is upfront about reporting one locale at a time, emitting both values and a divergent flag, and explaining the runtime shadowing danger. The read-only nature is made clear through 'compares' and 'reports', and the 'never by moving' caution adds important behavioral context beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three tight, purposeful sentences. It leads with the core operation, quickly gives a concrete monorepo example, then explains the runtime danger and the safe fix. Every sentence adds distinct value and no space is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with five parameters, no annotations, and no output schema, the description gives a strong behavioral outline: it identifies collision semantics, output flag, locale behavior, and recommended resolution. It does not spell out projectDir defaults or exact output structure, but the input schema covers those, and the description's orientation is enough for an agent to use the tool confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers all 5 parameters with full descriptions, providing the baseline. The description only adds minor contextual semantics, such as the single-reference-locale behavior, but does not restate or deepen parameter meanings meaningfully. Given 100% schema coverage, this is adequate and does not need heavy compensating explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb-resource pair, 'find translation keys', and specifies the exact scope: keys present in BOTH a shared layer and a consuming app layer. The runtime shadowing explanation further clarifies why these collisions matter, distinguishing this from sibling find_* tools that look at empty, missing, orphan, or undefined keys.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly identifies when to use this tool: whenever a key exists in both the shared and app layers and you want to detect shadowed values. It does not explicitly name sibling tools as alternatives or state when not to use them, but the 'BOTH shared layer and app layer' framing and the 'fix by deleting one side' guidance provide solid usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fabkho/the-i18n-kit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server