In 2004, most web users encountered foreign-language content and gave up. Machine translation existed — AltaVista’s Babel Fish had been available since 1997 — but accessing it required navigating to a separate site, pasting the URL or text, and reading the result in a new context entirely. If you were reading a page in German and wanted to understand a paragraph, the friction was high enough that most people didn’t bother.
TranslatePage changed that workflow for Firefox users. Developed as part of the Palancar extension suite at palancar.net, it added a right-click option that either translated selected text or the entire current page using an external translation service — without leaving the page you were reading. It was one of the first browser extensions to treat translation as a contextual action rather than a separate destination.
What TranslatePage Was
TranslatePage added two options to Firefox’s right-click context menu:
Translate selected text — highlight a word, phrase, or passage, right-click, and send the selection to a translation service. The result opened in a small window or new tab, depending on the configuration.
Translate this page — right-click anywhere on the page to submit the entire page URL to a translation service for a full-page translation.
The extension supported multiple translation services, including AltaVista Babel Fish, Google Translate (once it launched in 2006), and several regional services. Users could configure which service was used by default and, in later versions, could access a submenu showing multiple services simultaneously.
The extension was active on addons.mozilla.org throughout the Firefox 1.x through 3.x era. The palancar.net extension page accumulated backlinks from Firefox resource sites and multilingual web user communities. Given the practical need it addressed — language access for web content — it found a user base across Europe, Latin America, and international developer communities.
How It Worked Technically
TranslatePage used Firefox’s XUL context menu system to inject right-click options, and the translation mechanism itself was straightforward: it constructed a URL pointing to the chosen translation service with the appropriate query parameters.
For page translation:
// Simplified: send current page URL to translation service
var pageURL = encodeURIComponent(content.document.location.href);
var sourceLang = 'auto'; // Auto-detect, or user-configured
var targetLang = userPrefs.getCharPref('translatepage.targetlang');
var translateURL = 'https://translate.google.com/translate?sl=' + sourceLang
+ '&tl=' + targetLang
+ '&u=' + pageURL;
gBrowser.loadOneTab(translateURL, { inBackground: false });
For text translation, the selected text was passed as a query parameter:
var selectedText = encodeURIComponent(getBrowserSelection().toString());
var translateURL = 'https://translate.google.com/?sl=auto&tl=' + targetLang
+ '&text=' + selectedText;
The technical approach was simple precisely because the extension wasn’t doing any translation itself — it was a routing layer, passing content to external services. This kept the extension lightweight and meant it automatically benefited from improvements in the upstream translation services.
Later versions handled AltaVista Babel Fish’s URL format, Google Translate’s evolving API, and a handful of regional services including WorldLingo and SYSTRAN. Managing the service-specific URL templates was the primary maintenance burden.
The XUL context menu integration used the same extension points as ContextSearch — the nsIContextMenuListener interface and XUL overlay system. Technical documentation from this period is preserved on web.archive.org.
The Translation Landscape During TranslatePage’s Active Period
It’s worth understanding the quality of translation services TranslatePage was routing to, because it contextualizes both the extension’s value and its limitations.
AltaVista Babel Fish (1997–2012) was the first major consumer translation service, using SYSTRAN’s rule-based translation engine. Quality was mediocre but functional for getting the gist of a text. For languages with significant grammatical differences from English, output was often confusing.
Google Translate launched in 2006 using statistical machine translation — trained on large corpora of parallel text rather than linguistic rules. Quality improved meaningfully over Babel Fish, particularly for common language pairs (Spanish, French, German, Portuguese). TranslatePage added Google Translate support relatively quickly after its launch, and most users switched to it as their default service.
Neural machine translation (NMT) arrived around 2016–2017. Google’s transition to neural translation (September 2016) was a step change in quality — particularly for fluency and handling of idioms. DeepL launched in 2017 with a focus on European languages and quickly gained a reputation for superior output.
TranslatePage was built for the statistical MT era. By the time NMT systems produced genuinely good translation, the extension was approaching end-of-life.
Why It Was Discontinued
TranslatePage followed the standard Palancar extension trajectory: Firefox Quantum (version 57, November 2017) dropped XUL/XPCOM support, and the extension was not rewritten for the WebExtensions API.
The competitive landscape had also shifted significantly by 2017. Google Chrome had shipped with native, seamless translation since Chrome 6 (2010) — the browser automatically detected foreign-language pages and offered a translation bar without any extension required. This was architecturally superior to TranslatePage’s approach: the entire page translated in-place, preserving the page’s layout and design, rather than opening a new tab with Google Translate’s iframe wrapper around the original page.
Firefox was slower to implement native translation. It relied on a toolbar notification that routed to Google Translate’s page-framing approach until Firefox 118 (2023), when Firefox Translations became available for fully on-device translation.
By the time XUL extensions stopped working, the use case for a simple translation-routing extension was handled better by browser-native features or by the updated WebExtension alternatives that were appearing on addons.mozilla.org.
What Replaced It
Browser-native translation is the primary recommendation for most users today:
Firefox Translations (Firefox 118+, 2023): On-device, privacy-preserving translation for 20+ languages, built into Firefox without any extension. Translates the page in-place. Accessible via the translate icon in the address bar or the page action menu. No text is sent to external servers. See the Firefox Translations documentation.
Chrome’s built-in translation: Google Translate is deeply integrated — foreign-language pages trigger an automatic translation prompt. Translate via the address bar icon or right-click menu. Sends page content to Google’s servers.
Edge’s built-in translation: Microsoft Translator is integrated into Edge. The right-click context menu includes “Translate to [language]” directly.
Modern WebExtension alternatives for Firefox:
- Firefox Translations — the extension version of Firefox’s built-in translation for older Firefox versions
- To Google Translate — adds right-click translation using Google Translate, closely replicating TranslatePage’s behavior in the modern API
- DeepL Translate — right-click translation using DeepL, which many consider the highest-quality option for European language pairs
For text selection specifically, the To Google Translate extension provides the selected-text translation workflow that TranslatePage offered — highlight, right-click, translate.
If You’re Building Something Similar Today
A modern WebExtension replicating TranslatePage’s core behavior uses the contextMenus API and the tabs API:
// background.js
browser.contextMenus.create({
id: 'translate-selection',
title: 'Translate "%s"',
contexts: ['selection']
});
browser.contextMenus.create({
id: 'translate-page',
title: 'Translate This Page',
contexts: ['page', 'frame']
});
browser.contextMenus.onClicked.addListener(async (info, tab) => {
const targetLang = (await browser.storage.sync.get('targetLang')).targetLang || 'en';
if (info.menuItemId === 'translate-selection') {
const text = encodeURIComponent(info.selectionText);
browser.tabs.create({
url: `https://translate.google.com/?sl=auto&tl=${targetLang}&text=${text}`
});
}
if (info.menuItemId === 'translate-page') {
const pageURL = encodeURIComponent(tab.url);
browser.tabs.create({
url: `https://translate.google.com/translate?sl=auto&tl=${targetLang}&u=${pageURL}`
});
}
});
This requires contextMenus, tabs, and storage permissions. The full context menus API documentation is at developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/contextMenus.
For the in-place translation approach (which is more sophisticated than TranslatePage’s routing method), modern extensions use the DeepL API or Google Cloud Translation API via background script fetch calls, injecting the translated text back into the DOM via content scripts. The DeepL API offers a free tier suitable for low-volume extension use.
For fully on-device translation without external API calls, Bergamot (the engine powering Firefox Translations) is available as a JavaScript library via WebAssembly.
The Multilingual Web Before Browser Translation
TranslatePage was useful precisely because the web was becoming more multilingual while browser vendors hadn’t yet treated translation as a core feature. The assumption embedded in early browser design was that users read in their native language and content was either in that language or not for them. That assumption was wrong, and TranslatePage and extensions like it proved it.
The feature it pioneered — translation as a context menu action, accessible from anywhere on any page — is now a standard browser capability. That’s the measure of how right the concept was.
The original TranslatePage page at palancar.net is preserved at web.archive.org.