Перевод интерфейса типовой конфигурации на иностранные языки

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

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

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

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

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

 

Постановка задачи: необходимость перевода интерфейса

 

В какой-то момент в компании появились англоговорящие сотрудники – или они уже были ранее, – и им стало неудобно работать с интерфейсом на русском языке. Хотя буквы в английском и русском алфавитах во многом совпадают, смысл многих слов остается непонятным. Иногда всплывает какое-нибудь системное сообщение: одни слова похожи, другие – совершенно незнакомы, и непонятно, что делать.

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

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

 

Первые шаги: поиск стандартного решения

 

Как же решать эту задачу? Для меня она была новой – непонятно, за что браться. Первое, что приходит в голову – загуглить. Начинаем искать: как вообще переключить язык интерфейса пользователя? Есть ли какие-то стандартные решения?

 

 

Оказывается, да – в настройках есть пункт «Язык интерфейса программы». Меняем с русского на английский.

 

 

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

Было бы здорово, если бы все действительно работало так просто.

Такой подход работает только в случае, если типовая конфигурация изначально полностью переведена на другие языки – например, как в 1С:ERP. Там при переключении на английский язык действительно все становится на свои места: меню, отчеты, справочники – все на осмысленном, бизнес-ориентированном английском, а не на кальке или машинном переводе.

Но у нас совсем другая ситуация: используется Управление холдингом с русской локализацией, и полноценного перевода на английский нет. Значит, стандартный переключатель языка нам не поможет – придется искать обходные пути и как-то выкручиваться.

 

Что нужно перевести: три уровня интерфейса

 

Нам предстоит решить три основные задачи.

Во-первых, нужно изменить язык интерфейса платформы – то есть те элементы, которые приходят «из коробки»: стандартные сообщения, названия пунктов меню (например, «Открыть», «Закрыть», «Провести»), уведомления об ошибках и прочее.

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

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

 

Перевод интерфейса платформы: что доступно «из коробки»

 

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

• Русский

• Английский

• Азербайджанский

• Грузинский

• Болгарский

• Венгерский

• Вьетнамский

• Китайский

• Казахский

• Литовский

• Немецкий

• Турецкий

• Украинский

• Румынский

• Украинский

• Французский

• Латышский

• Польский

Отдельно хочу отметить интересный, но малоизвестный механизм – возможность быстрого частичного перевода ресурсов платформы. Я узнал о нем только при подготовке материалов. Подробности – по ссылке https://its.1c.ru/db/metod8dev/content/5864/hdoc/_top/язык

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

 

 

Посмотрите на картинку: сверху – интерфейс на русском, снизу – на английском. Видно, как «Завершить работу» превратилось в Exit, «Открыть» – в Open, а «Новый» в New. Появилось даже Windows в меню. Все это – возможности самой платформы.

 

 

Чтобы использовать интерфейс на языке, отличном от русского, нужно предварительно установить соответствующий языковой пакет. Это делается на этапе установки платформы. Можно установить все доступные языки сразу, а потом выбирать нужный в зависимости от задачи. Например, можно указать в файле конфигурации при запуске у конкретного клиента, что нужно запустить определенный язык.

Обратите внимание, что при переходе на английский язык у нас меняется все меню. Теперь мы работаем не в «конфигураторе», а в Designer, как «белые люди». Вместо «отчетов» – Reports, вместо «справочников» – Catalogs. В интерфейсе появляется даже Numeral («нумератор»).

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

 

Синтаксис кода: русский или английский – что меняет выбор

 

 

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

Но есть один нюанс: на что влияет этот выбор? По сути – почти ни на что. Меняется синтаксис-помощник. Если вы выбрали русский язык как основной язык разработки, то мы найдем «если», но не найдем if. И наоборот – при выборе английского синтаксиса мы найдем if, но не найдем «если».

 

 

При этом исполняемый код может быть как на русском, так и на английском – абсолютно неважно, что вы выбрали. Единственный нюанс: если у вас выбрана русская раскладка, то писать английские ключевые слова придется «по памяти», без помощи подсказок. Синтаксис-помощник в этом случае не сработает.

 

Мультиязычность в подсистеме БСП: что дает вендор

 

 

Теперь поговорим о представлении ссылок. На этом этапе нам не пришлось ничего делать вручную – достаточно было просто установить платформу. Может нам и дальше ничего не надо делать с точки зрения разработки, а за нас все сделал вендор?

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

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

 

