August 8, 2026

Localizing your Edge Add-ons listing

Microsoft Edge Add-ons is the one extension store that decides your listing languages by reading your _locales folder — but only if your manifest points at it correctly. Get that one detail wrong and Partner Center shows a single language, with no error and no explanation. This guide covers the gotcha first, then the full per-language field set.

The gotcha: a perfect _locales folder and still one language

You ship twenty locales. You upload the package. You open Store listings in Partner Center and there is one row: English. No validation error, no warning, no hint about what went wrong.

Microsoft documents this under the heading “If a single locale appears, but the package includes multiple languages”, and the cause is one sentence long:

This happens when the manifest file uses hardcoded strings instead of localized message references.

Partner Center never reads your folder list. It reads the __MSG_ references in your manifest’s name and description fields, then looks up those keys in each locale’s messages.json. Microsoft states it plainly: “Partner Center uses these message references to identify available languages. If these message references are missing, the language will be skipped.” A hardcoded manifest name means there are no references to follow, so every language is skipped except the default.

Side by side, the difference is two lines:

✗ One listing language

{
  "manifest_version": 3,
  "name": "Tab Manager",
  "description": "Groups your tabs.",
  "default_locale": "en"
}

Literal strings. Nothing for Partner Center to resolve, so nothing to enumerate.

✓ Every locale detected

{
  "manifest_version": 3,
  "name": "__MSG_extensionName__",
  "description": "__MSG_extensionDescription__",
  "default_locale": "en"
}

References Partner Center can follow into every messages.json.

Microsoft’s own remediation snippet is exactly this shape:

{
    "manifest_version": 3,
    "name": "__MSG_extensionName__",
    "description": "__MSG_extensionDescription__"
}

plus, in Microsoft’s words, “Include a default_locale in your manifest, such as "default_locale": "en"” and “Make sure your _locales folder contains a properly structured messages.json file for each language.”

Diagnostic: “I uploaded 20 locales and Partner Center shows only English”

Work down this list in order. The first failing check is your answer.

Is manifest name a __MSG_ reference?

Open the manifest.json inside the uploaded ZIP, not the one in your source tree. Build steps substitute values more often than you would expect. If name is a literal string, stop here — this is the bug.

Is manifest description also a __MSG_ reference?

Microsoft names both fields. Localizing only name and leaving description hardcoded is a half-fix — and the description is what populates the Description field on each language page.

Is default_locale present?

Required whenever _locales/ exists — without it the package will not even load in the browser. See default_locale rules and errors for the exact failure messages.

Does every locale define both keys, spelled identically?

__MSG_extensionName__ resolves the key extensionName — not extension_name, not appName. One renamed or missing key in one file removes one language. Microsoft: “If these message references are missing, the language will be skipped.”

Is every messages.json valid, in folders with valid names?

Each value must be an object with a message property — a bare string is not the format, and one trailing comma invalidates the file. Folder names take underscores and exact casing: pt_BR, not pt-BR or pt_br. See validating messages.json and Chrome extension locale codes.

Because both the manifest and the message catalogue must change, the fix is never “click something in Partner Center”. It is: edit the manifest, rebuild the package, re-upload. Budget for that — certification, in Microsoft’s words, “can take up to seven business days” after you submit.

Which fields come from the manifest and cannot be edited

Partner Center’s Store listings page is a table with one row per language, each row leading to a Details for <language> page. Two fields on that page are populated from your package and are read-only there:

•The manifest Name field populates Extension name.
•The manifest Description field populates Description.

Microsoft spells out the consequence for the short description:

To edit the short description, you must update the description field in the manifest file of the extension package, and then re-upload the package.

The same round trip applies to the extension name. This is the structural difference from the Chrome Web Store, where the long store description is dashboard-only text that never appears in your package. On Edge, your repository is the source of truth for the name and the short description — which is good news, because it means those two strings are versioned, diffable and translated by the same pipeline as your UI strings.

