Wie ich einen 13-sprachigen E-Mail-Workflow nur mit KI und Microsoft-Tools automatisiert habe

Die Lokalisierung von E-Mail-Kampagnen über mehrere Regionen hinweg war früher eine langsame, sich wiederholende Aufgabe mit vielen manuellen Schritten. Mehrere Prüfer arbeiteten an separaten Versionen, derselbe Inhalt wurde mehrmals umgeschrieben, und die Verwaltung der Konsistenz über bis zu 13 Sprachen hinweg erforderte erhebliche Koordination.

Anstatt neue Plattformen oder externe Tools einzuführen, führte ich ein internes Experiment durch: \n Könnte die Lokalisierung automatisiert werden, indem nur die Tools verwendet werden, die bereits in einer Standard-Microsoft-Unternehmensumgebung verfügbar sind?

Der Prototyp basierte hauptsächlich auf SharePoint, Power Automate und Teams, mit einer zusätzlichen Komponente - GPT-4.1 mini, auf die über Azure OpenAI zugegriffen wurde - die ausschließlich für einen kontrollierten QA-Schritt verwendet wurde. Dies ermöglichte es dem Prozess, von LLM-basiertem Reasoning zu profitieren, während alle Daten in derselben Unternehmensumgebung blieben.

Um diesen Workflow zu unterstützen, richtete ich eine strukturierte SharePoint-Bibliothek namens Email translations mit Ordnern ein, die jede Phase des Lokalisierungslebenszyklus repräsentieren:

| Ordner | Zweck | |----|----| | 01IncomingEN | Englische Quelldateien; Power Automate-Auslöser | | 02AIDrafts | Automatisch übersetzte Entwürfe von Copilot + GPT | | 03InReview | Dateien, die auf regionale Überprüfung warten | | 04Approved | Endgültig genehmigte Übersetzungen | | 99Archive | Archivierte oder abgelehnte Versionen |

Dateien wurden je nach ihrem Status automatisch zwischen diesen Ordnern verschoben.

Das Ziel war nicht, ein perfektes Lokalisierungssystem zu erstellen - sondern nur zu sehen, wie weit ein Prototyp mit internen Tools gehen könnte.

Am Ende wurden ein großer Teil der sich wiederholenden Arbeit beseitigt und ein weitaus strukturierterer Überprüfungsprozess geschaffen.

Das Problem: Prozess, nicht Sprache

Die manuelle Lokalisierung von Inhalten über viele Regionen hinweg verursachte mehrere konsistente Probleme:

• Jede Region bearbeitete ihre eigene Datei, sodass gleichzeitig mehrere verschiedene Versionen existierten.
• Wenn sich der Quelltext änderte, aktualisierten nicht alle Regionen ihre Version, was zu nicht übereinstimmenden Inhalten führte.
• Dateien wurden an verschiedenen Orten und mit unterschiedlichen Namen gespeichert, was es schwierig machte zu erkennen, welche Version aktuell war.
• Überprüfungen nahmen Zeit in Anspruch, besonders wenn Teams in verschiedenen Zeitzonen arbeiteten.
• Die Wiederholung derselben Bearbeitungen in vielen Dateien erhöhte das Risiko kleiner Fehler

Versuch 1: Nur-Copilot-Übersetzung

Obwohl Copilot jetzt auf neueren GPT-5-Serienmodellen läuft, wurde dieser Prototyp auf einer früheren Version aufgebaut, und das Übersetzungsverhalten spiegelte diese früheren Fähigkeiten wider.

Die erste Version des Workflows war einfach:

1. Eine Datei wurde in 01IncomingEN hochgeladen.
2. Power Automate wurde automatisch ausgelöst.
3. Copilot generierte eine Übersetzung für jede Region.

Da SharePoint-Trigger ausgelöst werden können, bevor eine Datei vollständig hochgeladen ist, enthielt der Flow eine Dateigröße-Vollständigkeitsprüfung (warten, bis die Größe > 0 ist, bevor fortgefahren wird).

Das Hauptproblem wurde jedoch schnell klar: Copilots Übersetzungen waren nicht zuverlässig genug für eine End-to-End-Lokalisierung.

Zu den häufigen Problemen gehörten:

• CTAs wurden zu wörtlich übersetzt
• Ton und Stil variierten zwischen den Sprachen
• Platzhalter wurden entfernt oder geändert
• Formatierungsunterschiede in Listen, Abständen und Struktur

Dies machte Copilot nur für die Erstellung eines ersten Entwurfs nützlich. \n Eine zweite Qualitätsprüfungsschicht war notwendig.

Versuch 2: Hinzufügen von GPT-4.1 Mini für QA

Die nächste Version fügte einen Überprüfungsschritt hinzu:

1. Copilot → erste Übersetzung
2. GPT-4.1 mini (Azure) → QA und Konsistenzprüfung

GPT-4.1 mini verbesserte:

• Tonkonsistenz
• Platzhaltererhaltung
• Formatierungsstabilität
• Ausrichtung an der Quellbedeutung

Die Prompts mussten angepasst werden, um unnötiges Umschreiben zu vermeiden, aber nach Anpassungen wurden die Ausgaben konsistent genug, um sie im Workflow zu verwenden.