Автоматический перевод: интеграция с Google и Яндекс

 

 

Что еще нам дает БСП «из коробки»? Возможность переиспользовать интернет-переводчики. Можно подключить, например, Яндекс.Переводчик или Google Translate – это также настраивается из каталога.

Однако важно понимать: это работает не везде. Например, в 1С:ERP такая функция есть – на картинках вы видите скриншоты из ERP. А в Управлении холдингом ее нет, потому что, видимо, функционал просто не был подключен. И если вы захотите использовать перевод в своей конфигурации, его нужно будет настраивать вручную – по умолчанию он не активируется.

 

 

Что дает эта подсистема? Прежде всего – представление ссылок. Если вы заглядывали в конфигуратор, возможно, замечали поля вроде «Наименование1», «Наименование2», «Наименование3» или табличную часть «Представления» – вот это и есть техническая основа мультиязычности.

Как реализована замена ссылок? Если у текущего пользователя установлен язык, отличный от основного (в нашем случае – русского), система вместо стандартного поля «Наименование» использует «Наименование1» или «Наименование2» – в зависимости от кода выбранного языка.

То же самое касается табличной части представлений. Там получается целый подзапрос. При прокрутке списка система может выполнять множество вложенных запросов – по одному на каждое отображаемое наименование.

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

 

Перевод печатных форм и макетов

 

 

Также появляется возможность переключить печатные формы. На стандартной форме печати появляется переключатель между языками – например, «Русский / English».

Если у нас есть, к примеру, форма «Счет на оплату покупателю», и она изначально на русском, мы можем вручную создать ее англоязычный аналог – скажем, «Invoice». Для этого нужно добавить соответствующий макет и прописать его в нужных модулях. После этого система предложит пользователю выбор: какую версию формы использовать.

Это особенно удобно, когда часть клиентов – российские компании, и им нужно выставить русский счет, а другая часть – иностранные, и им требуется выставить иностранный счет.

Кроме того, появляется возможность автоматического перевода макетов с помощью подключенных онлайн-сервисов – Google Translate или Яндекс.Переводчик. Это уже возможно в регистре сведений, который хранит пользовательский макет.

Любую печатную форму в типовом продукте можно немного изменить: например, поменять буквы.

 

Как добавляются переводы: неудобства ручного ввода

 

 

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

Например, в карточке наименования появляется специальная кнопка «Открыть» – если, конечно, вы подключили несколько языков. При нажатии открывается окно, где можно вручную ввести наименования на разных языках: сначала – русское, затем – английское и т.д. Если подключен Google Переводчик, система может автоматически предложить перевод. Кажется, удобно – но на практике не все так гладко.

Когда вы включаете мультиязычность уже в действующей базе, система английские наименования заполняет русскими символами. То есть вместо «Product» будет написано «Товар» – просто потому, что «что-то лучше, чем ничего». Формально поле заполнено, но по сути – это не перевод, а имитация.

При этом важно понимать: «Рабочее наименование» – это именно основное поле «Наименование». То есть если пользователь переключит интерфейс на английский, он не увидит в карточке «Product» – там все еще будет «Товар». Чтобы увидеть английскую версию, нужно вручную зайти в окно многоязычных наименований и посмотреть, что там прописано.

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

 

Интерфейс конфигурации: ручная замена синонимов

 

Теперь поговорим о самом интересном – языке интерфейса самой конфигурации.

 

 

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

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

 

 

Оказывается, есть. Один из вариантов – заимствовать формы в расширение и менять синонимы. То есть прямо в русской локализации мы можем заменить, например, «Счет на оплату поставщика» на «Invoice».

Чтобы не захватывать всю форму целиком, можно пройтись по ее элементам и заменить отдельные подписи: «Дата» ? «Date», «Номер» ? «Number» – все это делается на уровне заимствования.

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

 

 

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

Фактически задача свелась к массовому переименованию объектов. Такой вариант возможен, но у него есть минусы. Главный – теперь все пользователи, включая русскоязычных, видят английские названия. Это не всегда удобно.

 

 

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

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

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

 

Попытка реализовать полноценную мультиязычность через языковой пакет

 

 

Что для этого нужно? Прежде всего – добавить английский языковой пакет. Но есть важный момент: языковой пакет нельзя добавить через расширение, его можно только заимствовать, нам нужно будет снимать конфигурацию с поддержки и добавлять английский язык.