If your manifest short description and your listing copy have drifted apart, the manifest wins. Fix it in messages.json and repackage rather than looking for an override in Partner Center — there is not one.

What is required per language, and what is not

Microsoft splits the required fields into two tiers, and the split is the thing to internalise before you add your tenth language:

Required for EACH language in the package

DescriptionExtension logo

Required for AT LEAST ONE language

Extension nameShort description

So every language you enable costs you a full description and a logo. The description is the expensive half, because of its length rule:

Minimum 250 characters, maximum 10,000 characters.

The minimum is what catches people. Every language needs at least 250 characters of description — a translated one-line pitch will not save. If you enable twelve languages you are committing to twelve descriptions of 250+ characters each, not twelve translations of a tagline.

The asset requirements, all per language, with a Duplicate option below each field once uploaded that copies it to every other language:

Asset	Required?	Size
Extension logo	Each language	1:1 · 300×300 recommended · 128×128 min
Small promotional tile	Optional	440×280
Large promotional tile	Optional	1400×560 (PNG)
Screenshots	Optional · max 6	640×480 or 1280×800
YouTube video URL	Optional	—

Use Duplicate for anything without text baked into the image. A logo is almost always identical across languages; screenshots with visible UI copy are the case where duplicating costs you the localization you just paid for.

Search terms are per-language and invisible

Each Details for <language> page has its own Search terms box, and Microsoft notes the terms “aren’t displayed to users”. The limits are specific:

•Up to a maximum of 21 words total — whether used as single words, phrases, or a combination of both.
•Up to a maximum of seven search terms (single words or phrases).
•Each search term is limited to 30 characters.

Do not machine-translate your English keywords here. Search terms are the one field where a literal translation is usually wrong — German users search for different phrases than English users, not for translated English phrases. This field wants per-language keyword research, or nothing.

Markets and languages are separate settings

They live on different pages of the submission flow and they control different things. Conflating them is the second most common Edge listing mistake after the __MSG_ one.

	Markets	Languages
Set on	Availability page	Store listings page
Controls	Where the extension can be installed	Which translations of the listing text exist
Default	All markets, including future ones	Whatever the package's __MSG_ references resolve to
Changing it	Change markets button	Repackage, or Add a language dropdown
Getting it wrong	Users cannot install	Users install, then read English

Microsoft notes that the default for markets is all markets, “and that includes any future markets that are added later”. So unless you deliberately narrowed it, you are already available everywhere — and a missing German listing is a translation gap, not an availability gap.

One consequence worth planning around: restricting markets after launch does not remove the extension from users who already installed it, but Microsoft states such a user “doesn’t have access to any future updates”. Narrow markets deliberately, not as a side effect of tidying up a listing.

Adding and removing languages

There are two routes into the language list, and they are not equivalent. The one you want is from the package: ship __MSG_ references in the manifest plus a messages.json per locale, and Partner Center enumerates the languages for you — with the extension name and short description already translated, because they come from the catalogue.

The manual route is the Add a language dropdown on the Store Listings page; selecting a language opens a new Details for <language> page for it, and a language row can be removed with Remove on that row. That gives you a listing page, but it does not give you translated in-extension strings and it does not translate the manifest-sourced fields. Treat it as a supplement. If you find yourself using it for ten languages, the real fix is upstream in the manifest.

The AI description generator

Partner Center offers an optional Generate with AI button below the Description box. It is worth knowing what it does before you lean on it for a dozen languages:

•It is powered by Azure OpenAI, generating from your uploaded package (manifest, code files, image files), any screenshots you uploaded on the language page, and optional prompt text you supply.
•It works one language at a time, individually, and is rate-limited to 10 generations per hour — it is not a bulk translation pass.
•You can apply, edit or discard the result, and Microsoft is explicit that “you’re responsible for the quality and accuracy of the final description.”

