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.
1---2name: edt-mcp-bilingual3description: 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.4---56# EDT-MCP — two-language (ru/en) correctness781C 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.910## 1. The metadata synonym is keyed by the language CODE1112The synonym is an `EMap<String,String>` whose key is the **language code** (`"ru"`, `"en"`), NOT the `Language` object's name.1314- ✅ Write/read through `MetadataLanguageUtils`: `resolveLanguageCode(config, explicit)` and `getSynonymForLanguage(map, code)`.15- ✅ Reference language-resolution logic: `CreateMetadataObjectTool.resolveLanguage` — explicit → `getDefaultLanguage().getLanguageCode()` → the first language's code → null.16- ❌ NOT `config.getDefaultLanguage().getName()` (returns "Russian"/"Русский" — the name, not the key; on a multi-language config it silently misses the EMap).17- ❌ Don't hardcode `"ru"` as the fallback — use the first configured language's code.1819## 2. An object resolves by its programmatic Name; the TYPE token is bilingual2021- 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.22- The TYPE token (Справочник/Catalog, Документ/Document …) is bilingual, handled by `MetadataTypeUtils` (`toEnglishSingular`, `normalizeFqn`, `getAllFqnVariants`).23- 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".2425## 3. Writing a synonym — symmetric, through the shared resolver2627- When creating an object/attribute, if a synonym is given, write `getSynonym().put(resolveLanguageCode(...), synonym)`.28- A write tool must **return** the written `synonym`+`language` in its response (symmetry with read tools).2930## 4. BSL: ru/en dialects3132- 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.33- `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.34- Cyrillic in regexes — escape via `\uXXXX` (as in `BslSyntaxChecker`), not raw UTF-8 literals (corruption risk under a non-UTF-8 build).3536## 5. 1C queries are bilingual3738Query 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.3940## Test invariant4142Any 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`.
ditrixnew