Lokalizing kampeni za barua pepe katika mikoa kadhaa zamani ilikuwa kazi ya polepole, ya kurudia na hatua nyingi za mwongozo. Watafiti kadhaa walifanya kazi juu ya matoleo tofauti, maudhui yenyewe yameandikwa tena mara kadhaa, na kusimamia ufuatiliaji katika lugha 13 zinahitaji ushirikiano mkubwa. Badala ya kuanzisha majukwaa mapya au zana za nje, nilifanya majaribio ya ndani: Could localisation be automated using only the tools already available inside a standard enterprise Microsoft environment? Prototype ilitegemea hasa SharePoint, Power Automate, na Teams, na kipengele kingine kimoja - GPT-4.1 mini upatikanaji kupitia Azure OpenAI - kutumika kikamilifu kwa hatua ya QA iliyoendeshwa. Ili kusaidia mchakato huu wa kazi, niliunda maktaba iliyoundwa ya SharePoint inayoitwa na folda ambazo zinawakilisha kila hatua ya mzunguko wa maisha wa eneo: 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 Chanzo Kiingereza faili; Power Automate trigger 02_AI_Drafts Maandalizi ya moja kwa moja kutoka Copilot + GPT 03_In_Review Files kusubiri kwa ajili ya ukaguzi wa kikanda 04_Approved Tafsiri ya mwisho iliyoidhinishwa 99_Archive Toleo la kuhifadhiwa au la kukataliwa Faili huhamia moja kwa moja kati ya folda hizi kulingana na hali yao. Lengo lilikuwa si kujenga mfumo kamili wa eneo - tu kuona kiasi gani prototype inaweza kwenda kwa kutumia zana za ndani. Hatimaye kuondoa sehemu kubwa ya kazi ya kurudia na kuunda mchakato wa ukaguzi uliojengwa zaidi. The Problem: Process, Not Language Matatizo ya lugha, sio mchakato Upatikanaji wa maudhui kwa manually katika mikoa mingi ulisababisha matatizo kadhaa ya utaratibu: Kila mkoa alizindua faili yake mwenyewe, hivyo matoleo kadhaa tofauti yalikuwa yamewekwa wakati huo huo. Wakati maandishi ya chanzo yalibadilika, si mikoa yote iliboresha toleo lake, ambayo ilisababisha maudhui yasiyofaa. Faili zilihifadhiwa katika maeneo tofauti na na majina tofauti, na kufanya vigumu kutambua ambayo toleo lilikuwa la sasa. Tathmini ilichukua muda, hasa wakati timu zilikuwa katika maeneo tofauti ya wakati. Utaratibu wa marekebisho sawa katika faili nyingi unaongeza hatari ya makosa madogo Attempt 1: Copilot-Only Translation Majaribio 1: Tafsiri ya Copilot tu Ingawa Copilot sasa inafanya kazi kwenye mifano mapya ya GPT-5-series, prototype hii iliundwa juu ya toleo la awali, na tabia ya tafsiri ilionyesha uwezo huo wa awali. Toleo la kwanza la mchakato wa kazi ilikuwa rahisi: Faili moja ilipelekwa kwenye 01_Incoming_EN. Ndoa ya Usalama Hatari ya Automatic. Copilot ilizalisha tafsiri kwa kila mkoa. Kwa sababu triggers za SharePoint zinaweza kuchomwa kabla ya faili kuishia kupakia, mtiririko ulikuwa na udhibiti wa kukamilika kwa ukubwa wa faili (asubiri mpaka ukubwa > 0 kabla ya kuendelea). Hata hivyo, tatizo kuu lilionekana haraka: tafsiri za Copilot hazikuwa za kuaminika kutosha kwa uwanja wa mwisho. Maswali ya kawaida ni pamoja na: CTAs kutafsiriwa kwa kifupi sana Tone na mtindo tofauti kati ya lugha Watumiaji wanaoondolewa au kubadilishwa kubadilisha tofauti katika orodha, nafasi, na muundo Hii ilifanya Copilot kuwa muhimu tu kwa kuzalisha draft ya kwanza. Utafiti wa pili wa ubora ulikuwa unahitajika. Attempt 2: Adding GPT-4.1 Mini for QA Majaribio 2: Kuongeza GPT-4.1 Mini kwa QA Toleo la pili liliongeza hatua ya ukaguzi: Copilot → initial translation GPT-4.1 mini (Azure) → QA na udhibiti wa utaratibu GPT-4.1 mini ya kuboresha: Ufuatiliaji wa Tone Mahali pa kuhifadhi Utengenezaji wa utulivu Kuunganisha kwa maana ya chanzo Maombi yalihitaji tuning ili kuepuka kuandika upya usiofaa, lakini baada ya marekebisho, outputs ilibadilika kutosha kutumika katika mtiririko wa kazi. Engineering Work: Making the Workflow Reliable Kazi ya Uhandisi: Kufanya mchakato wa kazi wa kuaminika Usanifu ulikuwa rahisi, lakini matatizo kadhaa yalitokea wakati wa matumizi halisi na yanahitaji ufumbuzi. Platform behaviour: SharePoint triggers si daima kuanza mara moja, hivyo checks na retries iliongezwa. Utaratibu wa timu haukuwa na ufanisi wakati vituo vilikuwa na majina, kwa hiyo uhariri ulikuwa unahitajika kuboreshwa. Design issues: Baadhi ya hatua za parallel zimeshindwa katika kozi ya kwanza, hivyo mantiki ya retry ilizinduliwa. Majibu ya JSON wakati mwingine yalikuwa na masharti yaliyotarajiwa, hivyo uhakiki uliongezwa. Majina ya faili yalikuwa mabaya, hivyo muundo wa jina moja ulifanywa. After these adjustments, the workflow ran reliably under normal conditions. Final Prototype Architecture Mfumo wa mwisho wa prototype Hapa chini ni muundo wa kazi kamili wa mfumo. 1. SharePoint Upload & Intake mchakato ulianza wakati faili ilipelekwa kwenye Email translations / 01_Incoming_EN Uwezekano wa Power Automate: kuangalia kama faili ilikuwa imechapishwa kikamilifu (zero-byte guard) Ufafanuzi wa metadata Mchapishaji wa maandishi Maeneo ya lengo yaliyotambuliwa SharePoint alifanya kazi kama chanzo kimoja cha ukweli kwa hatua zote. 2. Power Automate Orchestration Power Automate iliongoza kila sehemu ya mchakato wa kazi: Kusoma chanzo cha Kiingereza Kuomba Copilot kwa mradi wa tafsiri kuwasilisha mradi kwa GPT-4.1 mini kwa QA Kuunda tawi kwa mikoa Kutuma barua pepe kwa timu za mitaa Kuwasilisha kadi za kukubalika kwa timu Kupata “kuidhinisha” au “kutaka mabadiliko” Kuokoa faili zilizopitishwa katika 04_Approved Kuokoa toleo la hivi karibuni katika 03_In_Review kuhifadhi matoleo ya zamani katika 99_Archive Routing yote, retries, na mabadiliko ya hali walikuwa kushughulikiwa na Power Automate. 3. Copilot Translation Pass Copilot kutafsiri maudhui yaliyotolewa na kuhifadhi utaratibu wa barua pepe - orodha, nafasi, na muundo - bora kuliko GPT peke yake. 4. GPT-4.1 Mini QA Pass GPT-4.1 mini ya kuangalia: Ufuatiliaji wa Tone Umuhimu wa Alignment Utengenezaji wa utulivu Maisha ya utulivu Hii ilizalisha mradi wa kuaminika zaidi wa ukaguzi wa kikanda. 5. Regional Review (Email + Teams) Kwa kila mkoa, Power Automate: kuwasilisha faili iliyotafsiriwa kwa barua pepe imewasilishwa kadi ya Adaptive ya Teams na Mabadiliko ya Kufadhili / Kuomba Ikiwa mabadiliko yamewasilishwa, faili iliyosajiliwa ilirudi kwenye na kurejea kwenye mchakato wa kazi. 03_In_Review 6. Final Storage Tafsiri zilizoidhinishwa zimehifadhiwa katika kutumia muundo wa majina ya ufanisi. 04_Approved Matoleo yaliyopunguzwa au yaliyopangwa yamehamishwa kwenye Hii inahakikisha njia ya ukaguzi kamili na safi. 99_Archive. Results Matokeo ya Baada ya kujaribu prototype katika kazi halisi ya kazi: Muda wa kutafsiri ulipungua kutoka siku hadi dakika Baadhi ya mapigano ya lugha Utaratibu mdogo wa kuandika upya Utafiti wa haraka wa mzunguko Takwimu zote zilizochukuliwa ndani ya mazingira ya Microsoft Hii haina kubadilisha mifumo maalum ya mahali, lakini imeondoa kiasi kikubwa cha kazi ya mara kwa mara ya manually. Limitations Mabadiliko ya baadhi ya lugha bado zinahitaji marekebisho ya stylistic Timu za kukubalika kulingana na wakati wa majibu ya mtazamaji Mzunguko unahitaji mantiki ya retry kwa makosa ya mpito Ufuatiliaji wa sauti ulibadilika kwenye barua pepe ndefu au ngumu Hizi zilikuwa sahihi kwa ajili ya prototype. Next Step: Terminology Memory Hatua inayofuata: kumbukumbu ya terminology Mabadiliko ya baadaye yaliyopangwa ni maktaba ya terminology ya vektor ambayo inajumuisha: Glosari ya Majina ya bidhaa Mabadiliko ya maneno Ufafanuzi wa eneo maalum Makundi ya sinonim Kanuni ya Tone Modeli zote mbili zinatumia maktaba hii kabla ya kuzalisha au kuangalia tafsiri. Final Thoughts mawazo ya mwisho Mradi huu ulikuwa jaribio la ndani la kuelewa kiasi gani cha mchakato wa kazi wa mahali pengine inaweza kuwa automated kwa kutumia zana za kawaida za Microsoft na LLM moja iliyoshikiliwa na Azure. Sio jukwaa kamili la mahali - lakini inaonyesha kile kinachowezekana na mtiririko wa kazi rahisi, uliojengwa vizuri ndani ya mfuko wa kampuni iliyopo.
