Breadcrumbs are one of those pieces of interface people barely notice when they're working, and immediately miss when they're not. That thin line of text exists for one purpose: telling someone where they are, and giving them a fast way back to where they came from.
On a large intranet, that matters more than it looks like it should. Content gets organised into folders, folders get nested inside other folders, and a staff member who arrived at a page through a search result, a shared link, or a Teams message has no other way of knowing where in the site they've landed. Without a breadcrumb, the only way back is the browser's back button, which breaks the moment someone opens a link in a new tab, which is most of the time.
We use a controlled folder structure across the intranet specifically so this kind of orientation is possible, sections and subsections that mirror how the organisation actually thinks about its own content. But that structure created a problem the moment the site needed to serve both English and French speakers equally well.
The problem: a folder name only ever exists in one language
A page's title translates. SharePoint's own multilingual pages feature handles that natively, create a page, translate it, and both versions carry their own correctly localised title.
A folder's name doesn't. Whatever a folder was called when it was created is what it's permanently called, in the URL and everywhere else, regardless of which language a visitor is reading the page in. A French-speaking employee browsing a page inside the Policies folder would, without any extra work on our part, see "Policies" sitting right there in their breadcrumb, in English, on an otherwise fully French page. Small, but exactly the kind of small inconsistency that makes a site feel unfinished.
How it works, in plain terms
The breadcrumb itself lives inside the site's header, the same web part responsible for the branded background, search box, and site name. A breadcrumb needs to know what page it's on and where that page sits in the folder structure, and the header already carries that context for other reasons. Building the breadcrumb as part of it meant not duplicating that logic somewhere else.
What a visitor actually sees is two levels: the folder the current page lives in, shown as a clickable link, and the current page itself, shown as plain text next to it. Click the folder name, and you're taken to a proper landing page for that section.
The current page's part of the breadcrumb takes care of itself. Since pages are already translated natively, the breadcrumb simply reads whatever title the page itself already has, in whichever language a visitor is viewing it. No extra setup required, translate the page the normal way, and its breadcrumb label is automatically correct.
The folder's part needed a different answer, since there's no equivalent mechanism to lean on. We built a small SharePoint list that maps each folder to its English and French display names, along with the correct English and French landing pages that folder's breadcrumb link should point to. When a visitor is viewing the site in French, the breadcrumb reads from the French columns. Otherwise, it reads from the English ones. The technical detail of exactly how that language switch happens, and how the list is structured, is covered in the full technical write-up, for anyone who wants the mechanics rather than the summary.
Keeping it accurate
A feature like this is easy to demo and, if left alone, quietly hard to maintain. Every folder that's supposed to show up as a proper, translated, clickable breadcrumb destination depends on three things existing together: an English landing page, a French landing page, and an entry in that list connecting them. Nothing about creating a new folder in SharePoint prompts anyone to do any of that. Left alone, new sections would accumulate over time with breadcrumbs quietly falling back to an untranslated folder name, or a link into a plain file listing instead of real content.
Rather than rely on anyone remembering a manual step, we built two small automated flows around the list itself.
The first fires the moment a new folder is created. It works out, automatically, exactly where that folder's English and French landing pages are expected to live, based on the same consistent structure the rest of the site already follows, and emails the person who created the folder with exactly what's needed: build these two pages, at these exact addresses. At the same time, it adds a placeholder entry to the list, so the gap is visible in our own governance data immediately, rather than only becoming obvious if a visitor happens to notice a broken URL.
The second runs quietly in the background every day, checking any placeholder entries against reality. The moment a page actually appears where it was predicted to, the entry is automatically marked complete, no one needs to go back and manually update the list themselves. If something sits unfinished for too long, a second reminder goes out, rather than the gap just sitting there indefinitely, unnoticed.
Between the two, the only thing a content owner actually has to do by hand is build the page. Everything else, the record-keeping, the reminders, the eventual sign-off, happens on its own. The fuller detail of how those two flows are built is in the second technical piece, for anyone maintaining something similar and wanting the actual flow design rather than the overview.
Why this was worth the extra step
It would have been simpler to skip the automation and just ask people nicely to remember. But "ask people to remember" is exactly the kind of governance approach that works for the first few weeks and quietly stops working the moment the person who built the feature moves on to something else, or the person creating folders six months from now was never told the process existed in the first place.
Breadcrumbs are a small piece of the site. But a small piece that's wrong on some pages and right on others is worse for trust in the whole intranet than not having the feature at all. Building the reminder and the safety net alongside the feature itself, rather than after something had already gone quietly wrong, was the point.