The Problem Nobody Plans For

Most multilingual website projects focus heavily on the launch: getting the translations done, getting the language switcher working, getting the site live. The question that gets insufficient attention is what happens the week after launch — and the month after, and the year after.

A multilingual site creates an ongoing editorial commitment. Every time content on the primary language version changes — a programme description updated, a staff member replaced on the team page, a policy document revised — the translated versions need to reflect that change too. If they don't, you develop what's called content drift: the translated versions gradually diverge from the primary language version, becoming inaccurate, outdated, or misleading.

For a nonprofit, content drift in translated versions is not just an embarrassment. A French-speaking beneficiary reading programme eligibility criteria that no longer reflect your current offer is being misinformed. A funder conducting due diligence who finds contradictory information across language versions is encountering a governance gap. Outdated translated content undermines the trust the translation was supposed to build.

The solution isn't technical. It's a governance decision made before the site launches: who owns the translated content, and what process exists to keep it in sync?

Establishing Translation Ownership

Before any translated content goes live, assign clear ownership for each language. This means a named person — not a team, not "the comms team," a named individual — who is responsible for reviewing and approving translated content in that language.

In practice, this person is usually a bilingual staff member, a volunteer with relevant language skills, or an external translator on retainer. For organisations without an obvious internal candidate, it's worth establishing a relationship with a professional translator before launch rather than discovering the gap when translated content needs urgent correction.

The translation owner's responsibilities are:

• Reviewing AI-generated or machine translations before they go live on the site
• Correcting terminology, tone, and sector-specific language that automated translation handles poorly
• Being notified when primary language content changes so translated content can be updated accordingly
• Signing off translated content before it is marked as reviewed or promoted

If no one in your organisation can fulfil this role for a given language, that's important information. A language version with no human reviewer is a governance risk — automated translation errors will go undetected and remain live indefinitely. It may be better to launch with fewer languages, each properly maintained, than to add languages that will drift.

Building the Update Trigger Into Your Content Process

Content drift happens because the translation update step isn't built into the process for updating primary language content. When a Communications Manager edits the French programme page description in Webflow, they're focused on getting the English version right — the French translation isn't top of mind.

The fix is structural: the translation update must be a step in the content update process, not an afterthought.

For organisations using Weglot:

When primary language content changes on the Webflow site and the site is republished, Weglot detects new or changed text and flags it in the dashboard as untranslated or needing review. The translation owner receives a notification (if notifications are configured in Weglot) and can update the translation directly in the Weglot dashboard without needing Webflow access.

Build this into your content update process explicitly: after publishing any change to core pages, the person who made the change notifies the translation owner. A simple shared document or a Slack message — "Updated the Children's Services page — French and Spanish need reviewing" — is sufficient for small teams.

For organisations using Webflow native localisation:

When content changes in the primary locale, the corresponding content in secondary locales needs to be updated manually in the Webflow Designer. This requires someone with Designer access to switch to each locale and update the content. For content managed through the CMS, Webflow flags which CMS items have content that differs between locales.

This is more demanding than Weglot's approach — it requires Designer access for every content update across every locale. For organisations with active content programmes and non-technical teams, this is one practical reason to prefer Weglot over Webflow native localisation.

What Requires Translation and What Doesn't

Not all content on a nonprofit website warrants the same translation effort. A sustainable multilingual workflow distinguishes between content tiers.

Tier 1 — Always translated and kept in sync:

• Homepage
• Navigation labels
• Programme and service pages
• About the organisation
• Contact page
• Privacy policy and cookie policy
• Any page linked directly from communications targeting the translated language audience

These are the pages a French-speaking beneficiary or donor is most likely to visit. They carry the highest stakes if content is outdated or incorrect. When any of these pages change in the primary language, the translation update should happen within a defined timeframe — typically within one week for material changes.

Tier 2 — Translated at launch, updated when significantly revised:

