Как перевести файлы DITA без преобразования в формат XLIFF

Вы ищете способ перевести ваши файлы DITA без постоянной головной боли, связанной с ручным преобразованием в формат XLIFF? Если это так, то вы попали по адресу. DITA (Darwin Information Typing Architecture) уже является золотым стандартом эффективности и повторного использования контента, однако многие технические команды, занимающиеся контентом, по-прежнему застревают в порочном круге: цикле преобразования XLIFF.

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

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

Налог XLIFF на техническую документацию

XLIFF (XML Localization Interchange File Format) — отличный стандарт для многих задач, но для пользователей DITA он часто выступает в роли посредника, который скорее усложняет, чем упрощает процесс. Мы часто называем это «налогом XLIFF»: скрытая плата за время, деньги и ручной труд, необходимые для того, чтобы этот формат заработал. Вот почему этот процесс ручного преобразования может обходиться вашей команде дороже, чем вы думаете.

1. Анализ повторного использования контента: ссылки на источники (Conrefs) и ссылки на ключевые слова (Keyrefs).

Истинная гениальность DITA заключается в ее способности создавать ссылки на контент по самым разным темам. При преобразовании файла DITA в XLIFF эти сложные взаимосвязи часто сглаживаются или полностью нарушаются. В стандартном файле XLIFF ссылка на содержимое (conref) может отображаться просто как статическая текстовая строка.

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

2. Повреждение тегов и ошибки проверки.

Файлы DITA регулируются строгими DTD (определениями типов документов) или XML-схемами. Каждый раз, когда ваш контент перемещается из формата .dita в .xliff и обратно, вы рискуете создать то, что мы называем "супом тегов".

Достаточно одного переводчика, незнакомого со структурой DITA, чтобы случайно удалить обязательный атрибут или неправильно поставить закрывающий тег. Одна-единственная отсутствующая скобка или неправильно расположенный атрибут во время этого обмена данными могут привести к сбою всей вашей сборки DITA-OT. Все мы оказывались в такой ситуации: пятница после обеда, вы пытаетесь выпустить релиз, а вместо этого ваши инженеры службы поддержки просматривают тысячи строк кода в поисках единственной ошибки валидации.

3. Кошмар управления Дельта

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

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

Помимо тегов: важность защиты атрибутов

Одним из наиболее часто упускаемых из виду аспектов в борьбе за преобразование DITA в XLIFF является управление атрибутами XML. DITA в значительной степени опирается на атрибуты для профилирования и фильтрации, такие как продукт, платформа и аудитория. Это инструменты, позволяющие публиковать разные версии руководства из одного и того же источника.

При использовании стандартного рабочего процесса DITA эти атрибуты по умолчанию защищены. В MotaWord наша система распознает, что атрибут продукта — это фрагмент метаданных, который ни в коем случае нельзя переводить. При стандартном преобразовании в формат XLIFF эти атрибуты часто либо удаляются (что нарушает условную публикацию), либо становятся доступны транслятору. Если переводчик увидит pro_version и переведёт его на испанский как version_profesional, ваша логика условной обработки перестанет работать.

Почему функция «Перевести = Нет» — это спасение

Атрибут translate="no" — это важный инструмент для технических писателей, которым необходимо обеспечивать единообразие фрагментов кода, инструкций командной строки или названий конкретных брендов во всех языках программирования. Встроенный парсер DITA учитывает это свойство на уровне движка. При ручном преобразовании в формат XLIFF эти инструкции часто игнорируются фильтрами, используемыми для создания файла XLIFF, что приводит к дорогостоящим и утомительным циклам постобработки для исправления избыточно переведенного контента.

Контекстный разрыв: почему переводчики испытывают трудности с XLIFF

Перевод – это не просто обмен словами: это понимание контекста. При преобразовании темы DITA в плоский файл XLIFF транслятор часто видит список отдельных строк. Они теряют карту, которая придает проекту структуру. Они не могут понять, что конкретное название относится к определенному разделу в рамках более крупной задачи.

Используя встроенный перевод DITA, переводчик работает в системе, которая действительно понимает иерархию DITA. Это дает ряд преимуществ для качества вашей документации:

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

Лучший способ: перевод DITA с помощью MotaWord

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

