Localizing the SmartBlock Embed Header

Moving the SmartBlock embed content header string out of hardcoded English into Fluent so non-English Firefox builds get the localized version.

Bug 2026331 | D295198 | Reviewers: manuel, fluent-reviewers, webcompat-reviewers, twisniewski, flod

The Problem

The embed link preservation work I shipped earlier (Bug 1976290) injects a header above the preserved content that says something like “Original embed content.” That string was hardcoded English in the helper file. Firefox ships in 100+ locales. None of them were getting their language for that header.

This is the unglamorous side of front-end work in a browser. You build a feature, ship it, and then realize you’ve quietly built something that only works for English speakers. Fluent (Mozilla’s localization framework) exists exactly for this, but you have to remember to use it.

The Fix

Two changes:

  1. Add the string to the relevant .ftl file in the SmartBlock locale directory, so translators can pick it up on the next translation cycle.
  2. Replace the hardcoded English in smartblock_embeds_helper.js with a call into the Fluent system that resolves to whatever locale the browser is running in.

The number of reviewers on this patch (manuel, fluent-reviewers, webcompat-reviewers, twisniewski, flod) reflects how many ownership areas a one-string change can touch in mozilla-central:

  • manuel for SmartBlock module ownership
  • fluent-reviewers because new strings need a Fluent reviewer to confirm naming and ID conventions
  • webcompat-reviewers, twisniewski because the helper file lives in the webcompat extension
  • flod for the localization platform itself

I’ve come to think of multi-reviewer patches as the cost of the codebase being correctly modular. Each of these reviewers cares about a different invariant, and the patch has to satisfy all of them.

What I Learned

  1. “It works in English” is not a real done state at Mozilla. A feature that only works for English speakers is a feature that’s broken for the other ~60% of the user base.

  2. Fluent’s review process is short but real. The Fluent reviewers are checking that string IDs follow conventions, that there’s no English-specific phrasing baked in (e.g. assuming a particular word order), and that the message structure supports the kinds of things translators need (plurals, gender, variable interpolation). It’s worth running the patch by them early rather than late.

  3. String IDs are a public contract. Once you ship a Fluent ID, you can’t easily rename it without breaking translations in flight. Naming the ID is a small decision that has long tail consequences.