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: n 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:
| Folder | Purpose |
|—-|—-|
| 01IncomingEN | Source English files; Power Automate trigger |
| 02AIDrafts | Auto-translated drafts from Copilot + GPT |
| 03InReview | Files waiting for regional review |
| 04Approved | Final approved translations |
| 99Archive | 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
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
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 01IncomingEN.
- 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
This made Copilot useful only for generating a first draft. n A second quality-check layer was necessary.
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
GPT-4.1 mini improved:
- 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
The architecture was simple, but several issues appeared during real use and needed fixes.
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.
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.
After these adjustments, the workflow ran reliably under normal conditions.
Final Prototype Architecture
Below is the complete working structure of the system.
1. SharePoint Upload & Intake
The process began when a file was uploaded into Email translations / 01IncomingEN
Power Automate then:
- 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
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 03InReview
- archiving old versions in 99_Archive
All routing, retries, and state transitions were handled by Power Automate.
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
GPT-4.1 mini checked:
- tone consistency
- meaning alignment
- formatting stability
- placeholder integrity
This created a more reliable draft for regional review.
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
If changes were submitted, the updated file returned to 03InReview and re-entered the workflow.
6. Final Storage
Approved translations were stored in 04_Approved using a consistent naming format.
Rejected or outdated versions were moved to 99_Archive. This ensured a complete and clean audit trail.
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
This did not replace dedicated localisation systems, but it removed a significant amount of repetitive manual work.
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
These were acceptable for a prototype.
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
Both models would use this library before producing or checking translations.
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.