Сравнение рабочих процессов

Ручной рабочий процесс XLIFF

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

Встроенный рабочий процесс DITA в MotaWord

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

Загрузите ваши исходные файлы .dita и .ditamap.

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

Автоматизация вместо ручного сравнения.

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

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

Экономические аспекты подготовки документации к строительству

Истинные скрытые издержки конвертации в формат XLIFF проявляются на заключительном этапе публикации. При ручном рабочем процессе получение переведенных файлов — это лишь половина дела. Вам все равно придется заново импортировать все в вашу систему управления компонентным контентом (CCMS), запустить тестовую сборку с помощью DITA Open Toolkit и отладить неизбежные ошибки XML.

Этап контроля качества локализации может занять у автора несколько дней или даже недель. Встроенная поддержка DITA гарантирует, что загруженные вами файлы будут готовы к использованию. Поскольку конструкция никогда не разбиралась для установки в контейнер XLIFF, её не нужно восстанавливать. Вы можете перейти от завершенного перевода к опубликованному PDF- или HTML-сайту всего за несколько кликов.

Часто Задаваемые Вопросы

1. Как перевести файлы DITA, не нарушая работу conrefs?

Встроенные платформы для перевода DITA, такие как MotaWord, обрабатывают файлы в их исходной XML-структуре. Благодаря тому, что преобразование в формат XLIFF не требуется, система сохраняет указатели на ссылки на контент (conrefs) и ссылки на ключи (keyrefs). Это гарантирует корректную обработку многократно используемых объектов без их жесткого кодирования в переведенном тексте.

2. Какой оптимальный рабочий процесс DITA-перевода для небольших команд?

Наиболее эффективным рабочим процессом для небольших команд является подход Direct to DITA. Вместо того чтобы вкладывать средства в дорогостоящее промежуточное программное обеспечение или тратить часы на ручной экспорт в формат XLIFF, небольшим командам следует использовать платформу, которая принимает файлы .dita и .ditamap напрямую. Это снижает технические издержки и устраняет необходимость в выделенном инженере по локализации.

3. Поддерживает ли MotaWord специализированные DTD-файлы DITA?

Да. Поскольку DITA допускает специализацию (создание пользовательских типов элементов), наш собственный парсер разработан таким образом, чтобы учитывать базовую XML-схему. Ваши пользовательские теги и атрибуты защищены и не учитываются при подсчете слов, если они не содержат переводимого контента.

4. DITA против XLIFF для перевода: что лучше?

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

5. Могу ли я использовать встроенный перевод DITA с моей существующей системой управления контентом (CCMS)?

Совершенно верно. Большинство систем управления контентом, таких как IXIASOFT, Heretto или Oxygen Content Fusion, позволяют экспортировать необработанные пакеты DITA. Вы можете загружать эти пакеты непосредственно в MotaWord, а затем повторно загружать переведенные результаты обратно в вашу систему управления контентом (CCMS) без каких-либо промежуточных этапов преобразования.

6. Как снизить затраты на перевод DITA с помощью памяти переводов?

Загрузив весь ваш Ditamap на собственную платформу, система использует память переводов (Translation Memory™) для точного определения совпадений с вашими предыдущими проектами. Оплата взимается только за новый или измененный текст, что значительно снижает затраты на долгосрочные проекты по созданию технической документации.

7. Как обрабатывать локализацию изображений и атрибуты href в DITA?

При загрузке проекта DITA в исходном формате система распознает теги изображений и ссылок. Вы можете указать, хотите ли вы обновить пути к этим изображениям, указав локальные папки (например, изменить путь с /images/en/ на /images/es/) или оставить их в неизменном виде. Это гарантирует, что ваши ссылки никогда не будут не работать в переведенной версии.

Прекратите конвертацию и начните синхронизацию с MotaWord.

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

Ваши профессиональные навыки должны быть направлены на создание качественного контента, а не на управление экспортом файлов. Готовы узнать, сколько времени и усилий вы сможете сэкономить на своем следующем проекте? Вы можете получить мгновенную оценку стоимости на MotaWord, загрузив свои файлы .dita уже сегодня.

ОЙТУН ТЕЗ - Главный технический директор (CTO) в MotaWord

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