Локализация интерфейсов конфигураций. Практика и инструментарий 1Ci

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

Что нужно для успешной локализации интерфейса

Что нужно для успешной локализации интерфейса:

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

• И вам обязательно придется доработать ваш продукт для того, чтобы этот интерфейс в нем вообще работал, запустился. 

Вторая часть для вас, я думаю, более понятна. А с первой я начну.

Выбор инструмента перевода

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

Поскольку этим вопросом мы занимались еще в самой компании «1С», а там так исторически сложилось, что если решение нужно, значит, его нужно написать – был создан «1С:Переводчик». Это был 2011-2012 год. Тогда это был огромный скачок вперед. У нас не было ничего, и тут нам дали что-то, с чем можно работать, что решало все наши задачи и писалось специально под нас при нашем участии. Поначалу, когда мы только ввязались в это дело, «1С:Переводчик» полностью закрывал наши потребности. Но мы стали переводить конфигурации, которые все больше по размерам, и уже на уровне Библиотеки Стандартных Подсистем (БСП) столкнулись с тем, что особенности платформы и используемых решений приводили к тому, что уже на объемах БСП (которая меньше, чем любая конфигурация, куда БСП входит) некоторые действия переводчика обрабатывались до 5 минут. Работа строилась так: пользователь создает для элемента перевод, сохраняет его, после чего 5 минут ждет, пока программа анализирует, все ли он сделал хорошо, ничего ли не нарушил, не испортил. Это, естественно, очень сильно повлияло на стоимость перевода. Потому что, во-первых, тратилось много времени, а во-вторых, самых лучших переводчиков мы из-за этого стали терять. Люди отказывались работать по своей обычной сдельной ставке, потому что, если из-за особенностей продукта им приходится делать в три раза меньше, то либо это будет стоить в три раза дороже, либо мы разрешим им работать на том инструменте, который их устраивает, либо «ищите других людей». До определенного этапа мы пытались с этим как-то бороться, но, когда стартовал перевод на английский язык интерфейса конфигурации 1С:ERP, оказалось, что засунуть эту конфигурацию в «1С:Переводчик» просто нельзя. 

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

Из готовых продуктов, который мы могли бы себе установить, мы рассматривали, например, Trados – это лидер рынка, все переводчики его знают. Найти людей для работы с ним очень легко. Но проблема в том, что стоимость подобных продуктов зависит от количества пользователей, либо от объемов текстов. А поскольку у нас на проектах на текущий момент (2018 год –  прим. редакции) работает 62 человека (подавляющее большинство - внешние подрядчики), а размеры интерфейсов некоторых конфигураций исчисляются миллионами слов, то, если бы мы взяли подобные решения, расширение списка продуктов, для которых мы готовим интерфейсы, стоило бы очень дорого. 

Поэтому мы пошли в сторону облачных решений и остановились на Smartcat.

Обеспечение качества переводов в Smartcat

Что такое Smartcat? Это платформа для переводов, которая закрывает две задачи. 

• Во-первых, это сама среда, где мы переводим. 

• Во-вторых, это некий маркетплейс, где можно взять сотрудников и переводчиков. 

Что нам дает среда? За счет чего мы делаем переводы быстрее, дешевле и без потери качества?

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

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

• Дальше – нас многие спрашивают, работают ли у нас на переводе носители конечного языка? Например, переводят ли у нас на английский носители английского? Мы тоже с этого начали, но поскольку изначальные тексты могут быть очень технически сложные, мы пришли к тому, что у нас на самых ответственных проектах, как правило, работа идет в три этапа – есть переводчик, редактор и корректор. Причем, переводчик – это всегда носитель исходного (в большинстве случаев, русского) языка. Если мы в качестве переводчика сразу же ставим англичанина, американца, то на выходе получаем красивый текст, который по смыслу не очень совпадает с тем, что мы имеем. Причем, есть проекты, где исходный язык не русский, например, 1С:Drive, там исходный язык английский, и с английского мы уже переводим на все остальные языки.

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

• И сниппеты – это окружение, контекст, слепки текста.

Вот как все это выглядит:

• У нас есть подсказки – либо полное совпадение, либо частичное;

• У нас есть параметры в виде плейсхолдеров, которые переводчик не может испортить;

• У нас есть кусок кода, если это идет из кода;

• И есть еще очень много других подсказок. 

Этот текст – пример того, как мы переводим 1С:Drive с английского на вьетнамский.

Где взять переводчиков

После того, как мы определились со средой для переводов, где нам взять переводчиков? 

• За последние 6 лет у нас уже наработана очень большая база переводчиков. Мы их не скрываем и делимся этой базой с теми партнерами, которые тоже столкнулись с задачей перевода 1С-ных конфигураций, даем им рекомендации.