Engineering-Arbeit: Den Workflow zuverlässig machen

Die Architektur war einfach, aber während des realen Einsatzes traten mehrere Probleme auf, die behoben werden mussten.

Plattformverhalten:

• SharePoint-Trigger starteten nicht immer sofort, daher wurden Prüfungen und Wiederholungen hinzugefügt.
• Teams-Routing schlug fehl, wenn Kanäle umbenannt wurden, daher musste das Mapping aktualisiert werden.

Designprobleme:

• Einige parallele Schritte schlugen beim ersten Durchlauf fehl, daher wurde eine Wiederholungslogik eingeführt.
• JSON-Antworten fehlten manchmal erwartete Felder, daher wurde eine Validierung hinzugefügt.
• Dateinamen waren inkonsistent, daher wurde ein einheitliches Benennungsformat definiert.

Nach diesen Anpassungen lief der Workflow unter normalen Bedingungen zuverlässig.

Endgültige Prototyp-Architektur

Unten ist die vollständige Arbeitsstruktur des Systems.

1. SharePoint-Upload & Aufnahme

Der Prozess begann, wenn eine Datei in Email translations / 01IncomingEN hochgeladen wurde

Power Automate dann:

• prüfte, dass die Datei vollständig hochgeladen wurde (Null-Byte-Schutz)
• holte Metadaten ab
• extrahierte Text
• identifizierte Zielregionen

SharePoint fungierte als einzige Quelle der Wahrheit für alle Phasen.

2. Power Automate-Orchestrierung

Power Automate kontrollierte jeden Teil des Workflows:

• Lesen der englischen Quelle
• Aufrufen von Copilot für Entwurfsübersetzung
• Senden des Entwurfs an GPT-4.1 mini für QA
• Erstellen eines Zweigs pro Region
• E-Mail-Versand der Ausgabe an lokale Teams
• Posten von Teams-Genehmigungskarten
• Erfassen von "genehmigen" oder "Änderungen anfordern"
• Speichern genehmigter Dateien in 04_Approved
• Speichern aktualisierter Versionen in 03InReview
• Archivieren alter Versionen in 99_Archive

Alle Routing, Wiederholungen und Zustandsübergänge wurden von Power Automate verwaltet.

3. Copilot-Übersetzungsdurchlauf

Copilot übersetzte den extrahierten Inhalt und bewahrte den größten Teil der E-Mail-Struktur - Listen, Abstände und Formatierung - besser als GPT allein.

4. GPT-4.1 Mini QA-Durchlauf

GPT-4.1 mini prüfte:

• Tonkonsistenz
• Bedeutungsausrichtung
• Formatierungsstabilität
• Platzhalterintegrität

Dies schuf einen zuverlässigeren Entwurf für die regionale Überprüfung.

5. Regionale Überprüfung (E-Mail + Teams)

Für jede Region, Power Automate:

• sendete die übersetzte Datei per E-Mail
• postete eine Teams adaptive Karte mit Genehmigen / Änderungen anfordern

Wenn Änderungen eingereicht wurden, kehrte die aktualisierte Datei zu 03InReview zurück und trat wieder in den Workflow ein.

6. Endgültige Speicherung

Genehmigte Übersetzungen wurden in 04_Approved unter Verwendung eines konsistenten Benennungsformats gespeichert.

Abgelehnte oder veraltete Versionen wurden nach 99_Archive verschoben. Dies gewährleistete einen vollständigen und sauberen Prüfpfad.

Ergebnisse

Nach dem Testen des Prototyps in realen Workflows:

• Übersetzungszeit sank von Tagen auf Minuten
• weniger Versionskonflikte
• minimales manuelles Umschreiben
• schnellere Überprüfungszyklen
• alle Daten wurden innerhalb der Microsoft-Umgebung verarbeitet

Dies ersetzte keine dedizierten Lokalisierungssysteme, beseitigte aber einen erheblichen Teil der sich wiederholenden manuellen Arbeit.

Einschränkungen

• einige Sprachen erforderten immer noch stilistische Anpassungen
• Teams-Genehmigungen hingen von den Antwortzeiten der Prüfer ab
• der Flow benötigte eine Wiederholungslogik für vorübergehende Fehler
• Tonkonsistenz variierte bei langen oder komplexen E-Mails

Diese waren für einen Prototyp akzeptabel.

Nächster Schritt: Terminologie-Speicher

Die nächste geplante Verbesserung ist eine vektorbasierte Terminologiebibliothek, die enthält:

• Glossar
• Produktnamen
• eingeschränkte Begriffe
• regionsspezifische Formulierungen
• Synonymgruppen
• Tonregeln

Beide Modelle würden diese Bibliothek verwenden, bevor sie Übersetzungen erstellen oder überprüfen.

Abschließende Gedanken

Dieses Projekt war ein internes Experiment, um zu verstehen, wie viel des Lokalisierungs-Workflows automatisiert werden könnte, indem nur Standard-Microsoft-Tools und ein Azure-gehostetes LLM verwendet werden. Der Prototyp reduzierte den manuellen Aufwand erheblich und verbesserte die Konsistenz über Regionen hinweg, ohne neue Software hinzuzufügen.

Es ist keine vollstän