После добавления языка у каждого синонима в конфигураторе появляется кнопка «Открыть» – знакомая, например, по работе с многоязычными справочниками, вроде номенклатуры. Теперь можно переключаться между «Русский» и «English». Но по умолчанию английская локализация – пустая, то есть все нужно заполнять вручную.

Процесс трудоемкий. Сиди и заполняй, синоним за синонимом. Каждый раз открывать окно, вбивать перевод – не очень удобно.

К счастью, в 1С есть помощник: в правом нижнем углу интерфейса есть переключатель EN/RU. Вы переключаетесь на английский язык – и все синонимы в конфигураторе сразу отображаются на английском. Или на русском, в зависимости от того, какой язык вы выбрали.

 

Проблемы при частичном переводе: что происходит, если не все переведено

 

Давайте попробуем реализовать этот подход на практике.

 

 

Мы добавили английский язык в расширение, заимствовали нужные объекты – например, часть реквизитов и формы – стандартным образом. Заходим в редактирование синонимов и начинаем заполнять английские наименования.

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

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

В качестве теста таким образом заменим несколько реквизитов – «Организация», «Аккаунт» и т.д. – и посмотрим, что получится.

 

 

Получился вполне рабочий вариант: Number, Post and close, Save, Organization – все читаемо, логика понятна.

Но есть и проблемы. Форма получилась немного кривой и не очень красивой. В чем причина? Все реквизиты, у которых нет английского наименования, должны были брать русское – ведь мы указали русский как основной язык. Но оказалось, что это не так: если в локализации ничего не задано, используется имя реквизита. У реквизитов имя есть, а у элементов формы такой возможности нет – у них есть только русское или английское наименование. Поэтому все закладки, которые были на русском, остались вовсе без подписи, пустыми.

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

 

Инструмент для массового перевода: редактирование текстов интерфейса

 

 

В конфигураторе 1С есть встроенный инструмент, который помогает хоть немного автоматизировать этот «мартышкин труд» с постоянным открытием окон и ручным заполнением – «Редактирование текстов интерфейсов». Он самостоятельно сканирует конфигурацию и находит все места, где могут быть разные языковые пакеты – это реквизиты, строки с пометкой RU или EN и прочее.

Инструмент собирает все эти строки, выводит их в удобную табличную форму, подсчитывает количество вхождений и группирует одинаковые названия. Например, если слово «Товар» встречается 50 раз – оно отобразится в одной строке. Вам нужно просто один раз ввести перевод – «Product» – и система сама применит его ко всем 50 местам.

Остается только встать на английский язык и ввести перевод напротив каждого термина. Платформа при этом может немного «подвиснуть» – ведь она обновляет множество объектов, – но зато вся работа выполняется автоматически.

Таким способом переводить собственную конфигурацию просто и удобно. Запустил инструмент, прошелся по списку, вбил переводы – и готово. Отличный механизм, все работает стабильно.

Но есть нюанс. У нас типовая конфигурация, и мы не можем просто так снять ее с поддержки и вносить массовые изменения – это вызовет огромное количество конфликтов при обновлениях. Однако если ограничиться только синонимами, ситуация становится проще. При обновлении синонимы выходят в отдельное поле, видно, что это маловажное изменение и его можно пропускать.

 

Ограничения при работе через расширение

 

Попробуем решить задачу через расширение.

 

 

Мы уже заимствовали нужные объекты – например, формы и справочники – и теперь можем использовать инструмент «Редактирование текстов интерфейса». Главное – указать, что искать нужно только в расширении. Механизм поиска здесь тот же, что и в стандартном глобальном поиске: можно выбрать области поиска, типы объектов и так далее.

Запускаем – и система находит все строки с поддержкой нескольких языков, которые есть в заимствованных элементах. Но, конечно, есть нюансы.

Во-первых, инструмент видит только то, что мы заимствовали. То есть если объект остался в основной конфигурации и не был перенесен в расширение – он не попадет в выборку.

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

Для синонимов это подойдет, а для кода функции – нет.Там мы используем заимствование: предполагается, что подключается директива «Изменение и контроль», и все понимают, что произойдет, если просто вставить код без удаления старого – работать это не будет, система просто «отвалится».

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

 

Строки форматов и локализация: неожиданные сложности

 

 

А вот что особенно интересно: оказывается, строка форматирования тоже разноязычная. Ее обязательно надо переводить, те же ЧДЦ нужно переносить и копировать, потому что слетят все форматы – даты, числа и тому подобное.

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

 

