Localising email campaigns across multiple regions used to be a slow, repetitive task with many manual steps. Multiple reviewers worked on separate versions, the same content was rewritten several times, and managing consistency across up to 13 languages required significant coordination. Instead of introducing new platforms or external tools, I ran an internal experiment:Could localisation be automated using only the tools already available inside a standard enterprise Microsoft environment? Could localisation be automated using only the tools already available inside a standard enterprise Microsoft environment? The prototype relied primarily on SharePoint, Power Automate, and Teams, with one additional component - GPT-4.1 mini accessed through Azure OpenAI - used strictly for a controlled QA step. This allowed the process to benefit from LLM-based reasoning while keeping all data inside the same enterprise environment. To support this workflow, I set up a structured SharePoint library called Email translations with folders representing each stage of the localisation lifecycle: 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 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 Folder Purpose Folder Folder Purpose Purpose 01_Incoming_EN Source English files; Power Automate trigger 01_Incoming_EN 01_Incoming_EN 01_Incoming_EN Source English files; Power Automate trigger Source English files; Power Automate trigger 02_AI_Drafts Auto-translated drafts from Copilot + GPT 02_AI_Drafts 02_AI_Drafts 02_AI_Drafts Auto-translated drafts from Copilot + GPT Auto-translated drafts from Copilot + GPT 03_In_Review Files waiting for regional review 03_In_Review 03_In_Review 03_In_Review Files waiting for regional review Files waiting for regional review 04_Approved Final approved translations 04_Approved 04_Approved 04_Approved Final approved translations Final approved translations 99_Archive Archived or rejected versions 99_Archive 99_Archive 99_Archive Archived or rejected versions Archived or rejected versions Files moved automatically between these folders depending on their state. The goal was not to build a perfect localisation system - only to see how far a prototype could go using internal tools. It ended up removing a large portion of repetitive work and created a far more structured review process. The Problem: Process, Not Language The Problem: Process, Not Language Localising content manually across many regions created several consistent issues: Every region edited its own file, so multiple different versions existed at the same time. When the source text changed, not all regions updated their version, which led to mismatched content. Files were saved in different places and with different names, making it difficult to identify which version was current. Reviews took time, especially when teams were in different time zones. Repeating the same edits across many files increased the risk of small mistakes Every region edited its own file, so multiple different versions existed at the same time. When the source text changed, not all regions updated their version, which led to mismatched content. Files were saved in different places and with different names, making it difficult to identify which version was current. Reviews took time, especially when teams were in different time zones. Repeating the same edits across many files increased the risk of small mistakes Attempt 1: Copilot-Only Translation Attempt 1: Copilot-Only Translation Although Copilot now runs on newer GPT-5–series models, this prototype was built on an earlier version, and the translation behaviour reflected those earlier capabilities. The first version of the workflow was simple: A file was uploaded to 01_Incoming_EN. Power Automate triggered automatically. Copilot generated a translation for each region. A file was uploaded to 01_Incoming_EN. Power Automate triggered automatically. Copilot generated a translation for each region. Because SharePoint triggers can fire before a file finishes uploading, the flow included a file-size completion check (wait until size > 0 before continuing). However, the main problem became clear quickly: Copilot’s translations were not reliable enough for end-to-end localisation. Common issues included: CTAs translated too literally tone and style varying between languages placeholders being removed or changed formatting differences in lists, spacing, and structure CTAs translated too literally tone and style varying between languages placeholders being removed or changed formatting differences in lists, spacing, and structure This made Copilot useful only for generating a first draft.A second quality-check layer was necessary. Attempt 2: Adding GPT-4.1 Mini for QA Attempt 2: Adding GPT-4.1 Mini for QA The next version added a review step: Copilot → initial translation GPT-4.1 mini (Azure) → QA and consistency check Copilot → initial translation GPT-4.1 mini (Azure) → QA and consistency check GPT-4.1 mini improved: tone consistency placeholder preservation formatting stability alignment with the source meaning tone consistency placeholder preservation formatting stability alignment with the source meaning The prompts needed tuning to avoid unnecessary rewriting, but after adjustments, outputs became consistent enough to use in the workflow. Engineering Work: Making the Workflow Reliable Engineering Work: Making the Workflow Reliable The architecture was simple, but several issues appeared during real use and needed fixes. Platform behaviour: Platform behaviour: SharePoint triggers did not always start immediately, so checks and retries were added. Teams routing failed when channels were renamed, so the mapping had to be updated. SharePoint triggers did not always start immediately, so checks and retries were added. Teams routing failed when channels were renamed, so the mapping had to be updated. Design issues: Design issues: Some parallel steps failed on the first run, so retry logic was introduced. JSON responses were sometimes missing expected fields, so validation was added. File names were inconsistent, so a single naming format was defined. Some parallel steps failed on the first run, so retry logic was introduced. JSON responses were sometimes missing expected fields, so validation was added. File names were inconsistent, so a single naming format was defined. After these adjustments, the workflow ran reliably under normal conditions. Final Prototype Architecture Final Prototype Architecture Below is the complete working structure of the system. 1. SharePoint Upload & Intake 1. SharePoint Upload & Intake The process began when a file was uploaded into Email translations / 01_Incoming_EN Email translations / 01_Incoming_EN Power Automate then: checked that the file was fully uploaded (zero-byte guard) retrieved metadata extracted text identified target regions checked that the file was fully uploaded (zero-byte guard) retrieved metadata extracted text identified target regions SharePoint acted as the single source of truth for all stages. 2. Power Automate Orchestration 2. Power Automate Orchestration Power Automate controlled every part of the workflow: reading the English source calling Copilot for draft translation sending the draft to GPT-4.1 mini for QA creating a branch per region emailing output to local teams posting Teams approval cards capturing “approve” or “request changes” saving approved files in 04_Approved saving updated versions in 03_In_Review archiving old versions in 99_Archive reading the English source calling Copilot for draft translation sending the draft to GPT-4.1 mini for QA creating a branch per region emailing output to local teams posting Teams approval cards capturing “approve” or “request changes” saving approved files in 04_Approved 04_Approved saving updated versions in 03_In_Review 03_In_Review archiving old versions in 99_Archive 99_Archive All routing, retries, and state transitions were handled by Power Automate. 3. Copilot Translation Pass 3. Copilot Translation Pass Copilot translated the extracted content and preserved most of the email structure - lists, spacing, and formatting - better than GPT alone. 4. GPT-4.1 Mini QA Pass 4. GPT-4.1 Mini QA Pass GPT-4.1 mini checked: tone consistency meaning alignment formatting stability placeholder integrity tone consistency meaning alignment formatting stability placeholder integrity This created a more reliable draft for regional review. 5. Regional Review (Email + Teams) 5. Regional Review (Email + Teams) For each region, Power Automate: sent the translated file by email posted a Teams adaptive card with Approve / Request changes sent the translated file by email posted a Teams adaptive card with Approve / Request changes Approve Request changes If changes were submitted, the updated file returned to 03_In_Review and re-entered the workflow. 03_In_Review 6. Final Storage 6. Final Storage Approved translations were stored in 04_Approved using a consistent naming format. 04_Approved Rejected or outdated versions were moved to 99_Archive. This ensured a complete and clean audit trail. 99_Archive. Results Results After testing the prototype in real workflows: translation time dropped from days to minutes fewer version conflicts minimal manual rewriting faster review cycles all data processed inside the Microsoft environment translation time dropped from days to minutes fewer version conflicts minimal manual rewriting faster review cycles all data processed inside the Microsoft environment This did not replace dedicated localisation systems, but it removed a significant amount of repetitive manual work. Limitations Limitations some languages still required stylistic adjustments Teams approvals depended on reviewer response times the flow needed retry logic for transient errors tone consistency varied on long or complex emails some languages still required stylistic adjustments Teams approvals depended on reviewer response times the flow needed retry logic for transient errors tone consistency varied on long or complex emails These were acceptable for a prototype. Next Step: Terminology Memory Next Step: Terminology Memory The next planned improvement is a vector-based terminology library containing: glossary product names restricted terms region-specific phrasing synonym groups tone rules glossary product names restricted terms region-specific phrasing synonym groups tone rules Both models would use this library before producing or checking translations. Final Thoughts Final Thoughts This project was an internal experiment to understand how much of the localisation workflow could be automated using only standard Microsoft tools and one Azure-hosted LLM. The prototype significantly reduced manual effort and improved consistency across regions without adding new software. It isn’t a full localisation platform - but it shows what can be achieved with a simple, well-structured workflow inside the existing enterprise stack.
