Как эффективно локализовать конфигурацию 1С и заменить вызовы НСтр

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей Торговля и дистрибуция
← На главную

При необходимости внедрения английских синонимов или локализации интерфейса в типовых конфигурациях, таких как УТ11, разработчики часто сталкиваются с дилеммой: менять каждый вызов функции НСтр вручную или искать альтернативные пути. Изменение модулей «напрямую» усложняет процесс обновления конфигурации в будущем. Рассмотрим, как решить эту задачу грамотно, используя встроенные инструменты платформы 1С.

Использование штатного механизма локализации

Вместо того чтобы вручную переписывать тысячи строк кода, воспользуемся функционалом «Редактирование текстов интерфейса». Этот инструмент позволяет выгрузить все строковые литералы, участвующие в локализации, во внешний файл, перевести их и загрузить обратно.

  1. Убедитесь, что в конфигураторе, в разделе «Языки», у вас установлен необходимый язык локализации.
  2. Перейдите в меню «Правка» -> «Редактирование текстов интерфейса».
  3. Выберите объекты, требующие локализации, установите галку «Искать в функциях НСтр...» и нажмите кнопку «Искать».
  4. В появившемся окне выполните экспорт данных: «Действия» -> «Экспорт в табличный документ».
  5. Сохраните полученный файл в формате Excel97. Важно сохранить форматирование, так как именно оно критично для корректной работы НСтр.

Редактирование таблицы перевода

После выгрузки данных в Excel необходимо правильно подготовить структуру файла для последующей загрузки:

Теперь выполните команду «Действия» -> «Заполнить тексты», укажите ваш файл, выберите языковую пару и примените изменения. Платформа автоматически свяжет переводы с соответствующими вызовами.

Как работает локализация внутри кода

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


// До локализации:
Сообщить(НСтр("ru = 'О, привет!' "));

// После применения механизма локализации через конфигуратор:
Сообщить(НСтр("ru = 'О, привет!'; en = 'Oh, hello!' "));

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

Альтернативные подходы: что делать, если локализации недостаточно?

Если задача требует не просто перевода текста, а подмены логики вывода, и штатные методы не подходят, разработчики часто обсуждают создание собственной «обертки».

Рассмотрим вариант с созданием собственной функции в общем модуле:


// В общем модуле (например, ОбщегоНазначения):
Функция МояНСтр(СтрокаНСтр) Экспорт
    // Здесь можно реализовать логику парсинга или получения текста из регистра
    Возврат НСтр(СтрокаНСтр);
КонецФункции

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

Рекомендация для крупных систем

Для масштабных проектов, где планируется частая смена текстов без вмешательства в конфигуратор, оптимальным решением является паттерн «Справочник сообщений»:

  1. Создайте справочник Сообщения, где ключом будет уникальный код сообщения.
  2. Замените прямые вызовы НСтр на функцию ПолучитьСообщение(Код).
  3. Вся логика перевода будет храниться в данных базы, а не в коде.

Этот метод считается архитектурно более правильным для Enterprise-систем, так как он полностью исключает конфликты при обновлении типовой конфигурации и позволяет управлять текстами интерфейса через пользовательский режим.

← На главную