• Дальше – если мы выходим на какой-то новый рынок, то обычно начинаем с того, что обращаемся к партнеру 1С, который работает в этой стране, к его опыту – наверняка он уже с кем-то работал, сталкивался с проблемой перевода. Даже если мы ищем переводчиков сами, их все равно верифицируют партнеры в конечной стране. 

• Как я уже говорил, сам Smartcat – это еще и биржа фрилансеров, где мы объявляем большие наборы. На каждый из них к нам обычно приходит порядка 80-90 тестовых работ.

Проверка уровня переводчика при подборе

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

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

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

Автоматизация выгрузки текстов. Наше решение 1Ci SmartSync

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

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

Чему мы научили утилиту SmartSync?

• Работать только с текстами по выбранным подсистемам. Очень часто, особенно в начале, либо на этапе продажи, либо на пилотных проектах полный перевод не используется. Если мы или партнер пытаемся «выйти в страну», и нам в первом кейсе нужны только продажи/закупки, мы переводим только продажи/закупки плюс всю базовую функциональность

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

• Передаем сниппеты (максимально контекст) для тех подсистем или для тех частей, которые не переведены.

• Умеем подставлять исходный текст в перевод. То есть, если нам 1C:Drive нужно быстро перевести на какой-то язык, мы можем перевести только несколько подсистем, а остальные оставить на английском.

• И, важная часть, умеем верифицировать конфигурацию на готовность интерфейса к переводу.

Проверка готовности продукта к добавлению нового интерфейса

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

Чтобы перевод интерфейса можно было загрузить в конфигурацию и предоставить пользователю, нам важно пройти несколько шагов и несколько проверок. 

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

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

• И последнее – это то, о чем почему-то забывают – что все эти изменения в конфигурации надо кому-то делать. На больших проектах уровня ERP у нас выходит, что 45% ресурсов – это непосредственно перевод, а еще 55% – это работа команды разработки, чтобы этот перевод вообще «взлетел», чтобы им можно было пользоваться. То есть, для нового продукта объем доработок кода чуть-чуть превышает объем работы по переводу самого интерфейса.

Здесь перечислены основные проверки, которые реализованы в 1Ci SmartSync.

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

Итак, как у нас сейчас выглядит перевод интерфейсов?

Мы работаем с XML-файлами конфигурации, выгруженными стандартными средствами конфигуратора. Дальше наша утилита проводит валидацию конфигурации. Причем, после того как мы получили отчет о том, сколько нам вообще придется работать внутри кода и дорабатывать, очень часто дальше проекты идут в параллель – разработчики вносят изменения, а мы уже переводим интерфейсы. Дальше тексты извлекаются из XML-файлов, отправляются на перевод. Переводим в SmartCat с использованием всех наработок, которые у нас были до этого. То есть, если в конфигурации есть БСП, то все старые переводы БСП приезжают сами. Загружаем переводы обратно, собираем и отправляем на тестирование.

Что может предоставить 1Ci для ускорения и удешевления переводов

Что мы сможем предложить для вас в следующем году?

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

Для партнера процесс перевода будет выглядеть следующим образом:

• Пункт 0 – стать партнером;

• Пункт 1 – загрузить конфигурацию в виде cf-файла к нам;

• Получить отчет о валидации, обработать его, исправить ошибки;

• Если вы считаете, что конфигурация готова для перевода, разрешить отправку текстов в Smartcat;

• Перевести;

• И собрать конфигурацию обратно.

Важная часть – Smartcat как сервис бесплатен, он монетизируется только за счет оплаты работы переводчикам. А если вы регистрируетесь в Smartcat, и у вас переводчиками работают только ваши сотрудники (либо вы сами), то сервис абсолютно бесплатен.

Вопросы:

• А с обычными формами работает эта утилита?

• С обычными формами эта утилита не работает, потому что с обычными формами мы сами уже больше не работаем.

• Речь о переводе только интерфейсов или самого кода?

• Речь о переводе только интерфейсов. Изыскания по переводу кода проводятся.

• Я так понял, что используется выгрузка в XML конфигурации, почему не используется штатная выгрузка текстов интерфейсов из конфигурации?

• Штатная выгрузка текстов интерфейсов хорошо работает на выгрузку, но не работает на загрузку. Если вы делаете выгрузку, вы можете включить поле, которое описывает место вхождения перевода. А при загрузке это поле не используется. Соответственно, все тексты из 1-2 слов, которые переводятся по-разному, обратно приедут вперемешку. Когда мы стали работать с XML-файлами, мы решали именно эту проблему.

• То есть, у вас перевод выполняется с привязкой к месту? Одни и те же фразы в разных местах конфигурации переводятся несколько раз?

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

• Но в Smartcat вы их храните с привязкой к месту?

• В Smartcat все хранится с привязкой к месту, просто если большие куски встречаются несколько раз, их можно перевести один раз, и все проставится автоматически.

• А что с макетами, со справкой?

