Developer Guides
Deep-dive guides on i18n formats and frameworks — messages.json, Next.js translations, i18next, and more — written for developers, not translators.
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.