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