Developer Guides
Deep-dive guides on i18n formats and frameworks — messages.json, Next.js translations, i18next, and more — written for developers, not translators.
Why Partner Center shows only one listing language even when your package ships twenty, how __MSG_ manifest references drive language detection, and which listing fields Edge requires for every language versus just one.
How to localize an add-on listing on addons.mozilla.org: which fields can be translated, the 250-character summary ceiling and what it costs you in German and Russian, and the per-locale Developer Hub workflow.
All four chrome.i18n methods with exact signatures and return types: which are synchronous, which return promises, what getMessage() returns when it fails, and how browser.i18n differs in Firefox and Safari.
Every locale code Chrome accepts as a _locales folder name, with language and native names, the underscore-vs-hyphen trap that makes pt-BR silently ignored, and how Chrome picks a locale at runtime.
getMessage() returns an empty string when a message is missing, and logs nothing at all. Every cause of the silent empty string, how to tell it apart from undefined, and how to confirm each one.
Synchronous getMessage() is an advantage in an MV3 service worker, not a problem — a common claim that gets this backwards. What actually breaks is the DOM, global-variable caching, localStorage and XMLHttpRequest.
How @wxt-dev/i18n compiles YAML, JSON, JSONC, JSON5 and TOML message files into standard _locales/{lang}/messages.json — setup, nested keys, plurals, substitutions, type safety, and how to translate a WXT project.
Plasmo does not read _locales/ at the project root. The three paths it does accept, where default_locale actually lives, the alphabetical-default trap, and how to place a translated _locales ZIP correctly.
CRXJS ships no i18n helper and its docs have no i18n page. Here is the working pattern: put _locales under public/, declare default_locale in manifest.config.ts, and call chrome.i18n directly.
How to get accurate AI translations for your Chrome extension: write description fields that give the model context, define placeholders with examples, avoid string concatenation, and handle plurals, casing, and length expansion.
An honest comparison of tools that translate Chrome extension messages.json files: LocalePack, Crowdin, Lokalise, Phrase, POEditor, Localazy, Weblate, and Localeship — setup overhead, pricing models, and placeholder safety.
Honest comparison of LocalePack and Localeship for Chrome Web Store listing translation. Both are pay-per-use tools — the key difference is that LocalePack also translates in-extension messages.json strings.
Honest comparison of LocalePack and POEditor for i18next JSON translation. POEditor is a collaborative TMS with a string-count subscription and a free tier; LocalePack is upload → pay once → download.
Honest comparison of LocalePack and Phrase Strings for Next.js locale JSON translation. Phrase is a full TMS with per-seat subscription pricing; LocalePack is upload → pay once → download.
Honest comparison of LocalePack and Lokalise for Chrome extension messages.json translation. Lokalise is a full TMS with team workflows and a monthly subscription; LocalePack is upload → pay once → download.
Honest comparison of LocalePack and Crowdin for browser extension messages.json translation. Crowdin is a full TMS with ongoing subscription; LocalePack is upload → pay once → download.
How to bulk-fill all 52 Chrome Web Store listing translations at once using a browser console script — no manual copy-paste per language.
Why Crowdin, Lokalise, and Phrase are overkill for most browser extension projects — and three real alternatives for indie developers who need to translate messages.json without a monthly subscription.
A complete reference for the i18next JSON locale format — namespace files, double-brace {{placeholder}} syntax, _one/_other plural keys, nested objects, and how to structure your locales/ folder.
The vue-i18n locale file format — pipe-separated plurals, {named} placeholders, linked locale messages, YAML support, and SFC i18n blocks.
Practical comparison of the three leading Next.js i18n libraries — App Router support, file format, TypeScript safety, pluralization syntax, and when to pick each one.
How the __MSG_key__ substitution syntax works in Chrome and Firefox extension manifests: which fields support it, how Chrome resolves tokens at load time, and the pitfalls that cause silent failures or upload rejections.
How to catch every class of messages.json error before your users do: JSON syntax, missing required fields, missing keys across locales, malformed placeholder syntax, and manifest key mismatches.
Step-by-step guide to adding i18n to a Chrome extension: _locales structure, default_locale, messages.json syntax, chrome.i18n.getMessage(), placeholder preservation, and how to test locale switching.
A complete reference for the WebExtension messages.json format: the message, description, and placeholders fields, $PLACEHOLDER$ syntax, $1 positional substitutions, and common mistakes.
How to set up the _locales folder, what default_locale does in manifest.json, and how Chrome picks the right messages.json at runtime.
Why default_locale is required when _locales exists, what happens when you omit it, and how to fix the most common manifest validation errors.
Using browser.i18n in Firefox add-ons: the messages.json format, AMO localization requirements, and how to avoid common pitfalls on addons.mozilla.org.
How Safari Web Extensions use the same messages.json/_locales format as Chrome and Firefox, and what to know for Mac App Store submission.
The difference between localizing your Chrome Web Store listing and localizing in-extension strings — and the _MSG_ pattern that bridges them.