Localizing an Already-Localized Site

Many sites switching to Webflow's Localization will already have existing localized content as part of the original site.

You may have had a few service pages translated into Chinese, or half of your site might be in other locales.

But first, we need to ask a question...

Will Webflow's Localization Feature Benefit You?

There are really three main benefits to Webflow's localization;

1. The machine translation, which cuts out much of the translation work / time / cost
2. The ability to easily switch between different locales on the same page
3. The centralized content admin

So here's what you want to consider;

• If your site is already translated, and you don't have much new content planned in the future where the machine translation will benefit you, then #1 isn't very useful.
• If your different locales have significantly different page sets, e.g. you have pages in your German locale that do not exist in any other locale, then #2 doesn't apply fully throughout your site- the locale-switching doesn't make sense on those locale-specific pages of your site.
• > Also, navigation is somewhat more complex, since you have to accommodate variations in your nav in different locales.
• If your content admin is done through the Editor, then localization isn't helpful because there are no localization capabilities there [ 23-Dec-2023 ].
• > Also, if you have different teams managing each locale, then putting it all under one site may not benefit you. You'd need a team plan for them to be able to work concurrently in the designer.

What are the alternatives?

One option is to simply separate the sites. Clone the original site, give it a new domain name, and revise it to focus on that single domain. Hand-translate ( or use your own preferred machine translation service ) to convert new content you add.

From a costing standpoint, adding another CMS plan is about the same monthly cost as the advanced Localization plan.

There are some advantages to this approach;

• Each site can have a locale-specific domain or subdomain, like _mysite.de.
• Generally, less complexity, with the tradeoff being you have multiple sites to manage. If you make a styling or feature change, you now need to do it for multiple sites.
• Your content team can manage the localized content for each site through the Editor.
• Each site can vary as much as it needs to, with no impact on other sites
• You can still offer some form of cross site navigation between pages with some careful navigation planning. At a bare minimum, you'd indicate that there are other locales available, and take them to the homepage of a locale they choose.

How Localization Affects Your Site Structure

When you migrate that site to Webflow's localization, you will be restructuring all of your content to Webflow's localization pattern, which is;

• The full set of static pages and CMS items in your primary locale
• A localized variant of all of those pages under a locale path prefix like _/de/
• Every page on your site exists in every locale - your primary page, and then the localized variants of that page.

How Localization's "Page Sets" Work

For any number N of alternate locales, you will always have a set of 1:N pages. 1 primary locale page, and N alternate locale variants of that page.

For example, for a primary page like _/about, there would be corresponding localized pages like _/de/about, and _/jp/about.

Sygnal refers to this as a localized page set or "page set" for short, and these page sets follow specific rules;

• To my knowledge, page sets always follow the same path structure. If your primary page is at _{/menu/dinner/soup}, then your localized variants will follow that structure, with the locale path prefix, _{/it/menu/dinner/soup}. Even if you are using localized paths, the slugs would be localized but the path structure would remain the same, e.g. _{/it/menu/cena/zuppa}.
• Complete page sets will always exist for every page - even if the page is intended only for a specific locale.

Webflow's base Localization design appears to stick as closely to the rest of Webflow's path structure rules as possible for efficiency ( and sanity ).

With special programming, exceptions to these pathing rules can be implemented using a reverse proxy, See Sygnal Hyperflow's Fluid Paths service.

‍

High-Level Overview

Let's say you have a primary locale of English, and an alt of Japanese. In your original site you had two about pages, at _/about, and _/about-jp.

Here's how to migrate that.

• Setup localization, and the Japanese locale
• Auto translate your _/about page to Japanese, that new localized variante will be at e.g. _/jp/about
• Copy paste any additional or special content you want from your old _/about-jp page, into the new localized variant of _/about
• Setup a redirect for _/about-jp to _/jp/about, or whatever path your new localized version will be at.
• Draft _/about-jp, you no longer need it. You can delete it later once everything is tested and working as desired.

Overall this means that any localized content you already had needs to be relocated into the new localized path structure, and the old paths need to be redirected.

Special cases like specific-locale-only pages have to be handled specially.

How to Migrate Your Localized Site to Webflow's Localization

Migrating an already-localized site to Webflow localization can be a fairly substantial undertaking, since all of your localized pages and content may be relocated, and you need to protect your links and SEO.
If you're stressing out, Sygnal can help.

Here's the general process.

Planning Phase

Choose your primary locale, and your alternate locale(s).

Decide whether you need localized paths.

Decide whether you will be localizing your live site, or localizing a copy of your site and then swapping it over.

• Localizing the live site is efficient for quick, smaller projects, and can be necessary for complex live sites which have real-time data feeds.
• Localizing a clone is efficient for very large sites, provided that;
• > Your live site is not changing during the migration process
• > You have no inbound CMS changes occurring via automations
• > You have no API dependencies on the CMS that rely on CMS item ID's - these will all change in the clone

Mapping Phase

Create a map of all of the pages on your site, and identify the complete set of paths that describes the pages in your primary locale.

Then for each alternate locale, determine;

• Existing page paths that have alternate locale-only content
• The new Localization path for that page

This map will help you sort out what is moving where, and it will act as the reference for creating all of your redirects later.

It's also how you will identify any specific-locale-only pages and plan out how you want to handle these.

Preparation

Backup and clone your site. Keep that clone as a reference in case you need to revisit your original site design mid-process.

Localize & Migrate

Localize all of your content according to your map, page by page.

Generally this means;

• Using Webflow's built-in machine translation, which is excellent.
• Copy-pasting any content you want from any previously localized page you had
• Adding a redirect from the old page to the new one
• Drafting the old page

Problem Areas

Dealing with Locale-specific Pages

Let's say you have a certain page that you want ONLY in the primary locale, or ONLY in an alternate locale.

Webflow does not appear to support this natively. It will always require a primary-locale page, and will always create locale variants, even if you do not localize the content.

It will also automatically indicate to search engines that there are alternate locales for that page, in the alt hreflang links and in the sitemap.

None of that should really create an issue for you from an SEO perspective. However ideally you want to prevent user confusion, and a messy navigation.

The best approaches we've found are either;

• Custom code that detects the variant, and redirects if that variant is irrelevant.
• A reverse proxy, which works similarly but has the ability to return a 404 for the phantom pages in a page set. In this case, your sitemap and page-level hreflang links need to be handled by the reverse proxy as well.

Dealing with Locale-specific Page Layouts & Elements

Another common situation we find is that when a client has previously built multiple static pages that represent localized page variants, the content and layout can be substantially different from the primary locale version of the page.

Ideally, you'll be able to resolve this by abandoning those differences, and sticking with the page layout of the primary locale page, with your localized content fitting into that structure.

But what if your localized page has an important sidebar, that your primary-locale page doesn't...

Here are two fairly easy ways to approach this;

• Custom CSS which will hide or show elements depending on the current locale. Use the _:lang() pseudoselector along with custom attributes that you use to designate the locales you want these elements to show / hide in.
• If that's not enough, you can use custom code to detect the variant and vary the page directly.

Dealing with Locale-specific Code Differences

Here we begin entering into much grittier territory, but an example of this might be a site that shows a different stock market feed depending on the locale that the visitor is in.

Generally, building solutions here depends entirely on the needs of a specific project, but one thing to not is that Weblfow's HTML Embeds can be localized too.

That means if you drop an Embed on your primary page, you can change the content - including script - in your locale variants.

Beware, this quickly becomes confusing, and difficult to update and manage. Webflow does not have a view that lets you see what Embeds are overridden and in which locales. Plan and structure your site accordingly, and use this superpower wisely.

‍

‍