Как определить объём работ по интеграции перевода в существующее бизнес-приложение
Спланируйте перевод в Вашем бизнес-приложении. До запроса расчёта определите контент, языки, проверку, правила работы с данными, обработку сбоев и приёмочные тесты.
Начните с одной законченной задачи, которую Вашей команде нужно выполнять на другом языке. Затем определите, какое место в этой задаче занимает перевод. Так поставщик программного обеспечения получит более понятную основу для оценки, чем просьба добавить кнопку перевода.
Объём работ должен охватывать текст, людей, данные и результат. В нём также нужно описать, что происходит, если перевод не удался. Используйте шаги ниже, чтобы подготовить такое описание до выбора технического подхода.
Выберите один процесс для первого релиза
Запишите, откуда берётся исходный текст и куда должен попасть утверждённый перевод. Например, сотруднику поддержки может понадобиться прочитать входящее сообщение и подготовить ответ на языке клиента. Это условное требование, а не отчёт о внедрении Vavus.
Перечислите каждый шаг: открыть сообщение, запросить перевод, прочитать исходный текст рядом с результатом, отредактировать ответ и утвердить его к отправке. Решите, запускается ли перевод автоматически или только после того, как сотрудник его выберет.
Сделайте первый релиз небольшим. Один экран и одну понятную бизнес-задачу протестировать проще, чем все текстовые поля приложения.
Определите потребности в контенте и языках
Составьте список полей, которые нужно переводить. Разделите короткие подписи, свободный текст, документы и речь. Для них могут потребоваться разная обработка и разные тесты. Также перечислите поля, которые должны оставаться без изменений, например номера заказов и коды товаров.
Укажите исходные и целевые языки, включая региональные варианты. Зафиксируйте типичную длину текста и ожидаемый ежедневный объём. Спросите, какие языковые пары и форматы ввода поддерживает предлагаемый сервис.
Для коротких текстов может иметь значение контекст. Например, API DeepL для перевода текста поддерживает параметр контекста, который может влиять на перевод, при этом сам контекст не переводится. В его документации также сказано, что отдельные фрагменты текста в одном запросе не используют общий контекст. [1] В описании объёма работ должно быть указано, откуда берётся полезный контекст.
Определите терминологию и проверку человеком
Соберите термины, которые Ваша компания использует часто. Включите предпочтительные переводы, названия продуктов и слова, которые должны оставаться без изменений. Назначьте одного человека, который будет вести этот список.
Некоторые сервисы перевода поддерживают глоссарии. Google Cloud Translation описывает свой глоссарий как пользовательский словарь для единообразной отраслевой терминологии. [2] Проверьте эту функцию для Ваших конкретных языковых пар и выбранного сервиса. Глоссарий не доказывает, что всё сообщение переведено правильно.
Решите, какие результаты должен проверять квалифицированный языковой специалист. Дайте проверяющему доступ к исходному тексту. Предусмотрите чёткий этап утверждения, прежде чем текст для клиентов будет отправлен или опубликован.
Задайте правила для данных и доступа
Опишите, какую информацию обрабатывает процесс. На ранних тестах используйте искусственные примеры. Не копируйте реальные данные клиентов в пробную версию только для того, чтобы проверить, работает ли кнопка.
Спросите, где будет обрабатываться текст, что будет хранить приложение, кто сможет это читать и когда данные будут удалены. Включите в обсуждение журналы и резервные копии. Уточните действующие условия поставщика и средства контроля, доступные в выбранном тарифе.
Индивидуальный интерфейс сам по себе не делает внешний сервис перевода закрытым или автономным. Если Вашему проекту нужна локальная обработка, укажите это требование с самого начала и протестируйте на соответствие ему весь поток данных.
Предусмотрите задержки и ошибки
Запишите ожидаемое время ответа и то, что должны делать сотрудники, если сервис недоступен. Приложение должно показывать понятное состояние, например «ожидание», «готово к проверке» или «ошибка». Сохраняйте исходный текст.
Попросите разработчика отличать временные сбои от ошибок, требующих изменений. Например, DeepL описывает повторные попытки с задержкой при ошибках превышения лимита запросов, тогда как исчерпанная квота требует другой реакции. [3] Повторные запросы не должны приводить к дублированию бизнес-действий, например к повторной отправке одного и того же ответа.
Согласуйте оповещения об использовании и ответственного за поддержку. При сравнении стоимости проектов учитывайте плату за сервис, сопровождение и будущие изменения.
Напишите приёмочные тесты до начала разработки
Выберите показательные примеры для каждой нужной языковой пары. Включите длинные сообщения, необычные символы, незаполненные поля и термины из утверждённого списка. Протестируйте задачу целиком — от исходной записи до сохранённого или отправленного результата.
Задайте критерии, которые люди могут проверить: коды товаров не меняются, неутверждённый перевод нельзя отправить, неудачный запрос виден, а проверяющий может вернуться к исходному тексту. Поручите квалифицированному проверяющему оценить смысл и тон. Фиксируйте дефекты и после изменений повторяйте те же тесты.
Подготовьте понятный запрос на расчёт стоимости
Отправьте описание процесса, примеры полей, языковые пары, ожидаемый объём, правила работы с данными и приёмочные тесты. Отметьте, какие пункты обязательны для запуска, а какие можно перенести в следующий релиз. Попросите изложить допущения и исключения письменно.
Vavus готовит письменное описание объёма работ для индивидуальных проектов. [4] Опишите на странице расчёта стоимости Ваше текущее приложение и задачу, которую хотите улучшить. Предлагаемая интеграция, развёртывание и тестирование должны быть подтверждены в объёме работ Вашего проекта.