1С переводчик: что это и как работает перевод в 1С

Под запросом «1С переводчик» обычно скрываются три разные задачи: перевод интерфейса конфигурации на другой язык, перевод пользовательских данных (наименований, описаний, текстов документов) и встроенные механизмы платформы 1С:Предприятие для мультиязычной работы. Отдельной программы с официальным названием «1С Переводчик» в составе платформы нет — под этим словом понимают либо штатные средства мультиязычности, либо сторонние обработки и сервисы, которые автоматизируют перевод строк конфигурации.

Ключевой механизм — функция НСтр() и многоязычные синонимы объектов метаданных. Разработчик пишет в коде строку на основном языке, помечает её функцией НСтр, а переводы хранятся в языковых ресурсах конфигурации. При запуске сеанса на другом языке платформа автоматически подставляет нужный вариант текста. Это штатный, документированный путь, и именно его следует использовать в первую очередь.

Сторонние «переводчики для 1С» — это обычно внешние обработки или сервисы, которые выгружают строки из конфигурации, отправляют их в машинный перевод (например, в облачные API) и загружают результат обратно. Они ускоряют работу, но требуют ручной вычитки: машинный перевод терминов учёта («проводка», «регистр накопления», «субконто») часто даёт неточные или двусмысленные формулировки.

Что именно называют переводчиком в контексте 1С

Термин используется в трёх смыслах, и их важно различать, потому что инструменты и риски разные. Первый смысл — встроенная мультиязычность платформы: список языков конфигурации, функция НСтр() в коде, многоязычные синонимы объектов, представления перечислений и предопределённых элементов. Это часть платформы, она не требует установки ничего дополнительного.

Второй смысл — внешние обработки и сервисы, которые автоматизируют перевод: выгружают строки, помеченные НСтр, в файл, отправляют в сервис машинного перевода и импортируют результат. Такие решения распространяются как готовые обработки или подключаемые модули и экономят время на больших конфигурациях, где строк могут быть тысячи.

Третий смысл — перевод пользовательских данных: наименований номенклатуры, описаний товаров, текстов печатных форм. Здесь механизм другой: переводы хранятся либо в дополнительных реквизитах, либо в специальных регистрах сведений, либо в многоязычных полях, если конфигурация их поддерживает. Функция НСтр для данных не работает — она предназначена только для строк, зашитых в код и метаданные.

Как устроена штатная мультиязычность платформы

Основа механизма — свойство «Языки» в корневом узле конфигурации. Там задаётся список языков (например, русский и английский) и язык по умолчанию. После добавления языков у каждого объекта метаданных появляется возможность заполнить синоним на каждом языке: у справочников, документов, реквизитов, команд, форм и элементов форм.

В программном коде переводимые строки оформляются через НСтр. Варианты перевода можно указать прямо в вызове функции, но при большом объёме удобнее вынести их в языковые ресурсы — тогда переводчики работают с отдельными файлами, не трогая код. Платформа в момент выполнения определяет язык сеанса пользователя и подставляет соответствующий вариант; если перевода для языка нет, выводится строка на языке по умолчанию.

Язык сеанса определяется настройками пользователя информационной базы или параметром запуска. Это значит, что одна и та же база может одновременно обслуживать пользователей с разными языками интерфейса — каждый видит синонимы и сообщения на своём языке, а данные при этом общие.

Как перевести интерфейс конфигурации: порядок действий

Работа ведётся в конфигураторе и требует прав на изменение конфигурации. Перед началом обязательно сделайте выгрузку информационной базы или копию: правка синонимов и кода — это изменение конфигурации, и откат без резервной копии затруднён.

1. 1
   Откройте конфигуратор, сделайте выгрузку базы (Администрирование → Выгрузить информационную базу).
2. 2
   В свойствах корневого узла конфигурации добавьте нужные языки и укажите язык по умолчанию.
3. 3
   Пройдите по объектам метаданных и заполните синонимы на каждом языке: справочники, документы, реквизиты, команды, формы.
4. 4
   В модуле кода найдите пользовательские строки (сообщения, заголовки) и оберните их в НСтр с вариантами перевода.
5. 5
   Обновите конфигурацию базы данных (F7) и проверьте интерфейс, запустив сеанс под пользователем с другим языком.

Удобный приём — поиск строковых литералов по всей конфигурации (Правка → Глобальная замена или поиск по модулям с фильтром по кавычкам). Так находятся сообщения пользователю, которые разработчик оставил «жёстко» на русском. Каждую такую строку нужно либо обернуть в НСтр, либо осознанно оставить как есть, если она служебная и пользователю не показывается.

Не забудьте про макеты печатных форм: надписи в табличных документах не переводятся автоматически. Для многоязычных печатных форм обычно создают отдельные макеты под каждый язык и выбирают нужный в коде, либо заполняют параметры макета строками через НСтр.

Сторонние обработки и машинный перевод: когда это оправдано

Если конфигурация содержит тысячи строк, ручной перевод становится неподъёмным, и здесь помогают обработки-переводчики. Типичная схема их работы: выгрузка всех строк, помеченных НСтр, и синонимов в табличный файл; отправка в сервис машинного перевода через API; загрузка результата обратно в конфигурацию. Некоторые решения работают пакетно и сохраняют соответствие «исходная строка — перевод» для повторного использования.

Ограничения у такого подхода существенные. Машинный перевод плохо справляется с учётной терминологией и короткими строками без контекста: «проведение», «сторно», «разузлование» могут быть переведены буквально и бессмысленно. Поэтому результат машинного перевода — это черновик, который обязательно вычитывает человек, знающий предметную область. Особенно критично для строк, которые попадают в официальные документы и отчёты.

Ещё один риск — конфиденциальность. Отправляя строки конфигурации во внешний сервис перевода, вы передаёте третьей стороне фрагменты логики вашей системы. Для типовых конфигураций это некритично, но для самописных решений с коммерческой тайной стоит проверить условия сервиса или использовать локальные модели перевода.

Как переводить данные, а не интерфейс

Частая задача — хранить наименования товаров или контрагентов на двух языках, чтобы печатные формы и веб-интеграции выводили нужный вариант. НСтр здесь не поможет: функция работает только со строками в коде и метаданных, а данные живут в таблицах базы.

Практические варианты решения: дополнительные реквизиты с типом «строка» для каждого языка; отдельный регистр сведений «Переводы» с измерениями «Объект» и «Язык»; либо штатные механизмы многоязычных данных, если они предусмотрены вашей конфигурацией. Выбор зависит от объёма: для пары полей достаточно дополнительных реквизитов, для системной мультиязычности каталога лучше регистр сведений — он не раздувает основную таблицу и удобен для выборок.

При выводе переведённых данных в печатную форму или в ответ веб-сервиса код должен явно выбирать значение на нужном языке. Определите правило fallback: что показывать, если перевода для запрошенного языка нет. Обычно возвращают значение на основном языке, чтобы пользователь не видел пустое поле.

Сравнение вариантов

Штатная мультиязычность (НСтр + синонимы)

Подходит для интерфейса и сообщений кода. Надёжно, поддерживается платформой, но требует ручного заполнения переводов.

Обработки с машинным переводом

Подходят для больших объёмов строк как первый проход. Требуют обязательной ручной вычитки и проверки терминологии.

Регистр сведений для переводов данных

Подходит для многоязычного контента (каталоги, описания). Требует доработки кода вывода и правила fallback.

Проверка результата и типичные ошибки

После внедрения перевода проверьте систему глазами пользователя с другим языком. Запустите сеанс с нужным языком интерфейса, пройдите основные сценарии: создание документа, проведение, формирование отчёта, печать. Обращайте внимание на сообщения об ошибках — именно их чаще всего забывают обернуть в НСтр, и пользователь видит русский текст в английском интерфейсе.

Контрольные точки

Как проверить результат

Синонимы объектов в интерфейсе

Норма

Названия справочников, документов и реквизитов показываются на языке сеанса

Тревожный признак

Часть названий осталась на русском или отображается пусто

Сообщения и предупреждения

Норма

Все тексты сообщений выводятся на языке сеанса

Тревожный признак

Всплывают русские строки из «жёстко» вписанных литералов

Печатные формы

Норма

Надписи и шаблоны на нужном языке, даты и числа форматированы корректно

Тревожный признак

Смешение языков в одном документе, пустые поля вместо перевода

Отдельная ошибка — правка типовой конфигурации «в лоб» с последующей потерей изменений при обновлении. Если конфигурация на поддержке, добавление языка и переводов снимает её с полной поддержки, и каждое обновление потребует сравнения и объединения. Планируйте это заранее и фиксируйте все изменённые объекты.

FAQ: частые вопросы о переводе в 1С

Можно ли перевести типовую конфигурацию (например, «Управление торговлей») на английский?

Технически да: добавляется язык, заполняются синонимы и НСтр. Но объём работ большой, а конфигурация снимается с полной поддержки — каждое обновление придётся объединять вручную. Часто дешевле использовать локализованные редакции, если они существуют для нужной страны.

Чем НСтр отличается от простого условия «если язык = английский, то...»?

НСтр — штатный механизм: переводы централизованы, платформа сама выбирает вариант по языку сеанса, а строки можно выгружать для переводчиков. Ручные условия размывают переводы по коду, усложняют поддержку и ломаются при добавлении третьего языка.

Переведёт ли платформа автоматически данные справочников?

Нет. Мультиязычность платформы касается интерфейса и строк в коде. Наименования, описания и прочие пользовательские данные переводятся отдельными механизмами: дополнительные реквизиты, регистры сведений или специализированные решения.

Опасно ли отправлять строки конфигурации в онлайн-переводчик?

Для типовых конфигураций риск минимален — эти строки и так известны. Для самописных решений вы передаёте третьей стороне фрагменты бизнес-логики; проверьте условия сервиса или используйте локальные инструменты перевода.

Что делать, если после добавления языка часть интерфейса стала пустой?

Причина почти всегда в незаполненных синонимах на новом языке. Платформа в таком случае должна подставлять значения языка по умолчанию, но для некоторых элементов (например, отдельных надписей форм) подстановка не срабатывает. Пройдите по объектам и заполните пропущенные синонимы.

Нужен ли отдельный язык сеанса для каждого пользователя?

Нет, язык задаётся индивидуально: в настройках пользователя информационной базы или параметром запуска. Одна база может одновременно обслуживать русскоязычных и англоязычных пользователей с общими данными.