Skip to main content
Glama

kaeris_translate_file

Translate app strings files into multiple languages, writing translated versions to the same folder. Supports eleven formats, incremental updates, and automatic back-translation checks.

Instructions

Translate a strings file on disk and write the results next to it.

Supports JSON, YAML, .strings, .po, ARB, Android XML, CSV, XLIFF 1.2, Java/Spring .properties, .NET RESX and Mozilla Fluent (.ftl). With only_new=True (JSON), translates just the keys missing from existing target files and merges.

Args: file_path: path to the source file, e.g. "locales/en.json". target_languages: language codes, e.g. ["de", "uk", "zh"]. out_dir: where to write outputs (default: the source file's directory). only_new: reproducible incremental mode — translate only new AND edited keys, tracked via kaeris.lock (a tone/ICU/glossary change re-translates all); unchanged stays stable. JSON only. keep: optional list of terms to NEVER translate — kept verbatim in every language (brand/product names), e.g. ["KAERIS", "GitHub"]. context: one line about what the app IS, e.g. "a mobile bank for teenagers" or "a wildlife documentary app". The model uses it to pick the right sense of ambiguous strings — "Bank" becomes Ufer in the second and Bank in the first. You are reading the repo, so you know this: pass it. Max 300 chars. verify: back-translate each result into back_lang to confirm meaning (non-incremental only). back_lang: language for the verify back-translation (default "en"). tone: "formal" or "casual" to steer register; "" (default) is neutral. icu: True if values may contain ICU MessageFormat (plurals/select) so the model preserves the syntax instead of translating it. reuse: optional {lang: {key: previous_translation}} translation-memory map — strings unchanged from a prior run are reused verbatim server-side (non-incremental only; only_new does its own client-side diffing). api_key / openrouter_key: optional auth overrides.

Returns: { "written": ["locales/de.json", ...], "languages": [...] }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
icuNo
keepNo
toneNo
reuseNo
verifyNo
api_keyNo
contextNo
out_dirNo
only_newNo
back_langNoen
file_pathYes
openrouter_keyNo
target_languagesYes
Behavior5/5

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

With no annotations, the description fully discloses side effects (file writes, merging), the lock-file mechanism, conditions for retranslation, and the return value. It even explains how context affects translation sense with concrete examples, going far beyond a typical definition.

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?

Although long, it is structured with an Args/Returns layout and front-loaded with purpose and supported formats. Every sentence contributes necessary information; there is no fluff or tautology.

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

Completeness5/5

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

For a complex 13-parameter tool with no annotations and no output schema, this description covers everything: return values, file formats, mode constraints, parameter semantics, and example usage. It is fully self-contained.

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

Parameters5/5

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

Schema description coverage is 0%, yet the description compensates fully by explaining every one of the 13 parameters with examples, defaults, constraints, and interactions (e.g., context max 300 chars, only_new JSON-only, reuse non-incremental).

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 specific verb-resource pair: 'Translate a strings file on disk and write the results next to it.' It further clarifies scope by listing supported formats, and distinguishes itself from siblings by focusing on file-based translation with incremental options.

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?

Clear conditions are given: only_new is JSON-only and incremental, verify and reuse are non-incremental-only. While it doesn't explicitly name sibling alternatives, it provides strong when-to-use context through these restrictive clauses.

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/RaiGanja/kaeris-mcp'

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