• Team pages
• Governance and transparency documents
• FAQs
• General resources

These pages change less frequently and the risk of outdated content is lower. A team page where a staff member's job title has changed is a minor inaccuracy. A safeguarding policy that references an outdated procedure is not. Apply judgement about which updates in this tier are material enough to warrant immediate translation.

Tier 3 — English only, or translated selectively:

• Blog posts and news articles
• Case studies and impact stories
• Event listings

For most nonprofits, translating an active blog into multiple languages is prohibitively expensive and editorially demanding. The more practical approach is to keep blog content in the primary language and display a note on the translated version explaining that editorial content is available in English only. This is honest and manageable, and most multilingual visitors to nonprofit sites understand it.

If a specific blog post or news item is particularly relevant to a language audience — an announcement of a French-language programme, a case study featuring a French-speaking community — translate that post individually rather than translating everything.

Handling Content That's Difficult to Translate

Some content on nonprofit websites poses particular challenges for translation that are worth addressing explicitly in your workflow.

Safeguarding and legal language. Your safeguarding policy, privacy policy, terms of use, and any legally significant content must be reviewed by someone with appropriate expertise — not just language fluency, but understanding of the relevant legal or sector context in the target language's jurisdiction. A French translation of a UK safeguarding policy needs to be read by someone who understands both the English source and the French-language regulatory context. Machine translation of legal language is particularly unreliable.

Impact data and statistics. Numbers, percentages, and outcome data don't need translating — but their context does. Ensure that units, date formats, and references are appropriate for the target language audience. A statistic about "2,000 beneficiaries supported annually" reads clearly in English; in translation, confirm the surrounding context makes the figure meaningful to the target audience.

Programme names and organisational terminology. Proper nouns — programme names, organisational values statements, brand terminology — are often better left in the original language or handled with a translator's note rather than translated directly. Automated translation tools will attempt to translate these and often produce poor results. Create a glossary of terms that should not be translated and share it with your translation owner and any external translators you use.

A Simple Governance Framework

For most nonprofits, a lightweight governance framework is more useful than a complex translation management system. The following structure works for organisations with one or two translated languages and a small communications team. It's the approach I walk clients through during handover — simple enough to actually stick.

Before launch:

• Name a translation owner for each language
• Define which pages are Tier 1, Tier 2, and Tier 3
• Review all Tier 1 translations before the translated version is publicly promoted
• Create a short glossary of terms not to translate

Ongoing:

• Any change to a Tier 1 page in the primary language triggers a notification to the translation owner
• Translation owner reviews and updates within one week
• Tier 2 pages reviewed quarterly as part of a content audit
• Tier 3 content stays in primary language unless specific posts warrant individual translation

Annually:

• Full review of all translated content against current primary language versions
• Reassess which languages are actively maintained and which have drifted — it may be better to remove a language version than to leave an outdated one live
• Update the glossary as terminology evolves

This framework doesn't require dedicated software or a significant time commitment. It requires clear ownership and a habit of including the translation update step in the content management process — which is entirely within reach for a Communications Director managing a site with one or two translated languages.

When to Remove a Language Version

If a translated language version has drifted significantly — if the translation owner has left and hasn't been replaced, if core pages haven't been updated in over a year, if the translations contain known errors that nobody has corrected — consider removing the language version rather than leaving it live in a degraded state.

An absent or inaccurate translation can cause more harm than no translation at all: a French-speaking beneficiary who reads incorrect programme eligibility criteria may be discouraged from applying, or may apply based on outdated information. Removing the language version and replacing it with a note — "We're working on a French translation — contact us for information in French" with a direct email address — is more honest and more useful than maintaining a translation that can't be trusted.

Further Reading

• Multilingual Nonprofit Websites: Webflow Native, Weglot, or Google Translate?
• How to Set Up Weglot on a Webflow Nonprofit Website
• How Socialectric Manages Nonprofit Website Projects from Start to End