Представим ситуацию: у вас есть продукт, в котором ваши клиенты создают собственный контент. Этот контент нужно распространить на аудиторию, говорящую на разных языках. Как помочь клиенту сделать процесс локализации его контента более комфортным?
В десктопных продуктах iSpring клиенты создают контент для корпоративного обучения. Например, крупной компании нужно провести тестирование сотрудников по всему миру. Одни говорят на русском, другие — на китайском, третьи — на испанском. Раньше контент переводили с помощью человека или в программе-переводчике. В одном случае нужно выдавать дополнительную лицензию на продукт, в другом — была вероятность кривого перевода и форматирования. Процесс был сложный.
Чтобы локализация происходила проще, мы сделали фичу, которая собирает исходный текст в формат XLIFF, отправляет его в Crowdin и потом передаёт клиенту готовый локализованный текст. Это быстро, почти автоматически и тестируется! Про особенности тестирования сборки текстов в XLIFF-документ и расскажем в статье.
Почему именно XLIFF
Что за формат XLIFF и с чем его «едят», хорошо описано на Википедии
Возникла идея: можно выгрузить из файла документ, в котором будет содержаться не только текст, но и всё необходимое форматирование. После перевода на нужный язык документ будет импортироваться обратно в исходный файл. И вуаля: получим переведённый текст с корректным форматированием.
Выбор пал на формат XLIFF (XML Localization Interchange File Format), потому что у него есть:
Набор платных и бесплатных редакторов под desktop и web.
Возможность поддержки форматирования любых кастомных элементов внутри текста.
Для пользователя магия экспорта и импорта происходит в 9 кликов:
Нажать кнопку «Перевод».
Выбрать кнопку экспорта.
Выбрать язык исходного текста.
Ввести имя файла.
Сохранить XLIFF-документ.
После перевода в стороннем сервисе, таком как CrowdIn, Smartcat, Localazy:
Нажать кнопку «Перевод».
Нажать кнопку импорта.
Выбрать файл.
Загрузить переводы.
Что учитывать при тестировании XLIFF
В целом процесс тестирования XLIFF ничем не отличается от обычного тестирования. Но есть несколько особенностей, которые нужно держать в голове.
Первое и самое главное — структура документа
Бывает, что между экспортом перевода и импортом перевода исходный документ может измениться: например, добавили в тест новый вопрос или текст ответа. Структура документа XLIFF должна быть устойчива к таким изменениям: нужно следить, чтобы импорт перевода в измененный документ проходил без ошибок.
Второе. Unit-тесты необходимы
За качество продукта отвечают не только тестировщики, но и разработчики. В частности, если разработчики покрывают unit-тестами большую часть кода, качество продукта становится выше. Поэтому программисты использовали эту практику и с нашей фичей.
Внутри документа XLIFF была большая структура с тегами и атрибутами — если бы тестировщики проверяли это сами, получилось бы накладно и долго. Поэтому бОльшую часть проверки структуры документов покрыли unit-тестами.
Также написали небольшой скрипт, который брал экспортированный XLIFF, менял регистр, добавлял теги <trans_unit> — это показывало, что документ переведён. Такой скрипт помогает проверять регрессию импорта текстов.
Третье. Теги в документе XLIFF
Есть теги стандартные (target-language="en", <target></target>) и обязательные, без которых XLIFF — не XLIFF. Например, <xliff>, <file>, <body> и так далее.
Некоторые сервисы перевода отображают все теги полностью, другие — вставляют красивые ромбики. С одной стороны хорошо, что не отвлекаешься на теги и сосредоточен на переводе текста. Но всё-таки при тестировании важно проверять, все ли теги подтянулись в сервис — или какие-то скрылись, забылись, потерялись.
<g clone="yes" ctype="x-is-par" id="g1" ispring:start-data="data1"><g clone="yes" ctype="x-is-span" id="span1" ispring:start-data="data2">Событие 3</g></g></g>
XLIFF позволяет внедрять кастомные атрибуты: например, к какому вопросу и ответу в продукте отнести тот или иной текст. Но не все сервисы по переводам их поддерживают.
Поэтому проверяйте, не удалил ли сервис кастомные атрибуты, которые вы заложили в XLIFF. Бывает, что при импорте переведенного текста выгруженный файл не будет поддерживаться вашим продуктом.
Например, до загрузки в сервис:
<file datatype="x-is-Quiz"
ispring:id="quiz_mlup862t69wi-95mjo8sai7jg"
original="Quiz"
source-language="es-SV"
xml:space="preserve">
</file>После выгрузки из сервиса:
<file datatype="x-is-Quiz"
original="Quiz"
source-language="en"
target-language="en-US">
</file>Ещё один важный момент: если переводить текст в самом документе, ничего не выйдет. Будет не хватать основных тегов: target-language="en", <target></target>
Подробнее про теги и атрибуты можно почитать в документации.
Четвертое. Проверка форматирования
В тексте документа может быть простое или продвинутое форматирование. Поэтому при импорте текста в документ нужно визуально проверить, что всё форматирование сохранилось и никакие атрибуты и теги не потерялись.
Простые встроенные средства форматирования:
Продвинутые средства форматирования:
Пятое. Устранение дублирования текста
В документах встречаются целые разделы одинакового текста: например, одинаковые предложения в «обратной связи» при ответе на вопрос. Но в сервис переводов такие тексты должны попасть только один раз: переводчик берёт оплату за строки текста, и ему не важно, одинаковый текст или нет. Мы распознаём одинаковые тексты, не дублируем их при переводе и экономим деньги пользователя.
Шестое. Применение перевода только к экспортированному тексту
При отгрузке текста нужно присваивать уникальный id каждому разделу и документу. Это позволяет каждой части перевода интегрироваться только в тот раздел, откуда она была извлечена.
Тестирование XLIFF: 6 нюансов
XLIFF помогает быстро удобно решать вопрос с переводом сложных по форматированию документов на иностранные языки. Но есть несколько нюансов, о которых нужно помнить, работая с этой фичей:
Следить за структурой документа: чтобы переведённые части текста импортировались без проблем, даже если в документ добавили новый слайд или раздел.
Покрывать структуру документов автотестами, чтобы не приходилось долго и мучительно проверять их вручную.
Следить за тегами и кастомными атрибутами: некоторые сервисы переводов их «выпиливают», из-за чего продукт может не поддерживать выгруженный файл.
Проверять форматирование документа после импорта глазами: что все атрибуты и теги подтянулись.
Предусмотреть фичу, которая будет отслеживать дублирование текста и удалять одинаковые куски: это сэкономит деньги и время при переводе.
Присваивать уникальный id разделам и документу целиком, чтобы перевод интегрировался куда нужно.