Showing Fallback Language Notices to Readers

This guide, part of Content Fallback & Routing, covers the reader-facing side of fallback: what to show when someone opens a page in their language and gets content in another. It covers when a notice is needed, how to word and place it, which HTML attributes make fallback content accessible, and how the same information helps editors in preview.

Serving fallback content silently saves the reader a 404 but costs them trust. They followed a link labelled in their language, and the page switched language without explanation; some will assume the site is broken, others that the language switcher does not work. A short notice in their own language, explaining that the page is not yet translated and offering alternatives, turns the same situation into a small, understandable gap.

The notice scales with the size of the gap.

The Problem

A public sector website served six languages, with English as the fallback for untranslated pages. User research found that readers of the Spanish version, arriving from search results with Spanish titles, often left English pages within seconds, and several participants said they thought the site had “switched to English by mistake”. Screen reader users had a worse experience: because the page declared lang="es", their screen readers read English text with Spanish pronunciation rules, which made it nearly unintelligible.

How Fallback Signalling Works

A page-level notice when the whole page falls back. One short sentence in the requested language says the page is not available in that language and names the language shown. Links offer the page in other available languages and, if useful, a way to request a translation or to go to the section’s translated overview.

Correct lang attributes. The <html> element keeps the requested locale, since navigation, header and footer are translated; the main content container gets lang set to the served language. For block-level fallback, each fallen-back block gets its own lang. This is what makes screen readers, hyphenation, spell checkers and browser translation behave correctly.

No notice for small gaps. A page where one caption fell back does not need a banner. The lang attribute is enough, and a banner would draw more attention to the gap than it deserves.

The notice itself is localized content. Its wording lives in the site’s translation strings for each locale, reviewed like any other text.

Everything the reader relies on to navigate stays in their language.

Implementation

The data layer returns the served locale, as in the fallback chain guide. The page renders the notice and sets attributes accordingly.

// components/fallback-notice.tsx
import { t } from "@/lib/i18n";

const LANGUAGE_NAMES = (inLocale: string) => new Intl.DisplayNames([inLocale], { type: "language" });

export function FallbackNotice({ requested, served, available, path }: { requested: string; served: string; available: string[]; path: string }) {
  if (requested === served) return null;
  const names = LANGUAGE_NAMES(requested);
  return (
    <aside className="fallback-notice" role="note" lang={requested}>
      <p>{t(requested, "fallback.notice", { language: names.of(served) ?? served })}</p>
      {available.length > 0 && (
        <p>
          {t(requested, "fallback.available")}{" "}
          {available.map((loc, i) => (
            <span key={loc}>
              {i > 0 && ", "}
              <a href={`/${loc}${path}`} hrefLang={loc} lang={loc}>{new Intl.DisplayNames([loc], { type: "language" }).of(loc)}</a>
            </span>
          ))}
        </p>
      )}
    </aside>
  );
}

// app/[locale]/[...slug]/page.tsx (excerpt)
const result = await getLocalizedPage(slug, locale);
if (!result) notFound();

return (
  <>
    <FallbackNotice requested={locale} served={result.servedLocale} available={result.availableLocales} path={path} />
    <main lang={result.servedLocale}>
      <Article page={result.page} />
    </main>
  </>
);

Intl.DisplayNames names each language in the reader’s language for the notice and in its own language for the links, which is the convention readers expect in language lists: “Español”, “Deutsch”, “日本語”. The translation strings are short, for example "fallback.notice": "Esta página aún no está disponible en español. Se muestra en {language}.".

Block-level fallback

When the data layer resolves fallbacks per block, it returns the served locale for each block. A wrapper sets lang on the block element only when it differs from the page’s locale. In draft mode, the same wrapper adds a visible outline and a small label, so translators reviewing a preview see exactly which blocks still need work.

