Зачем переводить исходники?
Сейчас всё чаще стали появляться новости о локальных успехах решений на платформе 1С в странах дальнего зарубежья - за пределами СНГ. Понемногу увеличивается распространение 1С в европейских странах, на западе и в азиатском регионе. Мы в 1С Вьетнам вносим свой вклад в международную "экспансию" отечественного ПО.
Для того, чтобы распространение платформы 1С на зарубежном рынке стало более массовым и вышло за границы единичных успешных проектов, недостаточно иметь лишь локализованную конфигурацию с переведённым интерфейсом. 1С здесь в новинку, и нет того фундамента, на котором держатся позиции 1С в России - широкая партнёрская сеть, достаточное количество специалистов на рынке и наработанный кредит доверия, обеспеченный многолетней историей на локальном рынке, сила бренда.
Часть вопросов можно решить правильным маркетингом и подготовкой продажи. Предположим зарубежные клиенты узнают о нас и рассматривают внедрение решений 1С в свою ИТ инфраструктуру. Один из важных вопросов, которые возникают в этот момент - вопрос поддержки. С кем заказчик сможет решать задачи, возникающие в процессе эксплуатации системы? Кто сможет выполнить кастомизацию или тюнинг приложений 1С? К кому обращаться при возникновении ошибок? И так далее. Ответ за редким исключеним всегда один - только к вендору ПО.
Для учётных бизнес-систем такое положение вещей несёт слишком много рисков для собственников бизнеса. Ведь мы как поставщик и разработчик ПО работаем на местном рынке относительно недавно, сама платформа 1С тоже малоизвестна (не сравнить с ситуацией в РФ), плюс предлагаем бизнесу купить софт, который в определённом смысле - чёрный ящик, и кроме специалистов приехавших из России никто внутрь этого "ящика" залезть не может. А что делать бизнесу, когда русские специалисты вернутся домой?
Поэтому в дальних странах важно обеспечить достаточное количество местных специалистов - и разработчиков, и консультантов. И если обучение консультантов является в принципе решаемой задачей, то с разработкой всё гораздо сложнее. Один из факторов, позволивших платформе 1С получить в России широкое распространение - простой и наглядный скриптовый язык. Из-за чего даже у человека незнакомого с разработкой ПО может возникнуть ощущение, что он понимает логику работы программы и при необходимости во всём сможет разобраться, повышается доверие к системе. Ведь русским по белому написано!
Пример кода 1С, как видит его любой человек в России:
Всё просто и понятно. В Канаде, Германии и во Вьетнаме люди видят этот код примерно вот так:
Ответственные лица заказчика и сотрудники его ИТ-службы видят это, когда хотят оценить возможность самостоятельной поддержки решения.
Так же видят код 1С и местные молодые специалисты, которые вдруг задумались "А не выучить ли язык 1С, чтобы стать профессиональным разработчиком?". Доступно и всерьёз©
То, что помогало 1С на Родине, и было одним из конкурентных преимуществ, за рубежом превращается в фатальный недостаток.
Обеспечить приток новых разработчиков и партнёров в других странах, открыть для приложений 1С путь на массовый рынок - можно только с продуктами на английском коде. Для этого существуют, очевидно, два пути - разработка конфигурации "с нуля" на английском языке и перевод русских исходников на английский. В зависимости от конкретной задачи, оба подхода имеют место.
Одна из конфигураций, с которыми мы работаем - переведённая на английский код и локализованная под местную специфику УНФ 1.5. С тех пор русская УНФ получила очень активное развитие в редакции 1.6 и наша переведённая версия сильно отстала по функционалу. Хотелось бы получить новую версию УНФ на английском коде. Далее я расскажу про то, как это было сделано.
Трудности классического перевода
1. Первая проблема связанная с переводом кода - это перевод специфической терминологии.
Классический подход к переводу конфигураций заключается в работе с командой переводчиков через какую-либо CAT-систему, например SmartCat. При этом переводчик видит в своём интерфейсе строку, которую нужно перевести, и определённую информацию о контексте, чтобы выбрать правильный перевод. При переводе кода контекст представляет собой несколько строк кода, которые предшествуют переводимой строке и название объекта конфигурации, в котором расположена эта строка. Но для качественного перевода этого недостаточно. Переводчик должен иметь опыт разработки на 1С, чтобы понять что он переводит. Переводчик должен знать специфическую терминологию платформы, чтобы не исказить и не потерять при переводе информацию, которую несут в себе имена методов и переменных.
Однако переводчики получают деньги за объём текста, за количество переведённых слов, и им неинтересно разбираться в контексте и терминологии платформы. Как переводит человек без знания предметной области? ОрганизацияНаименование переводит CompanyName, потому что не знает, что в платформе Наи переведено как менованиеDescription. При этом нарушается принцип единообразия переводов: нужно всегда использовать один и тот же термин для обозначения одного и того же понятия. РасшифровкаДопРасходов он переводит DecryptionAddCosts, а ПредставлениеДокумента - DocumentPerformance. И это не придуманные примеры, это переводы из реального словаря, полученного таким способом. В итоге имеем "симуляцию" перевода - слова вроде бы английские, но смысл иногда полностью потерян. Такие "переводы" никак не помогут иностранному разработчику, не знакомому с русской 1С.
Как говорится, "Переводи смыслы, а не слова". Чтобы добиться этого, нужна большая работа над качеством словаря. Как правило это совместная работа двух человек - первый хорошо знает английский язык и выполняет переводы, а второй знает 1С и способен выполнить редактуру полученных текстов или помочь с выбором правильного значения слова. Потому что идеальный вариант, когда один человек и имеет опыт разработки на 1С и достаточно хорошо владеет английским языком - в природе почти не встречается.
2. Следующая сложность - выбор правильного перевода для неоднозначных случаев.
Простые примеры для иллюстрации: как перевести Счёт? Если имеется в виду счёт плана счетов или счёт в банке, то это Account. А если имеется в виду счёт на оплату, то перевод InvoiceForPayment. Посмотрите на примеры из словаря, сможете сразу определить где переводчик выбрал удачные переводы, а где нет?
- АнализОплатыСчета = InvoicePaymentAnalysis
- ТипСчетаСписания = AccountTypeWriteOff
- ОткрытьСобытияПоСчету = OpenEventsByBill
- ОснованиеЗаказСчет = BasisOrderAccounts
- НомерСчетаОрганизации = AccountNumberOrganization
- СтруктураСчетов = AccountsStructure
Человеку, который работал с бухгалтерскими и торговыми конфигурациями, некоторые ошибки здесь сразу бросаются в глаза даже без информации о контексте. Достаточно соседства слов, т.к. глаза видели эти словосочетания уже очень много раз, и память хранит эти связи. А переводчику не знакомому с 1С выбрать правильное значение без посторонней помощи гораздо сложнее.
Обработка - это Processing или DataProcessor? Глаз разработчика безошибочно считывает контекст, которого не видит переводчик: ГрупповаяОбработка, ОбработкаПолноеИмя, ОбработкаЗавершена, ВнешняяОбработка, ОтложеннаяОбработка, ПолеОбработкаВыбора, ОбработкаОбъект.
Реальный словарь кода в большой конфигурации насчитывает многие тысячи подобных примеров. В результате трудозатраты на последующую редактуру и исправления переводов сопоставимы с трудозатратами на сам перевод и превышают его. Эх, вот если бы "загрузить" все эти связи в голову переводчика и добавить к его знанию английского языка информацию о терминологии и контекстах!
3. Некачественный перевод
Помимо сложностей с выбором правильной терминологии и разрешения неоднозначных ситуаций, перевод может быть некачественным и по другим причинам. Вспомним приведённые выше примеры:
- НомерСчетаОрганизации = AccountNumberOrganization
- ОткрытьСобытияПоСчету = OpenEventsByBill
Откуда взялись Organization и Bill, если соответствующие объекты переведены в конфигурации как Company и InvoiceForPayment? Нарушается принцип единообразия.
Кроме того, неверно выбран порядок слов для перевода родительного падежа. Похоже, что переводчик вообще не понял смысл написанного и просто перевёл отдельные слова. Падежные связи в английском языке (притяжательный падеж) передаются через порядок слов или предлог Of. Определение в форме существительного в притяжательном падеже ставится перед определяемым словом, а определение, выраженное существительным с предлогом, - после определяемого существительного. Правильный перевод будет такой: НомерСчетаОрганизации = CompanyAccountNumber.
Чтобы корректно перевести на английский отношения объектов, выраженные родительным падежом, нужно правильно понимать связи объектов и понятий, которые существуют в платформе. Подобные цепочки определений очень широко используются в именах идентификаторов и могут быть достаточно длинными.
Проиллюстрирую на нескольких примерах из словаря УНФ, с объяснением структуры имени, которая важна для правильной передачи смысла. Зелёным цветом выделен контекст, который опущен, но подразумевается:
- ГруппаОтборД о пРеквизитыВладелецПартии
читаем: Группа (имя группы) "Отбор". (подгруппа) "Дополнительные реквизиты". (элемент) "Владелец партии",
перевод: Group "Filter". "Additional attributes". "Batch owner"
GroupFilterAdditionalAttributesBatchOwner - Настро ить Вид имостьКолонокСпискаРасшифровкаДоговораОбслуживания
читаем: Настроить (что?) видимость (чего?) колонок списка (далее имя списка) "Расшифровка договора обслуживания",
перевод: Configure visibility of "Service contract details" list columns
ConfigureVisibilityOfServiceContractDetailsListColumns - ВидЦен СебестоимостиОбработкаВыбораЗавершение
читаем: Вид цен (чего?) себестоимости. (имя события) "Обработка выбора". (шаг обработки события) Завершение,
перевод: Cost price kind. "Choice processing". Completion
CostPriceKindChoiceProcessingCompletion - ДвиженияДенежныеСредстваВРезервеПередЗаписью
читаем: Движения (по регистру) "Денежные средства в резерве". (имя события) "Перед записью",
перевод: Register records "Cash assets in reserve". "Before write"
RegisterRecordsCashAssetsInReserveBeforeWrite
Здесь я явно указал информацию о значениях и отношениях объектов, которую человек знакомый с 1С считывает интуитивно. Но у переводчика нет этой "интуиции", и для него подобные имена зачастую выглядят как быссмысленное скопление слов, которое он чисто механически переводит таким же бессмысленным скоплением слов на английский.
Новый подход к переводу
Итак, мы видим что для качественного перевода кода, нам нужен переводчик, которого мы можем "научить 1С". Можно обучить настоящего живого переводчика, правда процесс это небыстрый и сам по себе является сложным и "узким" местом - далеко не всякий переводчик начнёт этим заниматься, ещё меньше - добьются желаемого результата. Однако подобное "обучение" - это одна из тех областей, в которых сегодня преуспели машины.
Как вы знаете, современные системы машинного перевода такие как Яндекс-переводчик, Google-translate или Deepl.com построенны на механизме обучения. В этих системах применяется принцип статистического анализа: в программу загружаются огромные объёмы текстов на исходном языке и их переводы, выполненные человеком. Программа анализирует статистику межъязыковых соответствий, синтаксических конструкций и т. п., а затем опирается на неё при выборе вариантов перевода. За последние несколько лет нейросети превзошли всё, что было придумано в машинном переводе за последние 20 лет. Они даже научались согласовывать роды и падежи в разных языках.
Однако если мы попробуем выполнить перевод кода УНФ в Яндексе или Google, результат будет неудовлетворительным, т.к. эти системы ничего не знают про понятия и термины платформы 1С, а так же про переводы уже используемые в словаре конфигурации.
Необходимо выполнить обучение переводчика с помощью подготовленного "профильного" словаря. Такую возможность предоставляют, например, Microsoft - сервис Custom Translator, и Google - сервис AutoML. Я использовал систему от Microsoft, т.к. результат, который выдавал bing.com/translator для перевода кода был релевантнее чем translate.google.com. В добавок, сервис от Google значительно дороже.
Работа с Microsoft Custom Translator
Документация по работе с Custom Translator достаточно подробна и доступна на официальном сайте. Я вкратце перечислю шаги по созданию и обучению новой модели перевода.
- Зарегистрироваться на порталах Microsoft Azure и Custom Translator
- На портале Custom Translator создать новый проект. В свойствах проекта указываются языковая пара, для которой планируется выполнять перевод и категория переводов - я выбрал Technology. Ещё пробовал категорию Business, но с Technology переводы получаются точнее.
- Нужно загрузить в проект переводы, на которых система будет обучаться. Я использовал для обучения словарь БСП и неполный словарь УНФ, собранный из доступных источников. Про работу по компиляции словаря конфигурации из произволных существующих словарей я писал в прошлой статье.
Есть несколько типов файлов для обучения:- Training (обязательный) - общий файл словаря, который система использует для формирования "нейронных связей". Основную часть исходного словаря нужно поместить в этот файл. При начале обучения модели Custom translator автоматически исключит из этого словаря предложения, которые присутствуют в Tuning и Testing словарях
- Tuning (необязательный) - "настроечный" словарь. По смыслу это такой же словарь, как и Training, но информация из него имеет больший "вес" при обучении системы и соответственно оказывает большее влияние на результат. Нужно ответственно подойти к формированию этого файла - все переводы в нём должны быть выверенные и точные. Если не подготовить tuning-словарь, то система сформирует его сама из рандомного набора переводов Training-словаря. Но в этом случае результат обучения будет подвержен случайности, т.к. для тюнинга могут быть подобраны и не самые удачные переводы.
- Testing (необязательный) - словарь содержащий эталонные переводы, которые Вы считаете правильными. После обучения новой модели Custom translator выполнит перевод слов из тестового словаря, сравнит результат с эталонным переводом и рассчитает показатель BLEU Score. Это коэффициент, который показывает насколько близки к желаемому результату переводы выдаваемые обученной моделью. Если не указывать данный файл, система сформирует его автоматически из случайных строк Training словаря.
- Phrase Dictionary (необязательный) - список фиксированных переводов. В этом словаре указаны слова, которые нужно переводить не нейросетью, а просто взять перевод из файла. Хорошо применять для имён собственных. Например наша конфигурация называется "Company management", поэтому я указал, что УправлениеНашейФирмой всегда нужно переводить CompanyManagement, а аббревиатуру УНФ - CM.
- После того как исходные данные для обучения загружены, нужно нажать кнопку "Create model". Запускается процесс обучения, а по окончании Вы увидите рассчитанный показатель Bleu Score и сможете скачать для ревизии результат перевода тестовых данных, чтобы принять решение - устраивает ли Вас качество переводов, выдаваемых машиной. Если качество перевода устраивает - обученную модель можно опубликовать и использовать для перевода произвольных текстов.
- Немного о подготовке исходных данных. Системе нужны для обучения пары переведённых предложений, разбитые на два .align файла: файл предложений на русском языке и файл их переводов на английский. Поскольку мы переводим код, исходный словарь у нас выглядит так:
ИменаДобавляемыхКолонок AddedColumnNames ОбработатьДанныеДляОбновленияВПодчиненномУзле ProcessDataToUpdateInSubordinateNode ПараметрыФормыПросмотраФайла FilePreviewFormParameters
Имена Добавляемых Колонок Added Column Names Обработать Данные Для Обновления В Подчиненном Узле Process Data To Update In Subordinate Node Параметры Формы Просмотра Файла File Preview Form Parameters
Имена Добавляемых Колонок Обработать Данные Для Обновления В Подчиненном Узле Параметры Формы Просмотра Файла
Added Column Names Process Data To Update In Subordinate Node File Preview Form Parameters
В таком виде словари готовы к загрузке в систему.
Перевод кода с помощью обученной модели включает следующие шаги:
- С помощью Language Tool выгружаем из конфигурации список слов, требующих перевода - "пустой" словарь
- Выполняем преобразование пустого словаря из CamelCase в набор слов разделённых пробелом, как показано выше
- Полученный документ переводим с помощью Microsoft Document Translator, которй подключен к нашей опубликованной модели переводчика. Программа формирует файл с переводами.
- Соединяем пустой словарь из шага 2 с файлом переводов из шага 3
- Выполняем обратное преобразование к CamelCase - удаляем пробелы
- Получился готовый словарь кода, который можно отдать Language Tool и запустить перевод конфигурации. (Только нужно заменить в словаре разделитель с табуляции на знак '=')
Приведу несколько примеров переводов, которые выдаёт система
АвтономнаяРаботаЗарегистрироватьИзменениеДокументаПередЗаписью StandaloneOperationRegisterDocumentChangeBeforeWrite
ВидЗака зНа рядаДляНовыхКлиентовПриИзмененииСервер JobOrderKindForNewCustomersOnChangeServer
Выбор каИз ТабличнойЧастиЗапасы SelectionFromTabularSectionInventory
ВыборкаСклады SelectionWarehouses
ВыводТекстаНаДисплейПокупателяЗавершение OutputTextToCustomerDisplayCompletion
ЗарегистрироватьЦеныНоменклатуры RegisterProductsAndServicesPrices
Подключ аемый_НаименованиеОбработкаВыбора Attachable_DescriptionChoiceProcessing
ПолучитьПодписиПоУмолчаниюНаСервере GetDefaultSignaturesAtServer
РегистрНакопленияДенежныеСредстваВРезерве AccumulationRegisterCashAssetsInReserve
РегистрСведенийЗначенияКатегорийПользовательские InformationRegisterCustomCategoryValues
СписокНаименований DescriptionsList
СуммаЗаказовПоставщику PurchaseOrdersAmount
СформироватьСпецификацию GenerateSpecification
УстановитьУсловноеОформлениеПоЦветамСостоянийСервер SetConditionalAppearanceByStateColorsServer
ФормаП ечати PrintForm
ФормаПл анОбменаОбменУправлениеНебольшойФирмойСайтПерейтиВЖурналРегистрацииСобытийВыгрузкиExchangePlanFormExchangeCompanyManagementSiteGoToExportEventLog
Как видно, корректно переведены термины платформы, названия объектов метаданных, реквизитов, контекст выполнения и имена событий.
Перевод комментариев
Итак, у нас переведён весь код и имена метаданных. Далее хотелось бы перевести комментарии к процедурам и функциям, так как это ценный источник информации для англоязычных разработчиков. Тем более что нормальной документации на английском языке пока не так много.
Для перевода комментариев я использовал тот же подход, что и для перевода кода, но с несколькими дополнительными особенностями:
- Перевод комментариев выполняется по правилам перевода технической документации. По сравнению с переводом кода, это ближе к обычному литературному переводу. Поскольку нам нужно, чтобы переводы формировались по новым правилам - мы не можем использовать модель обученную для перевода кода. Создаём новую модель - в том же проекте либо в отдельном. Для обучения модели я использовал базу перевода комментариев из тех же словарей, откуда брал перевод кода.
- Формат документирующего комментария к методу описан на ИТС. EDT использует документирующие комментарии для расчёта типов и генерации подсказок при наборе кода. Если исходный комментарий на русском языке написан в соответствии с требованиями этого формата, перевод тоже должен ему соответствовать. Т.е. при переводе важно сохранить форматирование - отступы, табуляцию, переносы строк, служебные символы (-, *, :)
- В комментариях могут встречаться имена типов, объектов метаданных, модулей, процедур, функций и т.п. Всё это мы уже перевели на предыдущем этапе - при переводе кода. И сейчас необходимо использовать для этих ссылок готовые переводы, а не переводить заново. Иначе с большой вероятностью переводы будут отличаться и ссылка в комментарии "сломается".
Результат перевода конфигурации
Код и объекты метаданных конфигурации полностью переведены на английский язык:
Запросы:
Шаблоны СКД:
Имена параметров и областей в макетах:
Комментарии к методам:
Проблемы после перевода
Новая терминология
Обученная модель прекрасно справляется с переводом понятий и терминов, которые уже встречались в словаре использованном для обучения. Но если перевести какой-то новый термин, система будет импровизировать, и результат может быть нестабильным.
Так, например, в УНФ 1.6 появилась подсистема CRM, и в словарь добавилось множество имён, включающих понятие "Лид". Это слово до этого не встречалось у нас в конфигурации, поэтому у машинного переводчика не было соответствующих "нейронных связей". Слово "Лид" система переводила как "Lida", приняв за имя собственное.
Ещё в последних версиях УНФ появилась подсистема Биллинга и новое понятие "Договор обслуживания". Мне хотелось, чтобы ДоговорОбслуживания везде переводился как ServiceContract, но система выдавала разные переводы в зависимости от контекста.
Такие ситуации после машинного перевода нужно исправлять вручную, но это относительно небольшой объём работы. Просто нужно помнить про эту особенность.
Неоднозначности переводов
Выше я писал про пример со словом "Расшифровка" - иногда это Details, как в РасшифровкаПлатежа - PaymentDetails. А иногда и Decryption (в подсистеме ЭДО). Хотя это редкость. Классический пример - слово "Строка". Если речь идёт о строке текста, то перевод "String", а если о строке таблицы или дерева - "Row". Плюс в платформе свойство "НомерСтроки" переведено как "LineNumber". Какой перевод выдаст машина - String, Row или Line? Выбор перевода осуществляется на основании контекста:
УчетЗатратНомерСтроки CostAccountingLineNumber
МассивС тр окЗапасовInventoryRowsArray
НоваяСтрокаЗапроса NewQueryString
Однако из имени идентификатора не всегда можно правильно определить контекст и выбрать корректный перевод. Зачастую из имени непонятно какая "строка" имеется в виду, пока не посмотришь в код. Поэтому ситуации с неоднозначными переводами остаются потенциальным источником ошибок, и после машинного перевода желательно проверить наиболее распространённые случаи.
Типизация кода
Плагин EDT Language Tool при выборе перевода опирается на типизацию кода. Если переводимый объект - платформенный, то перевод берётся из словаря платформы. Если объект пользовательский - то переводит по пользовательскому словарю. Однако в 1С код нетипизированный, и EDT рассчитывает типы динамически. Это не всегда возможно, поэтому для минимизации ошибок переводы в пользовательском словаре нужно делать такими же как в платформе. Например, если "Наименование" в платформе переведено как "Description" - не нужно в пользовательском словаре указывать перевод "Наименование=Name".
Полностью типизированный код 1С на сегодняшний день - это утопия. Но полной типизации и не нужно. Достаточно указать в пользовательском словаре те же переводы, которые используются в платформе. Есть несколько ситуаций, когда это невозможно:
- Нас не устраивает перевод из платформы и мы сознательно указываем в пользовательском словаре другой перевод. Слово "Организация" переведено в платформе "Organization" (свойство объектов ДанныеКонтакта и ПочтовоеСообщение). Это достаточно редкие случаи по сравнению с реквизитом "Организация", который есть во всех документах и многих других объектах метаданных. Пишем в словаре английский термин, который нам нужен: "Организация=Company" и после перевода конфигурации исправляем термин "Organization" там, где он появился.
- Разные слова в словаре платформы имеют совпадающий перевод. "Тип" и "Вид" в платформе переводятся одинаково - "Type". Но мы не можем указать для этих слов одинаковый перевод в пользовательском словаре, поскольку это приведёт к конфликту в объектах, в которых есть оба свойства. Например, у контактной информации есть свойства "Ти" и " пВи" - нельзя переводить их одинаково. Для слова " дВид" указываем перевод "Kind", однако Language Tool всё равно в некоторых местах переводит "Вид" как "Type", поскольку код нетипизирован. Поэтому для таких слов нужно либо явно указывать тип в коде, либо исправлять ошибки после перевода.
Я считаю подобное поведение плагина ошибочным, т.к. некорректно брать из словаря платформы совпадающие переводы без дополнительных проверок. Надеюсь что в будущем эта ситуация будет исправлена.
Образование дублей
Русский язык по своей структуре является языком синтетического типа и обладает флексивным (то есть гибким) строем. Большое количество информации передаётся в рамках одной морфемы с помощью флексий: предлоги, суффиксы, окончания. Словоизменение активно используется и играет важную роль. В синтетических языках грамматические значения и отношения с другими словами выражаются в рамках самого слова с помощью падежей, склонений и прочих средств. Благодаря этому порядок слов в предложении не так важен и зачастую можно поменять слова местами без потери смысла.
Английский, напротив, является языком аналитического типа. Грамматические отношения слова передаются в основном через определённые служебные слова, фиксированный порядок слов и контекст. Сами слова при этом остаются неизменными по форме или меняются слабо.
Следствием этого различия языков является то, что при переводе имён методов и переменных неизбежно образуется большое количество дублей. Сложное придумать различающиеся переводы для подобных случаев:
Произвольное Arbitrary
Произвольные Arbitrary
Произвольный Arbitrary
ДокументОснованиеСумма BasisDocumentAmount
СуммаДокументаОснования BasisDocumentAmount
ДополнительныеСвойства AdditionalProperties
СвойстваДополнительные AdditionalProperties
Плюс некоторые русские слова сами по себе переводятся на английский одинаково. Такие как: Кол и о нкаСт = о лбецColumn, Заказ и Порядок = Order.
Список подобных дублей в словаре конфигурации насчитывает почти десять тысяч строк. Понадобилось бы значительное время для ручной обработки всех дублей из словаря такого размера. Чтобы сократить объём этой работы учтём, что не всякое дублирование перевода является ошибочным. В нашем примере выше ДокументОснованиеСумма - это имя реквизита на формах некоторых документов, а СуммаДокументаОснования - имя переменной, использованной в модуле документа СчетФактура. Если после перевода и там и там будет указано имя BasisDocumentAmount ничего страшного не произойдёт. Напротив, произойдёт некая унификация используемых терминов, что даже хорошо.
Необходимо исправить те дубли, которые встречаются в рамках общего пространства имён. Я называю их "опасные" дубли. Опасными дублями могут быть два элемента на одной форме, две переменных в одной процедуре, две колонки в таблице и т.д. Скажем, у справочника есть реквизиты Пок и упат ел ьЗаказчик, а по словарю переводы совпадают - Customer. Такие ситуации нужно устранить, указываем перевод "Поку= пательBuyer".
После фильтрации по совпадающеиму пространству имён список дублей уменьшился в несколько раз, и я исправил переводы найденных "опасных" дублей.
Сравнение стоимости перевода
Тарифы на использование Microsoft Custom Translator:
На сайте сейчас указано по старому курсу, в долларах цены такие: 40$ за миллион символов перевода, 10$ за миллион символов обучения и 10$ за публикацию обученной модели.
Стоимость человеческого перевода 4.4 рубля за одно слово (без учёта редактуры).
Оценим сколько бы стоил перевод кода УНФ силами профессиональных переводчиков.
У меня получился словарь из 48 000 строк. После преобразования CamelCase в обычный текст это 190 000 слов. Стоимость перевода 836 тысяч рублей, а срок 4-6 месяцев работы.
Добавим сюда перевод комментариев. Объём словаря составляет 356 000 слов. Стоимость перевода 1.5 миллиона рублей, а срок 8-12 месяцев.
Итого 2 миллиона 300 тысяч рублей и полтора года работы переводчика (или полгода для команды из трёх человек).
Сравним со стоимостью машинного перевода.
Перевод кода:
Обучение модели 40$
Публикация модели 10$
Перевод текста 43$
Перевод комментариев:
Обучение модели 77$
Публикация модели 10$
Перевод текста 50$
Итого 230$ (18 000 рублей), срок 1 день (при наличии словаря, подготовленного для обучения).
Интересные цифры, не так ли? Ранее перевод большой конфигурации силами одного специалиста являлся неподъёмной задачей.
Стоит заметить, что 230$ это конечная сумма за перевод, если бы я делал его сейчас. На самом деле я прошёл некоторый путь к этой точке, экспериментировал с обучением, делал несколько тестовых моделей. Поэтому реальная стоимость для меня получилась выше, эту разницу отнесём к расходам на НИОКР.
Для тех, кто заинтересовался темой, добавлю, что возможна бесплатная работа с Custom Translator. При бесплатном использовании нельзя опубликовать обученную модель для перевода произвольных текстов, но можно оценивать качество перевода на тестовых данных. И есть ограничение на размер словаря для обучения. Для знакомства с системой вполне подойдёт бесплатный тариф.
Плюс при первой регистрации на портале Azure Вам будет начислено 200$ бонусов, которые можно использовать в зачёт оплаты Custom translator при переходе на платное использование.
Перспективы и новые возможности
Перевод кода других конфигураций
Обученную модель перевода кода УНФ можно использовать и для перевода кода других конфигураций из смежных предметных областей, например 1С:Розница или 1С:Управление торговлей.
Перевод интерфейсва
Аналогичный подход можно использовать и для перевода интерфейса конфигураций на другие языки. Я ожидаю что с переводом интерфейса нейросеть справится даже лучше чем с переводом кода, так как в сущности это обычный литературный перевод. А качественного материала для обучения существует более чем достаточно, поскольку к переводу интерфейса обычно подходят более ответственно чем к переводу кода.
Обновление вместе с русской конфигурацией
Во всех известных мне прежде примерах адаптации типовых конфигураций для работы в другой стране, связь локализованной конфигурации с родительской конфигурацией безвозвратно терялась после перевода. Обновление на новый релиз конфигурации-родителя становится слишком дорогостоящим проектом и от него просто отказываются. В итоге с годами отставание от исходной конфигурации увеличивается всё больше и рано или поздно встаёт вопрос о новом проекте по локализации русской конфигурации актуального релиза.
Сегодня, используя возможности Git, Language Tool и обучаемый машинный перевод становится возможным выпускать релизы локализованной УНФ на английском коде практически синхронно с релизами русской типовой конфигурации (с отставанием в один релиз).