Локализацията на имейл кампании в няколко региона е била бавна, повтаряща се задача с много ръчни стъпки.Многобройните рецензенти са работили върху отделни версии, едно и също съдържание е било пренаписано няколко пъти, а управлението на последователността в до 13 езика изисква значителна координация. Вместо да въвеждам нови платформи или външни инструменти, проведох вътрешен експеримент: Could localisation be automated using only the tools already available inside a standard enterprise Microsoft environment? Прототипът се основава главно на SharePoint, Power Automate и Teams, като един допълнителен компонент - GPT-4.1 mini, достъпен чрез Azure OpenAI - се използва стриктно за контролирана стъпка QA. За да поддържате този работен поток, създадох структурирана библиотека на SharePoint, наречена с папки, представляващи всеки етап от жизнения цикъл на локализацията: Email translations Folder Purpose 01_Incoming_EN Source English files; Power Automate trigger 02_AI_Drafts Auto-translated drafts from Copilot + GPT 03_In_Review Files waiting for regional review 04_Approved Final approved translations 99_Archive Archived or rejected versions 01_Incoming_EN Източник английски файлове; Power Automate trigger 02_AI_Drafts Автоматично преведени проекти от Copilot + GPT 03_In_Review Файлове в очакване на регионален преглед 04_Approved Одобрени окончателни преводи 99_Archive Архивирани или отхвърлени версии Файловете се преместват автоматично между тези папки в зависимост от тяхното състояние. Целта не е била да се изгради перфектна система за локализация, а само да се види докъде може да стигне прототип с помощта на вътрешни инструменти. В крайна сметка той премахна голяма част от повтарящата се работа и създаде много по-структуриран процес на преразглеждане. The Problem: Process, Not Language Проблемът: процес, а не език Ръчното локализиране на съдържанието в много региони създава няколко последователни проблема: Всеки регион е редактирал свой собствен файл, така че няколко различни версии съществуват едновременно. Когато изходният текст се промени, не всички региони актуализираха своята версия, което доведе до несъответстващо съдържание. Файловете са запазени на различни места и с различни имена, което прави трудно да се идентифицира коя версия е актуална. Прегледите отнеха време, особено когато екипите бяха в различни часови зони. Повтарянето на едни и същи редакции в много файлове увеличава риска от малки грешки Attempt 1: Copilot-Only Translation Опит 1: Превод само с копилот Въпреки че Copilot сега работи на по-нови модели от серията GPT-5, този прототип е построен върху по-ранна версия и поведението на превода отразява тези предишни възможности. Първата версия на работния поток е проста: Файлът е качен на 01_Incoming_EN. Автоматичното захранване се активира автоматично. Copilot генерира превод за всеки регион. Тъй като тригерите на SharePoint могат да се задействат, преди файлът да завърши качването, потокът включва проверка за завършване на размера на файла (изчакайте, докато размерът > 0 преди да продължите). Основният проблем обаче бързо се изясни: преводите на Copilot не бяха достатъчно надеждни за локализация от край до край. Общите въпроси включват: CTAs преведени прекалено буквално Тон и стил, вариращи между езиците Местата, които ще бъдат премахнати или променени Форматиране на различия в списъци, разстояния и структура Това прави Copilot полезен само за генериране на първи проект. Необходим е втори контрол на качеството. Attempt 2: Adding GPT-4.1 Mini for QA Опит 2: Добавяне на GPT-4.1 Mini за QA Следващата версия добави стъпка за преглед: Copilot → първоначален превод GPT-4.1 mini (Azure) → QA и проверка на последователността GPT-4.1 mini е подобрен: Тонът на последователността Място за съхранение Форматиране на стабилността Съвпадение със значението на източника Помощите се нуждаят от настройка, за да се избегне ненужно пренаписване, но след настройки, изходите станаха достатъчно последователни, за да се използват в работния поток. Engineering Work: Making the Workflow Reliable Инженерна работа: Направете работния процес надежден Архитектурата е проста, но няколко проблема се появяват по време на реална употреба и са необходими поправки. Platform behaviour: Причинителите на SharePoint не винаги започват веднага, така че бяха добавени проверки и повторения. Насочването на екипите се провали, когато каналите бяха преименувани, така че картографирането трябваше да бъде актуализирано. Design issues: Някои паралелни стъпки се провалят в първия ход, така че се въвежда логиката на ретри. JSON отговорите понякога липсват очакваните полета, така че валидирането е добавено. Имената на файловете са несъвместими, така че е дефиниран един-единствен формат за наименование. След тези корекции работният поток работи надеждно при нормални условия. Final Prototype Architecture Окончателна архитектура на прототипите По-долу е представена пълната работна структура на системата. 1. SharePoint Upload & Intake Процесът започва, когато файлът е качен в Email translations / 01_Incoming_EN След това Power Automate: Проверете дали файлът е напълно качен (zero-byte guard) Възстановяване на метаданни Извлечен текст Определяне на целеви региони SharePoint действа като единствен източник на истина за всички етапи. 2. Power Automate Orchestration Power Automate контролира всяка част от работния поток: Прочетете английския източник Пилотиране на проект за превод изпращане на проекта на GPT-4.1 mini за QA Създаване на клон по регион Изпращане на имейли до местни екипи Публикуване на одобрителни карти на екипи Записване на “одобри” или “запитване за промени” Съхранение на одобрени файлове в 04_Approved Запазване на актуализирани версии в 03_In_Review Архивиране на старите версии в 99_Archive Всички маршрутизации, пренасочвания и държавни преходи се обработват от Power Automate. 3. Copilot Translation Pass Copilot превежда извлеченото съдържание и запазва по-голямата част от структурата на имейла - списъци, разстояния и форматиране - по-добре от GPT. 4. GPT-4.1 Mini QA Pass GPT-4.1 мини проверява: Тонът на последователността Значение на изравняването Форматиране на стабилността Интегритет на мястото Това създаде по-надежден проект за регионален преглед. 5. Regional Review (Email + Teams) За всеки регион, Power Automate: Изпратете преведения файл по имейл Публикуване на адаптивна карта на Teams с промени в одобрението / искането Ако са изпратени промени, актуализираният файл се връща на След това отново влиза в работния поток. 03_In_Review 6. Final Storage Одобрените преводи се съхраняват в Използване на последователен формат на наименование. 04_Approved Отхвърлени или остарели версии са преместени в Това гарантира цялостен и чист одит. 99_Archive. Results Резултати След тестване на прототипа в реални работни потоци: Времето за превод намалява от дни на минути По-малко версии на конфликти Минимално ръчно пренаписване По-бързи цикли на преглед всички данни, обработвани в средата на Microsoft Това не замени специалните системи за локализация, но премахна значително количество повтаряща се ръчна работа. Limitations Ограниченията някои езици все още се нуждаят от стилистични корекции Одобренията на екипите зависеха от времето за реакция на рецензентите Потокът се нуждае от логика за преходни грешки Консистенция на тона варира върху дълги или сложни имейли Те са подходящи за прототип. Next Step: Terminology Memory Следваща статия: Терминологична памет Следващото планирано подобрение е векторна терминологична библиотека, съдържаща: Глосарий Име на продукта Ограничени термини Регионално специфични фрази Синонимни групи Тонни правила И двата модела ще използват тази библиотека преди да произвеждат или проверяват преводи. Final Thoughts Заключителни мисли Този проект беше вътрешен експеримент, за да се разбере колко от работния поток за локализация може да бъде автоматизиран, като се използват само стандартни инструменти на Microsoft и един LLM, хостван от Azure. Това не е пълна локализационна платформа, но показва какво може да се постигне с прост, добре структуриран работен поток в съществуващата корпоративна купчина.
