I shipped my extension in 9 languages to two stores. Here's what broke.
I shipped the same extension update to the Microsoft Edge Add-ons store and the Chrome Web Store in nine languages last week. The code change was maybe forty lines. The listing work took two days and broke in three different ways.
If you're about to localize a browser extension, here's what the consoles do not warn you about.
Why bother localizing at all
When you have no audience, store search is the only distribution channel you get for free. A monolingual listing only competes in English — the most crowded query space in both stores. A localized listing competes in a much thinner pool, because most indie extensions never translate anything.
That's the whole argument. It is not about "global reach". It's about being one of four results instead of one of four hundred.
Gotcha 1: every locale has its own character limit, and one of them is brutal
In Edge Add-ons, the short description stored in your manifest (extDescription) is capped at 132 characters — per locale, and it's a hard package-level validation, not a warning. I had five of nine locales over the limit and did not find out until the upload refused the package.
German and Russian blew past it almost immediately, because the same sentence is simply longer in those languages. "Summarize any page with your own AI key" is 41 characters in English and comfortably over budget once translated with any precision.
The fix is unglamorous: write the translation, then cut it to fit, then accept that the German short description is going to be a slightly different sentence than the English one. Don't translate; rewrite for the constraint.
The long description has a floor as well as a ceiling — 250 to 2000 characters. A too-short translation fails validation just like a too-long one, which is easy to hit in languages where you are being terse.
Gotcha 2: search terms are a budget, not a field
Edge gives you up to 7 search terms per language, and caps you at 21 unique terms across the whole listing. Not 21 per language — 21 total, deduplicated across all nine.
That means the term you use in English ("cookie banner") and the term you use in German ("Cookie-Banner") count separately, but repeating "cookie" in six languages does not give you six shots at it. Two of my listings blew the global budget — 23 and 22 terms — because I had been treating each language as an independent listing.
Plan the term set once, in a spreadsheet, before you touch the console. The console will let you type the eighth term and only complain at submit time.
Gotcha 3: the language dropdown is asynchronous and it will silently eat your work
This one cost me an entire product's listing.
In the Chrome Web Store dev console, the "edit language" control is a custom dropdown that loads its options asynchronously. If you switch language and start typing into the description field within a second or two, you are still writing into the previous language's field. Nothing visually indicates this. The field looks empty because it re-renders, and your input lands wherever the model currently points.
The result: every locale ended up holding the text of its neighbour. English field held German, German held Russian, and so on down the list. The store accepted it without complaint, because each field was a valid description of the right length.
Two rules came out of that:
- After switching, poll the page until the visible "currently editing language" indicator actually names the language you asked for. Do not rely on a fixed sleep.
- Verify by reading the saved text back, per locale, with a page refresh between switches. One page load can reliably switch language once; a second switch in the same load is where it goes wrong.
Read-back verification is the only thing that caught this. A screenshot would not have.
Gotcha 4: naming other companies' products gets you rejected for keyword spam
My first submission was rejected by an automated check within ten minutes.
The cause was a sentence in the description listing the consent-management platforms the extension supports — eight third-party trademarks in a row. To a human that reads as a feature list. To the automated reviewer it reads as keyword stuffing.
I rewrote it as a capability statement — what the extension does to a banner, not whose banner it is — and it went through. The same wording problem had already burned me once on a different product and a different store, so this is a pattern, not bad luck:
Describe what your software does. Do not enumerate other companies' names to prove coverage.
Gotcha 5: in Edge, editing the Properties page saves a draft and nothing else
The Partner Center has a page where you can edit your listing properties. Editing there and hitting save does not publish anything. The change sits as a draft until you walk the full update flow — Properties, then Privacy, then Listings, then Publish, then Submit — and the certification notes field must be filled or the submit is blocked.
Also, re-rendering between steps clears fields you already filled. In my case the certification notes textarea was wiped by clicking a radio button after typing. Fill the free-text explanation last.
The verification loop that actually works
After all of that, the process I'd keep is:
- Precheck locally. Character counts, term counts, and a scan for third-party brand names — all checkable before upload, none checkable after rejection.
- Fill one language at a time, confirming the active language before typing.
- Read back every field, refreshing between languages, and diff against your source text.
- Publish last, and treat any field with free text as something that may be cleared by the next click.
None of this is interesting engineering. It's just the difference between shipping in two days and shipping in two weeks.
I build small, privacy-first browser extensions — everything runs locally, and when an AI feature needs a model you bring your own key. If the workflow above saved you a rejection, the extensions are at glenkit.com.