// components/localized-block.tsx
export function LocalizedBlock({ servedLocale, pageLocale, draft, children }: { servedLocale: string; pageLocale: string; draft: boolean; children: React.ReactNode }) {
  const isFallback = servedLocale !== pageLocale;
  return (
    <div lang={isFallback ? servedLocale : undefined} className={draft && isFallback ? "block--fallback-preview" : undefined} data-fallback={isFallback ? servedLocale : undefined}>
      {draft && isFallback && <span className="fallback-label">{servedLocale} (fallback)</span>}
      {children}
    </div>
  );
}

Measuring whether notices help

Treat the notice as a feature and measure it. Record when a notice is shown and which of its links readers use, and compare engagement on fallback pages with and without notices, for example during a staged rollout by locale. Useful signals are bounce rate, time on page, clicks on the available-language links and support contacts that mention language. If readers rarely use the links, the alternatives offered may not be useful; if they leave immediately, the wording may be unclear or the fallback language may simply be unhelpful in that market, which argues for translating the most visited pages first or for a 404 with good navigation instead of a fallback.

Configuration Reference

Situation	Signal	Where
Whole page from fallback locale	localized notice plus `lang` on main content	Top of main content.
Some blocks from fallback	`lang` on those blocks	Block wrapper.
Single fields such as captions	`lang` on the element	Field wrapper, no notice.
Draft mode	outline and label on fallback parts	Preview only.
Language list	names in their own language, `hreflang` on links	Notice and switcher.

Gotchas & Edge Cases

Notices in the wrong language. The notice must be in the requested language, not the served one. A notice in English on an English fallback page, for a Spanish reader, defeats the purpose.
Caching notices. The notice depends on the served locale, which is part of the cached page, so caching is safe; purge the page when the translation is published, or the notice lingers after the gap is closed.
Right-to-left mixes. An English fallback block on an Arabic page needs dir="ltr" as well as lang. Set dir from the served locale.
Search snippets. Search engines may show the notice text as the snippet. Keep it short and mark the page as a fallback in SEO tags, as described in canonicalizing fallback pages.

Worked Example

The public sector site added page-level notices in all six languages, lang on the main content and on fallback blocks, and language links in the notice. In the next round of user research, Spanish-speaking participants understood what had happened on fallback pages, and several used the notice’s link to reach the Spanish overview of the same section. Screen reader users heard English content pronounced correctly. Analytics showed that the bounce rate on fallback pages for Spanish visitors fell substantially after the change.

The content did not change; only the explanation and markup did.

Writing Good Notices

The notice is a piece of microcopy, and its wording matters more than its design. State the fact plainly, in the reader’s language: the page is not available in that language yet, and it is shown in another one. Avoid apologies that take up space and blame nobody useful. Name the served language explicitly, because readers who do not speak it may not recognize it at a glance. Offer one or two useful actions, such as the list of available languages or a link to a translated overview of the section. Keep it to one or two lines, visually distinct but not alarming; a warning colour suggests an error, when this is a normal and expected state. Test the wording with native speakers of each locale, since a literal translation of an English notice often sounds stiff or even rude in other languages.

Rollout Checklist

Return the served locale for pages and blocks from the data layer.
Show a localized notice only when the whole page falls back.
Set lang, and dir where needed, on fallback content, not on the whole document.
List available languages by their own names with hreflang on links.
Highlight fallback parts in draft mode for translators.
Purge fallback pages when their translation is published.

Frequently Asked Questions

Should the notice offer machine translation?

It can offer a link to the browser’s translation, which readers control. Auto-inserting machine translations raises quality and liability questions that should be decided by the content owners.

Should the page title be in the fallback language?

The title comes from the content, so it is in the served language. Keep the site name in the requested language, since it is part of the translated chrome.

Do notices hurt SEO?

No, as long as fallback pages are handled with canonical or noindex tags. The notice itself is ordinary content.

Should the notice be dismissible?

It can be, remembered per session, but keep it short enough that dismissing is rarely needed. It must reappear on other fallback pages, since each one is a separate gap the reader has not yet seen explained.

Where should notice strings live?

With the other interface strings in the translation system, not in the CMS content, so every locale has a reviewed notice from day one.