Power Pages /add-localization Adds AI i18n and RTL Testing for React, Vue and Angular SPAs

Microsoft is looking to take the manual grunt work out of that process for developers building modern code-first websites on the Power Platform. According to an announcement on the Microsoft Power Platform Blog by Principal Product Manager Neeraj Nandwana, the Power Pages plugin for GitHub Copilot CLI and Claude Code now includes a dedicated /add-localization skill. Designed for Power Pages single-page application (SPA) sites, the update allows developers to scaffold, translate, and verify interfaces across more than 43 languages—including right-to-left (RTL) languages like Arabic and Hebrew—straight from their terminal coding agent.

While that sounds like magic on paper, enterprise architects and Power Platform veterans know that localization in the Microsoft ecosystem is rarely a one-switch affair. Let us break down exactly how the new /add-localization workflow operates, what Microsoft's technical documentation reveals under the hood, and the critical architectural boundaries between localizing a front-end SPA and localizing the underlying Dataverse environment.

What Is New in the Power Pages Plugin​

The Power Pages plugin is Microsoft's agentic site-authoring bridge for terminal-based AI coding assistants—specifically GitHub Copilot CLI and Anthropic's Claude Code. Instead of clicking through the traditional Power Pages design studio or wiring up boilerplate code by hand, developers use conversational slash commands (like /create-site, /integrate-backend, /setup-auth, and /deploy-site) to build and manage modern SPA code sites.

With the addition of /add-localization, Microsoft is targeting four core areas of front-end internationalization:

• Framework-Specific SPA Support: The skill adds or extends runtime multilingual support for React, Vue, and Angular projects.
• AI-Generated or Blank Translation Resources: Developers can instruct the AI agent to generate initial translations during the authoring phase, or ask it to scaffold blank translation resource files ready to hand off to professional human localization teams.
• Automated Right-to-Left (RTL) Engineering: Rather than leaving bi-directional layout fixes to manual CSS debugging, the skill audits existing layouts, converts directional styling to logical CSS properties, and tests both left-to-right (LTR) and RTL rendering in an actual browser.
• Integrated Site Creation Handoff: When scaffolding a brand-new project with /create-site, the agent now prompts whether the project requires additional languages and hands the workflow directly over to /add-localization without breaking the creation flow.

Section Summary: The /add-localization skill brings conversational, agent-driven i18n scaffolding and automated browser verification to React, Vue, and Angular Power Pages SPAs inside GitHub Copilot CLI and Claude Code.

Under the Hood: The Four-Stage Localization Workflow​

One of the valid criticisms of letting AI agents loose on a codebase is the "black box" problem—nobody wants an enthusiastic CLI tool silently rewriting 80 component files and breaking a production build. To Microsoft's credit, the Power Pages documentation in the MicrosoftDocs/power-pages-docs repository shows a structured, gate-kept workflow that requires explicit developer approval before touching project files.

When you run a prompt from an existing Power Pages code-site folder (which must contain a valid powerpages.config.json file), such as:

/add-localization Add French (fr-FR) and Arabic (ar-SA) to my site. Preserve the existing default language and add a language selector.

Or a simpler natural-language command like:

/add-localization Add French, German, and Arabic

The plugin executes a four-stage pipeline:

1. Plan (Detection and Approval Gate)​

First, the skill inspects your project to detect the front-end framework and any existing localization setup. If you are extending an already localized site, it preserves your current i18n package, default locale, and existing non-empty translations—or it can repair and reconfigure a broken setup. It validates requested locale tags against the standard BCP 47 format (such as fr-FR or ar-SA) and confirms the default fallback locale.

Before changing a single line of code, the skill opens an HTML implementation plan in your browser detailing the target languages, the recommended localization package, and the exact files slated for modification. Nothing happens until you approve the plan in the terminal.

2. Build (Extraction and Component Wiring)​

Once approved, the agent installs the framework-appropriate i18n package and extracts user-visible strings out of your components and into structured translation resource files. According to Microsoft's documentation, this extraction goes beyond basic body text to include navigation menus, form validation messages, accessibility labels (like ARIA attributes), and page metadata. It then populates those files with either AI-generated translations or blank keys, configures default-language fallback behavior, sets document-level language and text-direction attributes, and wires a language selector component into the UI.

3. Verify (Real-Browser Layout and Switching Checks)​

Here is where the workflow earns its keep. Instead of stopping at npm run build, the skill compiles the project and launches a real browser to verify every configured language. It tests live language switching, checks for UI breakage caused by text expansion (anyone who has translated succinct English button labels into German knows that pain), and verifies both LTR and RTL layout directions. If a specific locale triggers a blocking failure during verification, the skill automatically keeps that language hidden from site visitors until the issue is resolved.

4. Review and Deploy​