Критическая ошибка: проблемы с шаблонами и локализацией

 

Что дальше? А дальше снова сюрприз.

 

 

Мы все перевели, все выглядит красиво, пользователь доволен. Вспоминаем русскую конфигурацию – мы же перевели ее на английский с помощью добавленных средств. И тут налетаем на такую вот божественную конструкцию - СтрШаблон("НСтр('файл %1 не найден')").

Что произойдет, если будет локализация не RU, а EN? В функцию «СтрШаблон» прилетает строка, и мы получаем исключение. То есть не пустую строку, которая ничего не формирует, а большую глобальную ошибку.

Сколько таких случаев может быть? В УХ их 6 716. Заранее их все исправить – садиться и делать это через удаление и вставку – абсолютно нереально. Можно, конечно, ждать, пока у пользователя что-то сломается, он вызовет программиста, тот зайдет и починит. Но такой проект будет тянуться годами. Сегодня не открыли файл – завтра открыли, а тут ошибка, и работа встала, пока Серега не прибежит.

 

Вывод: почему типовую конфигурацию перевести невозможно

 

Таким образом, типовую «УХу», которая изначально была рассчитана в основном на русскоязычное использование, нормально перевести на другой язык невозможно. Стоит только добавить вторую локализацию – и система начинает падать буквально на первых шагах.

Что делать в такой ситуации? Остается один рабочий путь – переход на международную версию. Такая версия существует. К счастью, разработчики о нас позаботились и выпустили специальную международную сборку УХ – с поддержкой английского языка «из коробки».

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

 

Международная версия УХ: частичное решение

 

Обновляемся до международной версии УХ, и вроде бы вот он, долгожданный прорыв. Международная версия, все должно быть идеально. Запускаем, смотрим:

 

 

Согласен, русский – самый международный язык, но это не совсем то, чего я ожидал.

Коллеги нашли выход: они заполнили все поля, чтобы не было пустот. Строки в СтрШаблон теперь тоже на русском. То есть часть строк – на английском, часть – на русском. Система, по крайней мере, работает. Ее можно запустить, она что-то будет делать. Но мы снова в той же точке: работает – да, но криво, сложно и с костылями.

 

 

К тому же выяснилась еще одна интересная деталь: есть такая замечательная функция – ПолучитьСклоненияСтрокиПоЧислу(). Казалось бы, полезная штука. Но она очень чувствительна к локализации – если язык не RU, она просто падает с ошибкой. Я писал по этому поводу в 1С.

Таких упоминаний три штуки. Три мы можем поправить, 6200 – не можем.

 

Итоги: варианты решения и реальный выход

 

Пора подводить итоги. Какие у нас есть варианты, если речь идет о переводе именно типовых конфигураций?

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

Если речь идет о типовой конфигурации, то можно, конечно, залезть в код, поменять элемент – но это босяцкий подход. Можно поменять синонимы с добавлением нового языка.

Пока мы занимались этим мытарством – переключали языки, обновляли, тестировали, ломали и чинили – клиенту все это явно не нравилось. И он предложил простое и гениальное решение.

 

 

Оказывается, можно просто зайти в форму, нажать «Изменить», и вручную поменять синонимы прямо в интерфейсе. По сути то, что мы пытались сделать программно, он начал делать вручную – но системно.

Переименовал «Состояние документа» в «Status», заполнил нужные названия, создал универсального пользователя с уже настроенным интерфейсом – и стал копировать его настройки другим как шаблон.

В итоге задача решена на минималках и без программиста. Спасибо, Сергей, за вашу работу, но денег вы не получите.

 

Экзотические решения: попытка автоматического перевода через браузер

 

Еще один экзотический способ, который мы попробовали – это публикация базы и попытка использовать автоматический перевод браузера. Логика была простая: а вдруг Google Translate или аналогичный инструмент просто возьмет и переведет весь интерфейс за нас?

К сожалению, не сработало. Запускалось не сразу, а перевод был на уровне: «Моя твоя колбаса, speak from my heart», то есть не совсем то, что ожидалось.

Тем не менее, мне рассказывали коллеги, как они запускали похожий проект для китайцев. Там совершенно другая семантика, и хоть какой-то перевод лучше, чем никакого. И судя по их опыту, запуск через браузер с автоматическим переводом – вполне рабочий костыль: кое-что переводится, кое-что можно понять, и этого порой оказывается достаточно, чтобы начать работать.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.