Как да определите обхвата на интеграция на превод в съществуващо бизнес приложение
Планирайте превода във Вашето бизнес приложение. Определете съдържанието, езиците, прегледа, правилата за данните, обработката на грешки и тестовете за приемане, преди да поискате оферта.
Започнете с една цялостна задача, която екипът Ви трябва да изпълнява на друг език. След това определете как преводът се вписва в тази задача. Така доставчикът на софтуер получава по-ясна основа за оценка, отколкото при молба просто да се добави бутон за превод.
Обхватът трябва да покрива текста, хората, данните и резултата. Трябва да обяснява и какво се случва, когато преводът не успее. Използвайте стъпките по-долу, за да подготвите този обхват, преди да изберете технически подход.
Изберете един работен процес за първата версия
Запишете откъде идва изходният текст и къде трябва да отиде одобреният превод. Например служител от поддръжката може да трябва да прочете входящо съобщение и да подготви отговор на езика на клиента. Това е илюстративно изискване, а не отчет за внедряване на Vavus.
Избройте всяка стъпка: отваряне на съобщението, заявка за превод, четене на изходния текст до резултата, редактиране на отговора и одобряването му за изпращане. Решете дали преводът започва автоматично, или само след като служител го избере.
Дръжте първата версия малка. Един екран и една ясна бизнес задача се тестват по-лесно от всички текстови полета в едно приложение.
Определете нуждите от съдържание и езици
Направете списък на полетата, които трябва да се превеждат. Разграничете кратките етикети, свободния текст, документите и речта. Те може да изискват различна обработка и различни тестове. Избройте и полетата, които трябва да останат непроменени, като номера на поръчки и продуктови кодове.
Посочете изходните и целевите езици, включително регионалните варианти, ако има такива. Запишете обичайната дължина на текста и очаквания дневен обем. Попитайте кои езикови комбинации и входни формати поддържа предложената услуга.
При кратки текстове контекстът може да е важен. Например текстовият API на DeepL поддържа параметър за контекст, който може да повлияе на превода, без самият контекст да бъде преведен. В документацията му се посочва също, че отделните текстови елементи в една заявка не споделят контекст. [1] Във Вашия обхват трябва да е посочено откъде идва полезният контекст.
Определете терминологията и човешкия преглед
Съберете термините, които Вашата фирма използва често. Включете предпочитаните преводи, имената на продукти и думите, които трябва да останат непроменени. Определете един човек, който да поддържа този списък.
Някои услуги за превод поддържат речници на термините. Google Cloud Translation описва своя речник като персонализиран речник за последователна специализирана терминология. [2] Проверете функцията за Вашите конкретни езикови двойки и избраната услуга. Речникът не доказва, че цялото съобщение е вярно.
Решете кои резултати изискват квалифициран езиков рецензент. Дайте на рецензента достъп до оригиналния текст. Въведете ясна стъпка за одобрение, преди текстове за клиенти да бъдат изпратени или публикувани.
Задайте правила за данните и достъпа
Опишете каква информация обработва работният процес. Използвайте изкуствени примери в ранните тестове. Не копирайте реални клиентски записи в тестова среда само за да видите дали някой бутон работи.
Попитайте къде ще се обработва текстът, какво ще съхранява приложението, кой може да го чете и кога ще бъде изтрит. Включете в този разговор и журналите, и резервните копия. Потвърдете актуалните условия на доставчика и наличните средства за контрол в избрания план.
Интерфейсът по поръчка сам по себе си не прави външна услуга за превод поверителна или офлайн. Ако проектът Ви изисква локална обработка, посочете това изискване от самото начало и тествайте целия поток от данни спрямо него.
Планирайте закъснения и грешки
Запишете очакваното време за отговор и какво трябва да направи персоналът, ако услугата не е достъпна. Приложението трябва да показва ясно състояние, например „изчакване“, „готово за преглед“ или „неуспешно“. Запазвайте оригиналния текст.
Помолете разработчика да разграничава временните откази от грешките, които изискват промяна. DeepL например документира повторни опити със закъснение при грешки заради ограничение на честотата на заявките, докато изчерпаната квота изисква друга реакция. [3] Повторните заявки не бива да създават дублирани бизнес действия, като например изпращане на един и същ отговор два пъти.
Договорете известията за използване и кой отговаря за поддръжката. Когато сравнявате разходите по проекта, включете таксите за услугата, поддръжката и бъдещите промени.
Напишете тестовете за приемане преди разработката
Изберете представителни примери за всяка нужна езикова двойка. Включете дълги съобщения, необичайни символи, липсващи полета и термини от одобрения Ви списък. Тествайте цялата задача – от изходния запис до запазения или изпратения резултат.
Задайте критерии за успех, които хората могат да проверят: продуктовите кодове остават непроменени, неодобрен превод не може да бъде изпратен, неуспешната заявка е видима и рецензентът може да се върне към изходния текст. Нека квалифициран рецензент оцени смисъла и тона. Записвайте дефектите и повтаряйте същите тестове след промени.
Подгответе ясна заявка за оферта
Изпратете работния процес, примерни полета, езиковите двойки, очаквания обем, правилата за данните и тестовете за приемане. Отбележете всеки елемент като задължителен за старта или подходящ за по-късна версия. Поискайте допусканията и изключенията в писмен вид.
Vavus предлага писмено определяне на обхвата за проекти по поръчка. [4] Използвайте страницата за оферта, за да опишете съществуващото си приложение и задачата, която искате да подобрите. Предложените интеграция, внедряване и тестване трябва да бъдат потвърдени в обхвата на Вашия проект.