• Макеты также переводятся. Справка также переводится. Как раз наша утилита умеет переводить их не в те же самые макеты, а в отдельные. То есть, если макет стандартный – то можно держать несколько языков прямо в нем. А если это doc-файл или что-то еще, тогда перевод приезжает в отдельный файл, и здесь как раз должна сразу же команда завестись на то, что есть несколько макетов. И дальше уже идет работа по адаптации структуры конфигурации с учетом добавленных макетов.

• Планируется ли встроить в EDT какой-то плагин, в котором пишешь, например, НСтр, и чтобы система сразу же подсказывала перевод, чтобы сразу синхронизация с переводом была?

• Мы пока разработку такого плагина не планируем.

• А инструмент SmartSync пока не доступен? Его можно как-то получить?

• Мы им уже пользуемся, а партнеры смогут им пользоваться в обозримом будущем.

• Планируется ли в ближайшие месяцы провести какой-то вебинар, чтобы увидеть, как это будет?

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

• Переводите ли вы в интерфейсе все? Например, если есть какие-то скрытые, невидимые для пользователя группы – переводите ли вы их?

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

• Очень часто программисты забывают написать синонимы для элементов формы. А если нет синонима, то нет тега синонима, и при парсинге XML-файла с помощью XSLT-преобразования ничего не находится. 

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

• Подскажите, как будет возможно ли при поставке конфигурации выбрать интересующий язык? В частности, 1С:Drive будет поставляться как мультиязычное решение? Или можно будет сгенерировать его для конкретного языка, который меня интересует? Например, мы пользуемся украинской УТ3.0, но используем в ней только русский язык. И у меня в практике была проблема, когда в ряде обновлений начало происходить 90% изменений конфигурации. В первом обновлении в 1С решили изменить префикс удаленных объектов (с «Удалено» на «Видалено»). А на следующем релизе ко мне пришли изменения, которые я вообще видел, а проблема была в том, что они английскую «i» заменили на украинскую, которая визуально ничем не отличается. Вопрос в том, что, если выходить на рынок и выпускать мультиязычные решения – как лучше делать? Бандлами или на каждый конкретный язык отдельно? Чтобы люди, которые занимаются поддержкой локального решения для локального рынка не страдали тем, что они вынуждены обновляться и искать подводные камни, связанные с локализацией, которая их в принципе не интересует.

• У нас была такая ситуация, когда в конфигурации везде в конце предложений проставили точки, и к нам все это приехало на перевод как новые тексты. Как мы решаем эту проблему у нас? Разработка ведется только на одном языке. Все переводы хранятся в Smartcat, а Smartcat умеет отлавливать «серьезность» изменений в сегменте. Когда приезжает новая версия, технически мы можем сделать сборку с любым набором языков. С каким будем делать – зависит от запроса. Стандартно, когда к нам приезжает 1C:Drive, мы делаем сборку со всеми внешними языками. Но опять же, технически нам совершенно не сложно в нашей системе реализовать сборку для конкретного языка. И, соответственно, для партнеров, которые будут потом пользоваться нашим сервисом, набор языков на выходе может быть любой.

• Мы столкнулись с тем, что, когда перевод планируется на большое количество языков, код 1С превращается просто в кашу. Допустим, есть фраза «Не хватает остатка на складе». Мы у себя в интерфейсе делали эксперимент – делали для нашей конфигурации через Crowdin перевод на 30 языков, грубо говоря, просто через Google Translate. Все это подгрузили, просто чтобы посмотреть, что это будет. Во-первых, 30 языков у нас не запустилось, платформа падала, мы ограничились 25. Но в итоге, мы открываем в конфигураторе модуль, видим вызов метода СообщитьПользователю, и на полэкрана перечисление всех этих переводов. Отсюда вопрос, как нам, как разработчикам ядра, быть? Вроде все просто – берем, пишем на английском код, дальше просто патчим конфигурацию и получаем эту портянку. А конечным потребителям (разработчикам конфигурации) приходится работать с этой портянкой. У них половина экрана занимает этот НСтр. В итоге мы вообще отказались от такого указания НСтр, сделали переопределение через переопределяемые общие модули и мы там сделали отдельный кластер с описанием всех этих локалей, а там, где идет вызов, мы сделали аналог вызова языка из файловых ресурсов (по аналогии с языками, которые изначально ориентированы на мультиязычность, где все сделано через rstring-файлы). Я так понимаю, что вы тоже столкнулись с такой же проблемой, есть ли какие-то мысли о том, куда двигаться в этом плане, чтобы на это не нарываться?

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

• Получается, что, если у меня текст состоит из двух кусков НСтр, между которыми переменная, этот текст разобьется?

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

• Существует практическая задача – есть конфигурация, которая используется только в России, но компания возит грузы в Китай, и необходимо печатать документ на китайском языке. При этом конфигурация на обычном приложении 8.2. Может ли ваша практика как-то помочь в решении этой задачи? 

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

• Был ли у вас опыт или потребность в локализации существующих данных?

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

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

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

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION.