Power Pages: Mehrsprachige Websites per Plugin für GitHub Copilot CLI und Claude Code

Executive Summary

Kennst du den Satz „Französisch machen wir in Phase 2“? Das ist der Satz, mit dem in Lenkungsausschüssen Mehrsprachigkeit beerdigt wird. Phase 2 kommt nie, das Budget ist weg, und der Kunde in Lausanne liest dein Portal mit dem Browser-Übersetzer, der aus „Antrag stellen“ zuverlässig etwas Peinliches macht. Genau an dieser Stelle setzt Microsoft jetzt an.

Das Power-Pages-Plugin für GitHub Copilot CLI und Claude Code hat Mitte Oktober 2026 den neuen Skill /add-localization bekommen. Der Agent macht damit aus einer bestehenden Power-Pages-Code-Site eine mehrsprachige Website: Er erkennt das Framework (React, Vue oder Angular), legt dir einen Plan zur Freigabe vor, installiert das passende Paket, zieht alle sichtbaren Texte in Sprachdateien, baut eine Sprachauswahl ein und testet jede Sprache im Browser. Unterstützt werden mehr als 43 Sprachen, einschließlich rechts-nach-links-Schriften wie Arabisch und Hebräisch.

Die Kehrseite: Der Skill übersetzt nur die Oberfläche. Dataverse-Inhalte, Umgebungssprachen und die Systemmeldungen von Power Pages bleiben deine Baustelle. Und das Ganze läuft als Preview. Für DACH-Portale mit Deutsch, Französisch, Italienisch und Englisch sinkt der Aufwand trotzdem spürbar – vorausgesetzt, du behandelst die KI-Übersetzung als Rohentwurf und nicht als Endprodukt.

Worum geht es im Detail?

Ein bisschen Hintergrund, damit du die Tragweite einordnen kannst. Power Pages – früher Power Apps Portals, davor Dynamics 365 Portals, davor Adxstudio – war lange eine Welt aus Liquid-Templates, Webseiten-Datensätzen und Content Snippets. Mehrsprachigkeit hieß dort: Sprachpakete in Dataverse aktivieren, jede Seite pro Sprache pflegen und beten, dass niemand ein Snippet vergisst. Funktioniert, ist aber ungefähr so sexy wie eine Steuererklärung in dreifacher Ausfertigung.

Seit einiger Zeit gibt es zusätzlich Code Sites: Single-Page-Applications in React, Vue, Angular oder Astro, die du lokal entwickelst und über die Power Platform CLI nach Power Pages hochlädst. Dataverse, Tabellenberechtigungen und Web-Rollen bleiben, das Frontend ist aber ganz normaler Webcode. Und normaler Webcode ist genau das, was Coding-Agenten gut können.

Im Februar 2026 hat Microsoft deshalb das Power-Pages-Plugin für GitHub Copilot CLI und Claude Code als Public Preview veröffentlicht. Installiert wird es in beiden Werkzeugen mit /plugin marketplace add microsoft/power-platform-skills und /plugin install power-pages@power-platform-skills. Voraussetzung sind Node.js ab Version 18, eine aktuelle PAC CLI, die Azure CLI, angemeldete Sitzungen und eine Umgebung mit Power Pages. Das Plugin kennt die Power-Pages-Eigenheiten – Tabellenberechtigungen, Web-Rollen, Site-Einstellungen, Web-API-Muster – und fragt vor jeder kritischen Änderung nach.

Wie der Skill vorgeht

Spannend ist weniger, dass der Agent übersetzt, sondern wie kontrolliert er es tut. Wer schon einmal einem Agenten beim fröhlichen Umschreiben von 140 Dateien zugesehen hat, weiß das zu schätzen. Der Skill läuft in acht Phasen, und zwei davon sind harte Schranken.

Abbildung 1: Der Ablauf von /add-localization mit Freigabe- und Prüf-Gate

Zuerst prüft ein Skript, welches Framework im Projekt steckt und ob es schon Lokalisierung gibt. Sind die Hinweise widersprüchlich, musst du entscheiden – der Agent rät nicht. Danach fragt er in fester Reihenfolge ab: Sprachen als BCP-47-Tags (also de-DE, de-CH, fr-CH, it-CH), die Standardsprache, den Modus, das Paket und den Übersetzungsweg. Das Ergebnis landet als HTML-Plan im Ordner docs/ und öffnet sich im Browser. Erst wenn du im Terminal zustimmst, wird irgendetwas installiert.

Bei den Paketen ist Microsoft erfreulich paranoid: Ein Skript prüft Kompatibilität, Wartungszustand, Lizenz und Modus. Harte Fehler lassen sich nicht übersteuern, bei Lizenzfragen musst du ausdrücklich bestätigen. Installiert wird eine exakt validierte Version, deren Herkunft über die package-lock.json abgesichert wird. Für Angular empfiehlt der Skill @jsverse/transloco. Alle Einstellungen hält er im Manifest .powerpages-localization.json fest.

Dann folgt die eigentliche Arbeit: sichtbare Texte in sprechende Schlüssel extrahieren, Sprachdateien befüllen, Sprachauswahl einbauen, lang– und dir-Attribute setzen. Vorhandene Übersetzungen bleiben unangetastet. Anschließend prüfen ein unabhängiger Validator, der Build und ein Playwright-Audit die gerenderte Seite in beiden Schreibrichtungen. Eine Sprache, die durchfällt, taucht weder in der Auswahl noch in der automatischen Erkennung noch im Produktiv-Build auf. Und bei KI-Übersetzungen ist ein Warnhinweis Pflicht: Die Texte können Fehler enthalten und müssen vor der Veröffentlichung geprüft werden.

Was genau übersetzt wird – und was nicht

Abbildung 2: Gleiche Seite, zwei Schreibrichtungen – und die Grenze der Zuständigkeit

Was sind Chancen? Was sind Risiken?

Die größte Chance ist banal: Mehrsprachigkeit wandert von „Phase 2“ in den Sprint. Was früher ein bis zwei Wochen Handarbeit war – Strings suchen, Schlüssel erfinden, i18n-Bibliothek anbinden, Sprachumschalter basteln, RTL-Fehler jagen –, erledigt der Agent in einer Sitzung. Bei einem Kundenportal eines Schweizer Verbands haben wir früher allein für das saubere Herausziehen der Texte aus einer gewachsenen React-App vier Personentage gebraucht. Und danach noch einen Tag, weil jemand „Speichern“ an 37 Stellen hart codiert hatte, in drei unterschiedlichen Schreibweisen.

Die zweite Chance ist Disziplin. Plan, Freigabe, Validator, Browser-Test: Der Skill zwingt dir einen Prozess auf, den viele Teams nie hatten. Das ist ein bisschen wie ein Fitnesstrainer, der dich nur ins Studio lässt, wenn du vorher den Gesundheitscheck machst. Nervig, aber du überlebst länger.

Kommen wir zum unterhaltsamen Teil. KI-Übersetzungen sind gefährlich, weil sie so überzeugend aussehen. Ein Fehler, der holpert, fällt auf. Ein Fehler, der elegant formuliert ist, geht live. In einem Portal für Fördermittelanträge hat eine automatische Übersetzung einmal aus „Frist gewahrt“ ein französisches „Frist verpasst“ gemacht. Niemand hat es bemerkt, bis die ersten Antragsteller ihre Unterlagen gar nicht mehr eingereicht haben. Der Agent hatte seine Arbeit gemacht, das Team seine nicht.

Beim Thema RTL gilt: Der Playwright-Audit findet viel, aber nicht alles. Gespiegelte Pfeile, Icons mit Leserichtung, Formulare mit Telefonnummern, Datumsfelder, eingebettete Drittkomponenten – der Skill dokumentiert seine Befunde, die visuelle Abnahme bleibt aber ausdrücklich Handarbeit. Nichts sagt so überzeugend „Wir nehmen den Nahen Osten ernst“ wie ein Checkout, dessen Weiter-Button mutig in die falsche Richtung zeigt und den Kunden zurück in den Warenkorb schickt. Für immer.

Und dann die Preview. Microsoft hat schon in der Skill-Dokumentation Pfade als „vorübergehend nicht verfügbar“ markiert, etwa statisches Angular oder Astro. Das ist ehrlich, heißt aber auch: Was heute funktioniert, kann sich mit dem nächsten Plugin-Update ändern. Für Kundenprojekte mit festem Abnahmetermin ist das kein Ausschlusskriterium, aber ein Grund, Plugin-Version und Lockfile einzufrieren.

Was müssen wir jetzt schon vorbereiten?

Die gute Nachricht: Das meiste, was du vorbereiten musst, ist nicht technisch. Die schlechte: Genau deshalb wird es gern vergessen. Hier die Liste, die wir in Projekten gerade abarbeiten.

Besonders unterschätzt wird die Governance. Claude Code und GitHub Copilot CLI sind Werkzeuge, die auf dem Rechner von Entwicklerinnen und Entwicklern laufen, Code lesen, Befehle ausführen und mit Cloud-Modellen sprechen. Das ist für viele Datenschutzbeauftragte ungefähr so beruhigend wie ein Praktikant mit Generalschlüssel. Kläre vorab, welches Werkzeug mit welcher Lizenz erlaubt ist, welche Repositories der Agent sehen darf und dass er nie gegen Produktion läuft. Wenn ihr einen Betriebsrat habt: Der möchte auch gefragt werden, bevor ein Agent Logs über die Arbeitsweise schreibt.

Technisch solltest du außerdem die Werkzeugkette aktuell halten: Plugin aktualisieren, PAC CLI aktualisieren, Node.js ab Version 18. Wer bereits eine Site mit /create-site startet, kann die Sprachen dort gleich mitbestellen. Bestehende Sites bekommen sie über /add-localization nachgerüstet.

Häufig gestellte Fragen

Funktioniert /add-localization auch mit klassischen Power-Pages-Sites ohne Code-Site?

Nein. Der Skill arbeitet mit Power-Pages-Code-Sites, also Single-Page-Applications in React, Vue oder Angular, die über die Power Platform CLI bereitgestellt werden. Klassische Sites auf Basis von Liquid-Templates lokalisierst du weiterhin über Dataverse-Sprachen und mehrsprachige Inhaltsseiten.

Übersetzt der Skill auch Inhalte aus Dataverse?

Nein, er übersetzt ausschließlich die Texte der Benutzeroberfläche. Dataverse-Datensätze, Umgebungssprachen und Power-Pages-Systemmeldungen musst du separat konfigurieren und übersetzen.

Wie zuverlässig sind die KI-Übersetzungen des Power-Pages-Plugins?

Sie sind ein brauchbarer Rohentwurf, aber kein freigabefähiges Endprodukt. Microsoft schreibt selbst einen Warnhinweis vor, dass die Übersetzungen Fehler enthalten können und vor der Veröffentlichung geprüft werden müssen; für Rechtstexte solltest du leere Sprachdateien wählen und professionell übersetzen lassen.

Brauche ich für das Plugin eine Lizenz für GitHub Copilot oder Claude Code?

Ja, du benötigst Zugang zu GitHub Copilot CLI oder Claude Code mit dem jeweils passenden Abonnement. Dazu kommen Node.js ab Version 18, die Power Platform CLI, die Azure CLI und eine Power-Platform-Umgebung mit Power Pages.

Werden rechts-nach-links-Sprachen wie Arabisch vollständig automatisch umgesetzt?

Der Skill setzt die Schreibrichtung, passt das Layout an und prüft die gerenderte Seite automatisiert im Browser. Die visuelle Abnahme von Icons, Formularen und Drittkomponenten bleibt aber ausdrücklich ein manueller Schritt.