Доброе время суток. Сегодня я хочу поговорить про перевод решений на базе 1С.

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

И, в момент проектирования нашего решения, одним из ключевых факторов стал – перевод всех этих расширений, макетов и прочего.

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

Т.е. нас интересовал такой концепт:

Программисты не знают о том, что существуют переводчики.

А переводчики не знают о том, кто пишет программу.

Почему? Все просто. Языковой барьер между переводчиками и программистами, стоимость времени программиста, выделение отдельного времени команды на это все и т.д. Все значительно усложняется тестами, и полным CI/CD контуром, при его наличии, а без него — переводить большие конфигурации — не реально.

Итого, писать или не писать свой продукт для перевода — это решение каждой команды отдельно. Например, в нашем случае — у нас было четкое понимание и обоснование.

Основание создания продукта

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

В результате, было посчитано, что в среднем, на команду из 5 человек разработчиков, 3 переводчиков, одного QA инженера и релиз инженера — мы тратили порядка 100 часов в месяц на решение проблем связанных с переводом. Хотя, поддержка на тот момент была всего 2 языка — русский и английский. Т.е. разработчики сами переводили, что не знали — кидали переводчикам, те допереводили, потом вычитывали, правили и т.д.

На какие самые частые ошибки и проблемы мы нарывались:

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

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

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

И это только с двумя языками…

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

Другими словами — мало того, что фирма тратит больше 12000$ в год на оплату проблемы, так и еще продукт теряет 1200/7/22 = 8 человеко/месяцев. Т.е. около одного разработчика в год тратится в этом случае на то, чтобы поддерживать переводы.

Отсюда, можно сделать вполне резонный вывод — разработчики не должны вообще думать о переводах, а просто писать по стандартам, которые говорит сама 1С про локализацию.

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

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

Это тот из не многих случаев, когда должно быть единое хранилище переводов. Переводы должны делаться по API и т.д. Т.е. в данном случае — в любом варианте — для переводов надо единое место хранения. Откуда будут браться конечные варианты приоритетов.

Первая версия продукта. Интеграция с внешними сервисами

Что можно было бы написать за месяц? Можно написать простейший парсер, прямо на самой 1С, который умел бы парсить исходники 1С и вычленять оттуда НСтр (из bsl) и lang тег из xml.

И потом собирать все это в кучу. Но дальше надо думать — что делать с этим всем? Т.е. это надо бы где-то переводить…

Переводить в Excel? Да, наверное, но разве что объемы до 1000 строк и только один проект. А если их десяток тысяч, и десятки обработок и расширений, и это только начало, видь все проекты имеют свойство увеличиваться…

Поэтому, можно использовать внешние сервисы, и сделать выгрузку в CrowdIn и там переводить. Тем более — там есть версии проектов и много всяких других чудес. Но, не забудьте посмотреть на цены, а они тут весьма не низкие:

В реальности — максимальный план не подходит для крупных проектов, типо ERP, УТ11, УНФ.

Есть другой вариант — Smartcat. Он может купить тем, что он бесплатный (в некоем роде), и там большая база фриланса.

Но… Сбор статистики, анализ плейсхолдеров, выгрузка и загрузка данных — отнимают мега много времени.

А если задача стоит — проверять все постоянно, и иметь полноценный CI\CD, т.е. именно deploy, то тогда время это один из очень критических факторов.

Создание системы перевода

В итоге — мы собрали некие критические особенности, которыми должна обладать такая система:

•      Перевод не должен влиять на разработку
•      Разработка делается только на одном языке
•      Визуальная проверка результата переводов интерфейсов и макетов
•      Встраивание в CI\CD контур
•      Интеграция с GIT
•      Максимальная помощь для переводчиков
•      Высокая скорость переводов
•      Не верить программистам 🙂

Функционал, который критически необходим:

•     Переводить нужно конфигурации, обработки, расширения, макеты и т.д.
•     Исходники могут быть в виде xml формата 1С или EDT формат, поддержка OS скриптов, так что не хардкодьте везде bsl
•     Очень важен контроль шаблонов — %1, %Склад%, [Контрагент], %Пользователь …
•     Неограниченное количество языков для добавления в конфигурации и их урезание
•     Быстрое исправление и поиск ошибок перевода в том числе, в старых конфигурациях
•     Версионирование и группы проектов
•     Перевод справки, и/или ее размножение на другие языки

Работа с системой должна быть очень простая, например:

1.     Выгружаем конфигурацию и т.д. в xml, или сразу берем в EDT формате
2.     Удаляем все, что не нужно переводить, там драйвера всякие, классификаторы и т.д.
3.     Загружаем эти данные в переводчик
4.     Выполняем перевод, в том числе при помощи Yandex переводчика или других
5.     Скачиваем переведенные файлы обратно

Но, если есть git то – все это надо уметь делать автоматом, из нужных реп и веток, и туда же в другую ветку пушить уже переводы.

Наше представление реализации контура переводов

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