В условиях выхода бизнеса на международные рынки или работы с зарубежными поставщиками возникает необходимость ведения справочника Номенклатура сразу на нескольких языках. Это требуется не только для корректной выгрузки на интернет-витрины (например, на Bitrix), но и для формирования печатных форм (инвойсов) или работы иностранных сотрудников в одной информационной базе. Рассмотрим подробнее, какие решения существуют на платформе 1С:Предприятие 8.3, проанализируем их плюсы и минусы, а также разберем программную реализацию.
Это самый простой и быстрый способ, не требующий внесения изменений в конфигурацию на уровне метаданных. Мы воспользуемся механизмом «Дополнительные реквизиты и сведения», который входит в состав Библиотеки стандартных подсистем (БСП) и есть практически во всех типовых решениях (УТ 11, ERP, КА, УНФ).
Разберем по шагам, как это работает:
Номенклатура добавляем новые реквизиты, например: «Наименование (EN)», «Наименование (CN)», «Описание (EN)».Преимущества: Простота внедрения и совместимость с типовым модулем обмена с сайтами. Модуль обмена с Bitrix легко подхватывает дополнительные свойства и передает их на сайт как отдельные атрибуты товара. На стороне сайта останется только настроить отображение нужного атрибута в зависимости от выбранного языка интерфейса.
Недостатки: Этот метод становится громоздким, если языков больше двух. Фильтрация, поиск и построение отчетов по таким полям в 1С будут затруднены, так как данные хранятся в табличной части ДополнительныеРеквизиты, а не в основной таблице справочника.
Если проект предполагает масштабирование на 3 и более языков, правильнее использовать отдельный объект метаданных — РегистрСведений. Рассмотрим структуру такого регистра:
Номенклатура (тип СправочникСсылка), Язык (тип СправочникСсылка.Языки или перечисление).Представление, Описание (тип Строка).Проанализируем ситуацию: при таком подходе мы можем хранить неограниченное количество переводов. Для выгрузки на сайт нам потребуется написать небольшой обработчик в модуле обмена, который для каждой позиции номенклатуры будет выполнять запрос к этому регистру.
Пример получения данных для выгрузки:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ЯзыковыеДанные.Представление КАК НаименованиеEN
|ИЗ
| РегистрСведений.ПереводыНоменклатуры КАК ЯзыковыеДанные
|ГДЕ
| ЯзыковыеДанные.Номенклатура = &Номенклатура
| И ЯзыковыеДанные.Язык = &ЯзыкEN";
Запрос.УстановитьПараметр("Номенклатура", СсылкаНаТовар);
Запрос.УстановитьПараметр("ЯзыкEN", Справочники.Языки.НайтиПоНаименованию("English"));
Результат = Запрос.Выполнить().Выбрать();
Это наиболее продвинутый вариант, позволяющий не только хранить данные, но и автоматически подменять их в интерфейсе программы в зависимости от локали пользователя. Если у пользователя установлен английский язык интерфейса, он увидит в списке Номенклатура английские названия без каких-либо доработок форм.
Рассмотрим реализацию этого механизма. Для активации мультиязычности данных в своих объектах необходимо выполнить следующие действия:
1. В модуле менеджера справочника Номенклатура определим процедуры для формирования представления:
Процедура ОбработкаПолученияПолейПредставления(Поля, СтандартнаяОбработка)
МультиязычностьКлиентСервер.ОбработкаПолученияПолейПредставления(Поля, СтандартнаяОбработка);
КонецПроцедуры
Процедура ОбработкаПолученияПредставления(Данные, Представление, СтандартнаяОбработка)
МультиязычностьКлиентСервер.ОбработкаПолученияПредставления(Данные, Представление, СтандартнаяОбработка);
КонецПроцедуры
Процедура ОбработкаПолученияДанныхВыбора(ДанныеВыбора, Параметры, СтандартнаяОбработка)
МультиязычностьСервер.ОбработкаПолученияДанныхВыбора(ДанныеВыбора, Параметры, СтандартнаяОбработка, Метаданные.Справочники.Номенклатура);
КонецПроцедуры
2. В форме списка или форме объекта необходимо инициализировать подсистему в обработчике ПриСозданииНаСервере:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
МультиязычностьСервер.ПриСозданииНаСервере(ЭтотОбъект);
КонецПроцедуры
Важный нюанс: Как показывает практика, механизм БСП автоматически подменяет данные в динамических списках, изменяя текст запроса «на лету». Если вы используете произвольный запрос в динамическом списке, убедитесь, что в него включены поля, необходимые подсистеме для идентификации языка. Это позволяет пользователям работать в единой базе: один видит «Ботинок», другой — «Boot», при этом ссылка на объект Номенклатура остается неизменной.
Выясним причину, по которой многие отказываются от мультиязычности — это сложность ручного заполнения тысяч карточек. Современным решением является интеграция с API переводчиков. Мы можем автоматизировать этот процесс, добавив кнопку «Перевести» в карточку номенклатуры или настроив регламентное задание.
Проанализируем алгоритм автоматизации:
Использование ChatGPT предпочтительнее для поля Описание, так как нейросеть может не просто перевести текст, а адаптировать маркетинговое описание товара под целевой рынок, учитывая специфику терминологии.
Посмотрим на ситуацию со стороны сайта. Стандартный обмен через CommerceML (1c-bitrix) передает реквизиты товара. Чтобы на сайте корректно отображались разные языки, рекомендуется передавать переводы как дополнительные свойства. В настройках интеграции в 1С на вкладке «Обмен данными» можно указать, какие доп. реквизиты должны выгружаться. На стороне Bitrix эти данные попадут в инфоблок как свойства типа «Строка».
Для высоконагруженных систем можно использовать хранение всех языковых версий в одном текстовом поле в формате JSON. При записи объекта в 1С мы собираем все переводы в структуру {"ru": "...", "en": "..."} и записываем в одно скрытое поле. Это значительно ускоряет выгрузку, так как сайту не нужно собирать данные из разных таблиц — он получает готовый пакет для всех языковых версий в одной строке.
Подводя итог, выбор решения зависит от ваших задач: для простой выгрузки на сайт достаточно дополнительных реквизитов, а для полноценной работы сотрудников в мультиязычной среде лучше использовать подсистему БСП «Мультиязычность» с программной обработкой представлений.