---
name: edt-mcp-bilingual
description: Correctness checklist for 1C's bilingual (Russian/English) model in EDT-MCP — synonym language-code vs name, object resolution by Name vs synonym vs TYPE token, dialect-aware vs literal code search. Use when reading, writing, resolving, formatting or searching metadata objects, synonyms, BSL identifiers or query keywords.
---

# EDT-MCP — two-language (ru/en) correctness

1C is bilingual at several layers, and most plugin bugs live here. Before editing any tool that resolves/reads/writes/searches metadata or code, walk this checklist.

## 1. The metadata synonym is keyed by the language CODE

The synonym is an `EMap<String,String>` whose key is the **language code** (`"ru"`, `"en"`), NOT the `Language` object's name.

- ✅ Write/read through `MetadataLanguageUtils`: `resolveLanguageCode(config, explicit)` and `getSynonymForLanguage(map, code)`.
- ✅ Reference language-resolution logic: `CreateMetadataObjectTool.resolveLanguage` — explicit → `getDefaultLanguage().getLanguageCode()` → the first language's code → null.
- ❌ NOT `config.getDefaultLanguage().getName()` (returns "Russian"/"Русский" — the name, not the key; on a multi-language config it silently misses the EMap).
- ❌ Don't hardcode `"ru"` as the fallback — use the first configured language's code.

## 2. An object resolves by its programmatic Name; the TYPE token is bilingual

- The object name (the segment after the type) is a **programmatic identifier**, resolved by `getName()` (see `MetadataTypeUtils.findObject`). A synonym is NOT accepted as an identifier.
- The TYPE token (Справочник/Catalog, Документ/Document …) is bilingual, handled by `MetadataTypeUtils` (`toEnglishSingular`, `normalizeFqn`, `getAllFqnVariants`).
- Say it honestly in the schema description: "only the TYPE token may be Russian/English; the object name is a programmatic identifier, not a synonym." Don't mislead with "Russian names supported".

## 3. Writing a synonym — symmetric, through the shared resolver

- When creating an object/attribute, if a synonym is given, write `getSynonym().put(resolveLanguageCode(...), synonym)`.
- A write tool must **return** the written `synonym`+`language` in its response (symmetry with read tools).

## 4. BSL: ru/en dialects

- AST/index tools (find_references, get_symbol_info, go_to_definition, call_hierarchy) are dialect-aware — they resolve by symbol name with `equalsIgnoreCase`, no normalization needed.
- `search_in_code` is a **literal** matcher, NOT dialect-aware: searching an English keyword won't find its Russian equivalent. Reflect this honestly in the tool description; for identifier search, direct the user to the AST tools.
- Cyrillic in regexes — escape via `\uXXXX` (as in `BslSyntaxChecker`), not raw UTF-8 literals (corruption risk under a non-UTF-8 build).

## 5. 1C queries are bilingual

Query keywords have ru/en dialects (SELECT/ВЫБРАТЬ, FROM/ИЗ, WHERE/ГДЕ). `validate_query` delegates to the platform parser (dialect-aware) — don't assume a single dialect; keep UTF-8 when passing query text.

## Test invariant

Any change to resolution/reading/writing must have a test covering **both** languages: one object addressed by its English Name, Russian Name, and (where applicable) synonym — identical result; the synonym keyed by language code, not by name. Reference: `WriteModuleSourceToolTest.testResolveRussianObjectName`.