Finally, the agent presents the verification results for human review. If you ran /add-localization as a standalone command, it asks whether you want to Deploy now or Skip for now. It never pushes to your live environment automatically; whenever you are satisfied, running /deploy-site builds the production bundle and uploads it to Power Pages via the Power Platform CLI (PAC CLI).

Section Summary: The localization pipeline combines BCP 47 tag validation, HTML plan approval, string extraction (including accessibility and validation labels), and automated browser testing that quarantines broken locales before deployment.

Crucial Caveats: Where SPA Localization Ends and Dataverse Begins​

If you are an IT administrator or solution architect, this is the part of the broadcast where you want to lean in and read the fine print. Because Power Pages straddles the worlds of modern JavaScript front ends and enterprise Dataverse back ends, "localization" means two very different things depending on which layer of the stack you are looking at.

Microsoft explicitly notes several boundaries for /add-localization that teams must plan around:

1. UI Strings Only—Not Dataverse Records or Environment Languages: The /add-localization skill localizes your SPA user interface only. It does not provision or enable languages in your underlying Microsoft Dataverse environment, nor does it translate data records stored inside Dataverse tables. To enable environment-level languages or translate custom table and column labels for traditional portal forms and views, administrators still need to configure regional and language options in the Power Platform admin center and the Portals Management app using Dataverse and Power Pages Locale IDs (LCIDs).
2. Template Prerequisites Still Apply: Because client-side localization operates strictly in the SPA layer, running /add-localization does not satisfy a site template's Dataverse language requirements. For example, Microsoft's documentation notes that the curated 311 Portal React SPA template requires English (Dataverse language ID 1033) to be enabled in the target environment before solution import can proceed.
3. System Messages: Underlying Dataverse and Power Pages system messages remain in English or the environment's selected language; they are not rewritten by the front-end i18n package.
4. No Runtime Translation API: When you choose AI-generated translations, those translations are generated during authoring by the coding agent and saved as static resource files inside your project repository. The skill does not attach an Azure AI Translator runtime service, API keys, or external credentials to your live site. Furthermore, Microsoft emphasizes that AI-generated translations and code may contain inaccuracies and must be reviewed by humans before publishing to production.
5. Framework Exceptions (Astro and Angular Static Builds): While the broader Power Pages plugin supports scaffolding sites in Astro, localization for Astro sites is not available yet. Additionally, while React, Vue, and Angular are supported for runtime language switching, Angular static/build-time localization is currently listed in Microsoft's documentation as temporarily unavailable.

Section Summary: Developers must remember that /add-localization only handles static front-end UI strings inside React, Vue, and Angular SPAs; Dataverse table data, environment language packs, and Astro sites remain outside its scope.

How to Install and Test It on Windows​

Ready to take the localization skill for a spin on your development workstation? According to Microsoft's setup documentation, your system should have Node.js 18.0 or later, the latest Azure CLI, Power Platform CLI (PAC CLI) (version 2.6.3 or later is specifically required if you also use server logic), a Power Platform environment with Power Pages enabled, and either GitHub Copilot CLI or Claude Code installed.

To install or update the Power Pages plugin—which also updates your PAC CLI installation, registers the microsoft/power-platform-skills marketplace, and turns on automatic plugin updates—run one of the following commands:

Windows PowerShell:

iwr [!/usr/bin/env node](https://raw.githubusercontent.com/microsoft/power-platform-skills/main/scripts/install.js) -OutFile install.js; node install.js; del install.js

Windows Command Prompt (cmd), macOS, or Linux:

curl -fsSL [!/usr/bin/env node](https://raw.githubusercontent.com/microsoft/power-platform-skills/main/scripts/install.js) | node

Once the script completes:

1. Restart your GitHub Copilot CLI or Claude Code session so the agent registers the newly installed slash commands.
2. Navigate to an existing Power Pages SPA project directory (containing powerpages.config.json) and run /add-localization, or run /create-site in an empty directory and accept the prompt when it offers to configure additional languages.
3. Review the browser-generated HTML plan carefully, approve the terminal prompt, and inspect the resulting translation files before running /deploy-site.

Section Summary: Updating the plugin takes a single PowerShell or curl one-liner that refreshes PAC CLI and registers the /add-localization slash command in GitHub Copilot CLI and Claude Code.

The Bottom Line for Power Platform Developers​

For years, building multilingual portals on the Power Platform felt like an exercise in compromise—frequently sparking frustrated threads in community forums over clunky web-page hierarchies and tedious manual string management. By shifting Power Pages toward standard SPA frameworks (React, Vue, Angular) and pairing them with terminal-based AI agents that actually verify RTL layouts and text expansion in a real browser, Microsoft is addressing one of front-end development's most repetitive chores.

It will not replace a dedicated localization team or magically translate your Dataverse records, and you still need a sharp human eye on those AI-generated language files before hitting deploy. But as a way to turn hours of i18n plumbing and CSS logical-property refactoring into a five-minute terminal review? That speaks every developer's language.