Turning on multilingual support in SharePoint is a single toggle. Building a SharePoint intranet that actually works properly in two languages is a completely different undertaking.
The toggle enables the translation workflow — it creates the /fr/ folder structure, activates the translator notification system, and links language versions of pages together. What it doesn't do is handle the rest of your information architecture. Navigation, taxonomy, folder names, search, breadcrumbs, web part titles — none of that comes with the toggle. Each layer needs to be thought through separately.
This post walks through the full IA picture for a bilingual SharePoint intranet, what's handled automatically, what needs manual work, and where there are genuine gaps in the product that require custom solutions.
Start Where You Always Start — Content Types and Site Columns
The good news is that content types and site columns are largely language-neutral. You define them once. The internal names are language-neutral identifiers. The display names can be set per language.
The key decisions at this layer:
Choice columns vs managed metadata
If you use a Choice column for values that users will see — document status, content category, audience — those values display in the language they were created in. A Choice column value of "Policy" shows as "Policy" to French users unless you duplicate the column (a TitleFR/DescriptionFR pattern) or replace Choice columns with managed metadata columns pointing to the Term Store, where translations are built in.
For a genuinely bilingual environment, managed metadata columns connected to the Term Store are the right answer for any values that need to display in the user's language.
Duplicate columns for content
For page content fields — title, description, body content — the standard pattern is duplicate columns: Title and TitleFR, Description and DescriptionFR. The English web parts use Title and Description. The French web parts use TitleFR and DescriptionFR. Simple, explicit, and maintainable.
Term Store — Every Term Needs a Translation
The Term Store is one of the most important layers in a multilingual IA and one of the most frequently overlooked until it's too late.
Each term in the Term Store can have a label for each language. When a user views content in French, managed metadata columns display the French label for the term automatically. Without those translations, French users see English term values regardless of the page language.
For an intranet with a meaningful taxonomy — directorates, topics, content types, audiences — this means every term needs a French equivalent. For a large taxonomy that can be hundreds of translations. The practical approach is to build the English taxonomy first, export to CSV, add the French translations, and import back using PnP PowerShell.
The Term Store also needs translation at the term set and term group level — the labels that appear in the managed metadata panel when a user is tagging content.
Navigation — Two Separate Layers, Neither Automatic
Megamenu navigation is one of the most visible parts of any intranet and one of the areas where multilingual support requires the most manual work.
SharePoint's Language Settings allow you to add translations for navigation nodes — but this is a manual process for each node. Every top-level item and every second-level item needs a French equivalent entered manually. The structure mirrors the English navigation exactly; only the display text changes.
The two starting points:
If you're building the navigation from scratch in a bilingual environment, creating both language versions from the beginning is cleaner than building in English first and translating later. PnP PowerShell can create navigation nodes with translations in a single operation.
If you're starting from an existing English navigation and adding French translations, the approach is different — you update each existing node with its French label rather than recreating the structure.
Both approaches are documented with scripts:
- Create Bilingual Navigation — building navigation nodes with EN and FR from the start
- Add Navigation Translations — adding French translations to an existing English navigation structure
The megamenu itself — the layout, the column structure, the featured links — is configured once and shared across languages. Only the node labels differ.
Folders — The Gap in the Product
This is the most interesting part of the multilingual IA picture because it exposes a genuine limitation in SharePoint's translation framework.
SharePoint's multilingual pages feature creates language-specific subfolders within the Site Pages library. English pages live in the root or in content folders. French translation pages are created in /fr/ subfolders within those same folders. So if you have:
/SitePages/HR/OnboardingGuide.aspx
The French translation lives at:
/SitePages/HR/fr/OnboardingGuide.aspx
This folder structure is automatic and works well for organising translation pages. The problem is the folder names themselves. The /HR/ folder in the example above is a structural container — it's not a content page, it doesn't have a translation page by default, although you can create a page with the same name as the folder if your navigation or breadcrumb requires a landing page at that level. That page can then be translated in the normal way. For folder name display purposes however, that still doesn't solve the breadcrumb problem.
The folder name problem
If you're using folders for content organisation — and on a structured intranet with hundreds of pages you almost certainly are — those folder names appear in breadcrumb navigation. A French user navigating a page sees the English folder name in their breadcrumb because the folder has no French equivalent.
The custom solution
A dedicated SharePoint list with columns for the English folder name, the French folder name, and the folder path. A custom SPFx breadcrumb web part reads from this list and displays the correct language folder label based on the current page context — French UI shows French folder names, English UI shows English.
The list is simple to maintain — when a new folder is created, a new list item is added with both language values. The SPFx web part handles the rest.
The SPFx breadcrumb web part that implements this pattern is available here: SPFx Multilingual Breadcrumb (coming soon)
Search — Managed Properties and Slot Mapping
Search in a multilingual intranet needs careful planning. By default, SharePoint search indexes content and returns results regardless of language. For an intranet where English and French content coexist, unfiltered search returns a mix of both languages to all users.
The solution is managed properties mapped to your duplicate content columns, e.g.:
- TitleFR → RefinableString105
- DescriptionFR → RefinableString106
PnP Modern Search can help refine the multilingual search results. Here is an important article on modern search.
PnP Modern Search result cards then use slot mapping to display the correct language version of content based on which web part is on which page. The English homepage web part uses the Title and Description slots. The French homepage web part maps the same Title slot to RefinableString105 and Description to RefinableString106.
The result: the same underlying content, presented in the correct language on each page, driven entirely by slot configuration rather than duplicate web parts or conditional logic in the template.
The message banner solution documented on this site is a working example of exactly this pattern — two web parts, one list, bilingual content served correctly to each homepage.
Web Parts and Tools — Outside the Translation Framework
Several parts of the SharePoint UI sit completely outside the multilingual translation framework and need to be handled separately.
Web part titles are not translated by the multilingual feature. A web part titled "Latest News" on the English page shows "Latest News" on the French page unless you manually update the title on the French page version.
Tools and quick links — if you have a tools section or quick links navigation that shows application names, those names need French equivalents stored somewhere. A SharePoint list with EN and FR columns for each tool name and URL is the standard approach.
The Customisable Tools Menu SPFx web part on this site is built with multilingual in mind — it reads tool names and URLs from a SharePoint list with separate EN and FR columns, displaying the correct language version based on the current page context.
What the Translation Framework Handles Automatically
To be fair to the product — once properly configured, the translation framework handles a significant amount:
- Page content translation workflow — translator notifications, translation status tracking
- Language-specific URL structure — /fr/ subfolder creation
- Language toggle for users — switching between page versions
- Page-level translation status — out of date warnings
- News post translations — same workflow as pages
- Site name and site description — translated in Language Settings
The Things People Forget
A few areas that catch teams out late in the project:
Power Automate email notifications — if your intranet has approval flows or notification flows, the emails those flows send are typically in one language. Building bilingual email templates is an additional scope item that's easy to miss.
PDF documents — any PDFs linked from intranet pages are completely outside the translation framework. A French user clicking a policy link that returns an English PDF is a common frustration on bilingual intranets.
Image alt text — not covered by the translation workflow. Alt text needs to be set separately on each language version of a page.
Content owner training — arguably the most important item. The translation framework creates the structure and the workflow. Whether the French content actually gets translated, maintained, and kept up to date depends entirely on whether content owners understand their responsibilities and have the time to fulfil them. A governance document that defines the translator role, the review cadence, and what happens when content falls out of date is as important as any technical configuration.
Scripts for Multilingual SharePoint
The following PnP PowerShell scripts cover the most common multilingual setup tasks:
- Add Navigation Translations — add French translations to existing English navigation nodes
- Create Bilingual Navigation — create navigation nodes with EN and FR labels from the start
- Create Translations of Pages in a Folder — bulk trigger translation page creation for pages within a folder
Need help planning or building a bilingual SharePoint intranet? Get in touch and we'll work through the IA together.