Generating each language independently from the package produces twelve descriptions that are not translations of each other. Different emphasis, different feature lists, possibly different claims — and you are accountable for all of them. For a consistent message, write and translate one description, and use the generator as a drafting aid rather than a localization pipeline.

One _locales tree, two jobs

Microsoft’s guidance for supporting multiple languages in extension code points straight at chrome.i18n — the same API, the same catalogue format, the same folder layout as Chrome. Which means a single _locales tree is doing two unrelated jobs at once:

_locales/
├── en/messages.json
├── de/messages.json
├── ja/messages.json
└── pt_BR/messages.json

  ├─ runtime  → chrome.i18n.getMessage() in your popup, options page,
  │            content scripts. Read by the browser, on the user's machine.
  │
  └─ listing  → Partner Center resolves __MSG_extensionName__ and
               __MSG_extensionDescription__ to decide which listing
               languages exist. Read once, at upload time.

This is unusual. On Chrome and Firefox the listing and the package are largely separate concerns — see store listing vs in-extension i18n for how that division normally works, and localizing your Firefox AMO listing for Mozilla’s take. On Edge they are wired together, so a change to your _locales tree can silently change which store languages you have.

Practical consequence: deleting a locale folder to slim down a package removes a store listing language. Adding one adds a language — along with an obligation to write a 250+ character description and supply a logo for it. Locale folders are not free on Edge. For the placeholder mechanics themselves, see __MSG_ keys in manifest.json; if you also publish to Chrome, the CWS listing automation script handles the equivalent per-language grind there.

Frequently asked questions

Why does Partner Center show only one language in Store listings?

Because your manifest hardcodes name and description instead of using __MSG_ references. Microsoft states: “This happens when the manifest file uses hardcoded strings instead of localized message references.” Partner Center reads the __MSG_ placeholders in manifest name and description to work out which languages exist. With literal strings there is nothing to resolve, so it finds exactly one language — no matter how many folders sit in _locales.

How do I add more listing languages to my Edge extension?

Set manifest name to __MSG_extensionName__ and description to __MSG_extensionDescription__, add default_locale, ship a messages.json under _locales for each language defining those keys, then repackage and re-upload. Microsoft warns: “If these message references are missing, the language will be skipped.” You can also add a language manually from the Add a language dropdown on the Store Listings page.

Why is Extension name read-only in Partner Center?

Extension name and Short description are populated from the manifest and cannot be typed into Partner Center. Microsoft's documentation is explicit for the short description: “To edit the short description, you must update the description field in the manifest file of the extension package, and then re-upload the package.” The same applies to the name — update the manifest, create a new package, re-upload.

What is the minimum description length for an Edge Add-ons listing?

Microsoft specifies “Minimum 250 characters, maximum 10,000 characters” for the Description field. The minimum is the part that catches people out: it is required for every language, so each translation must clear 250 characters too. A translated one-line pitch will not pass.

Are Edge markets and languages the same setting?

No. Markets are configured on the Availability page and control where the extension can be installed. Languages are configured on the Store listings page and control which translations of your listing text exist. They are set independently — selling into Germany does not create a German listing, and adding a German listing does not make the extension available in Germany.

Can I reuse my Chrome _locales folder for the Edge Add-ons store?

Yes, and you should. Microsoft points developers at chrome.i18n for extension internationalization, and Partner Center reads the same _locales/<code>/messages.json structure Chrome uses. One correctly named _locales tree serves Chrome runtime strings, Edge runtime strings and Edge listing-language detection at the same time.

The _locales tree Partner Center is looking for

LocalePack takes your messages.json and returns a _locales ZIP in 52 locales, every folder name a valid Chrome locale code — which is exactly what Partner Center scans to discover your listing languages, and what AMO parses on upload. Placeholders like $PLACEHOLDER$ and $1 survive intact. Store-listing copy is handled separately, with character limits enforced on the output. Pay once, no account, no subscription.

Translate your messages.json into 52 locales →

← Back to Guides