Tracking Translation Coverage with Fallback Telemetry

This guide belongs to Content Fallback & Routing and turns fallback decisions into a measurement: which untranslated content readers actually see, in which locales, and how often. It shows what to log, how to aggregate it into a traffic-weighted coverage report, and how translation teams can use that report to prioritize.

Most translation backlogs are prioritized by what exists: every untranslated entry is a line in a spreadsheet, sorted by date or by whoever asks loudest. That misses what matters to readers. A single untranslated page with heavy traffic in a market can matter more than a hundred rarely visited ones. The fallback layer already knows, on every request, which locale was requested and which was served. Logging that decision gives a precise picture of where the gaps are felt.

The Problem

A consumer app’s help centre was available in nine languages. The localization team translated articles in the order they were written, and after a large product release had a backlog of 140 articles per language. Support noticed that tickets in Portuguese and Korean spiked after the release, mostly about features whose help articles existed only in English. The five articles behind most of those tickets were near the end of the backlog, because they had been written last.

How Fallback Telemetry Works

Log each decision. When a page or block is resolved, emit one structured event with the requested locale, the served locale, the entry id, the content type and the level of fallback: page, block or field. Do this server-side, in the data layer, so every render is counted, including crawlers if you want them, which you can filter later.

Aggregate by traffic. Count fallback events per locale and entry per day. Because each event corresponds to a page view, the counts are directly traffic-weighted.

Enrich and rank. Join the counts with entry titles, content owners and how long the gap has existed, and rank by views over a recent window, for example the last 14 days.

Publish and trend. Give translation teams the ranked list and a trend chart per locale: the share of page views served as fallback. The trend shows whether coverage keeps up with new content.

Implementation

Emit the event where the fallback decision is made. The example writes JSON lines to the logger; any analytics pipeline that can count events works.

// lib/cms/fallback-telemetry.ts
type FallbackLevel = "none" | "field" | "block" | "page";

export function logResolution(e: { requested: string; served: string; entryId: string; contentType: string; level: FallbackLevel; fields?: number; path: string }) {
  if (e.level === "none") return; // count only gaps; totals come from normal page-view analytics
  console.info(JSON.stringify({ kind: "locale_fallback", ts: new Date().toISOString(), ...e }));
}

// In the data layer, after resolving:
// logResolution({ requested: locale, served: result.servedLocale, entryId: result.id, contentType: "helpArticle",
//                 level: result.isFallback ? "page" : result.fallbackFields > 0 ? "field" : "none",
//                 fields: result.fallbackFields, path });

Statically generated pages render once, not per view, so the event must come from the client instead: a tiny script sends a beacon on page load with the same fields, read from data attributes set at build time. Server-rendered and incrementally regenerated pages can log from the server, but note that cached renders are not re-executed; for those, the client beacon is also the more accurate source.

-- Daily aggregate: page-level fallback views per locale and entry over the last 14 days
SELECT requested AS locale,
       entry_id,
       count(*)            AS fallback_views,
       min(ts)             AS first_seen
FROM   locale_fallback_events
WHERE  level = 'page'
  AND  ts >= now() - interval '14 days'
  AND  NOT is_bot
GROUP  BY requested, entry_id
ORDER  BY fallback_views DESC
LIMIT  200;

Join the result with entry titles and owners from the CMS, add the fallback share per locale from total page views, and publish it where the translation team works: a dashboard, a weekly message or, best, as priorities in the translation management system itself.

Feeding the translation workflow

Many translation management systems accept priorities or due dates through an API. A weekly job can set the priority of each untranslated entry from its fallback views, so translators see the most visible gaps at the top of their queue without a separate report. Entries with no fallback views keep their normal priority and are translated as capacity allows.

Presenting the report

Keep the report short and actionable. For each locale, show the headline fallback share with its trend, then the top twenty untranslated entries by fallback views with title, content owner, days since the gap appeared and a direct link to the entry in the CMS. Separate new gaps, which appeared in the last week, from long-standing ones, since new gaps usually come from a release and deserve a quick response. Add a short section of entries whose translation was published during the week, with their fallback views before publication, so the team sees the effect of its work. A report that fits on one screen gets read; a spreadsheet of every untranslated entry does not.

Configuration Reference

Gotchas & Edge Cases

• Double counting. Logging both on the server and via a client beacon counts views twice. Choose one source per rendering mode.
• Field-level noise. Many pages have one or two fallback fields, such as untranslated image captions. Report field-level gaps separately so they do not drown page-level gaps.
• Personal data. Fallback events need no user identifiers. Keep them anonymous and aggregate early.
• Intentional fallbacks. Some content is deliberately not translated, such as English-only developer references. Mark those types so they are excluded from the report and the headline metric.

Worked Example

The consumer app added fallback events to its help centre renderer and a weekly ranked report per language, and pushed priorities into its translation management system. After the next release, the Portuguese fallback share rose to 29 percent; the report showed five articles responsible for 60 percent of fallback views, and translators handled them first. Within three weeks the share returned below its pre-release level, and Portuguese support tickets about the new features dropped back to normal, well before the rest of the backlog was translated.

Using the Metric Beyond Prioritization

The fallback share per locale is also a useful health metric for the localization programme as a whole. Chart it monthly next to content output: if the share rises steadily, translation capacity is not keeping up with publishing, and the conversation is about budget or scope, not about individual articles. Set targets per locale based on market importance, for example below five percent for primary markets and below twenty for emerging ones, and review them with market owners. The same data also informs product decisions: a locale where most readers see fallback content may not be ready for marketing campaigns that drive traffic to it. And a sudden jump without new content usually signals a technical fault, such as a broken translation sync or a chain misconfiguration, which makes the metric a useful alert for engineering too.

Rollout Checklist

• Emit a fallback event wherever the data layer resolves locales.
• Use client beacons for static and cached pages, server logs otherwise.
• Aggregate daily, excluding bots and intentional fallbacks.
• Rank untranslated entries by recent fallback views per locale.
• Push priorities into the translation management system.
• Track fallback share per locale against targets.

Frequently Asked Questions

Related

• Content Fallback & Routing
• Configuring Locale Fallback Chains in Headless CMS Queries
• Measuring Preview Latency for Editors