Localization - How-to set up different static pages for each locale

Design help Localization
1

Hey Webflow Community

I’m Esben from the Danish company Famly.
We recently bought the “Advanced” localization package but are seeing some problems with how it works when you have a different URL structure for your website in each of the locales.

Below is some context on our setup.
We are using UK English as our Primary Locale as our website has the most pages in UK English as it’s our biggest market for the software we make.

Locale setup looks like this:

Famly Locale setup WF
Famly Locale setup WF1021×525 39.5 KB

The way we had our website before Localization was kind of a home-made setup in terms of URL structure, meaning that all UK pages would be set up like this:

www.famly.co/demo

… and the US version of that page would sit in the same instance under Pages with the URL being:

Get a demo | Discover the Top-Rated Childcare Software.

The pages where not sitting in a subdirectory.
(we did this because of limitations within the Webflow platform, but it hasn’t been good for SEO).

Every Technical SEO person knows, that the US page should sit in a subdirectory like this:

www.famly.co/en-us/demo. (goood for SEO).

The URL setup seem to work fine when looking through the locale setup.
Here is the above example:

US Demo Page - URL Setup
US Demo Page - URL Setup1022×1161 131 KB

But we have gotten all the static pages dublipacted onto each of the locales, why is Webflow doing that automatically?

I’ll try and list the problems in order:

First of all, all of the pages from our UK locale, have been copied to the US, German and Danish Locales.

We don’t want a carbon copy of all our UK pages on these locales, as we don’t have the same amount of pages in each of these markets.

In the Danish locale we for example only have 14 pages.

We don’t want a copy of all 134 UK pages (plus all the CMS content), as our Danish version of the software is limited. And in the other locales the product varies so we need a custom page setup for each locale.

Then we thought it might just be possible to delete the pages under each of the locales and only keep the pages we need for each of the locales under US, Germany and Denmark.

But it seems that the delete button is not to there under the locale pages:

Famly - no delete button under locale
Famly - no delete button under locale1920×1084 135 KB

I can’t find anything about this custom setup we want in the Localization documentation…?
https://university.webflow.com/lesson/localization-overview?topics=localization

So the question really is:
Is it possible to have a custom setup with a different number of pages under each locale?
…or do we have to have a carbon copy of each of the UK pages for each locale?

I know it’s possible via CMS Collections, but it would require soo much work moving 95% of our pages to all be CMS Collections and we would like to avoid that…

I’m eager to hear your feedback.

2

Webflow Localization works like this-

  • You have a main website, which is build in a single primary locale
  • You have additional locales, which function as a clone of every page on the site, with localized content

Your original site has multiple locales so your migration process would be something like this;

  • Setup Localization, add your locales e.g. en-US
  • Localize your content, as desired. Your /demo page would now have UK english as the primary, and e.g. /en-us/demo as the localized version. Customize that localized version as needed using the content from your /en-demo original page ( now deprecated ).
  • Draft your old /en-demo page, it’s no longer part of your main site, and that content has been moved into your localized page. You can delete it later, for now, you’re just taking it offline.
  • Add a redirect from /en-demo to your new page e.g. /en-us/demo

I haven’t used the custom paths feature but I don’t think it’s possible to create a locale custom path like /en-demo for a locale, it would always have to have the locale indicator, e.g. /en-us/en-demo. Otherwise, there’s possible overlap between paths and Webflow wouldn’t know which one you want served.

For users and SEO, that redirect solves the issue. You might not need localized paths at all unless you have other languages and want the paths to use localized keywords.

You’ll still get all of the pages, but you don’t have to translate them. e.g. /about/ would get /en-us/about, but it doesn’t need to be different. Webflow appears to use that /en-us as its locale context for all the navigation, rather than using a language cookie and jumping your around to a “best match locale” decision on every request. In some ways that’s better, it’s more predictable and no redirects needed.

It really doesn’t make a difference to speak of, particularly as the alt hreflang links are in place, search engines will see them all as variations of the same page.

3

Hey Michael,

Thanks so much for your reply!

Please disregard the idea of locale custom paths. It’s not really want we want to do, it was just a bad explanation from me… :slight_smile:

I’m a bit unsure how it would work when we don’t have the same URL structure for each of the locales currently. Let me try and give you an example that is a bit more “advanced” than the /demo example.

In Germany we have localized slugs.
So if we look at our “platform pages” in Germany they look like this:
www.famly.co/de-plattform/digitale-elternkommunikation

The “same” page in US (it’s not exactly the same as it’s modified for the US market):
www.famly.co/us-platform/parent-engagement

And the original page form the primary locale in the UK:
www.famly.co/platform/parent-partnerships

It should be possible to do a subdirectory for the UK → US translation, as the slug is not localised and named ‘platform’ both places.

But as the German slug is translated ‘plattform’ it would sit in it’s own folder in the pages setup in Webflow right?

Page setup in WF
Page setup in WF1034×1323 157 KB

I’m still confused if we can accomplish the setup we want…? I have a support ticket with Webflows support team pending on this topic. I’ll keep the tread updated when I hear something.

It seems like we might need to be looking into a solution with Country-Specific Top-Level Domains (ccTLDs) maybe?

4

All good, if you did not use the localized paths feature you could probably stuck with Localization essentials which is cheaper.

Let’s use your example- your primary UK content is be here;
/platform/parent-partnerships

Then localization would create the US pages at e.g.;
/us/platform/parent-partnerships
or /en-us/platform/parent-partnerships
You control that locale path so you can set it to /us, /en-us or something else.

Then the German variant would probably be at-
/de/platform/parent-partnerships

All of your current localized pages would be changing location, so you’d setup redirects for each of them to maintain your inbound links and SEO.

If you did want the German pages to show localized path strings, I believe it would and up as e.g.;
/de/plattform/digitale-elternkommunikation

I have done a lot of work with Localization but all of my client sites are on the essentials plan, and are not using the localized URLs feature. My understanding is that the way Webflow has built localization, the localized paths features;

  • Still requires the locale directory, e.g. /de, at the start of the path
  • Still requires the same directory structure as the primary locale content is in- but each folder / page / collection page / collection item slug can be localized, so e.g. platform → plattform, etc.

I might be off on that understanding, but everything I’ve seen points to that design. It’s also how I would probably have designed it.

For you, it means a fairly substantial site restructuring. All of your current localized pages will change their paths, and you’ll setup redirects to forward traffic to their new homes.

If you’re feeling overwhelmed on this, drop me a message, I’ve been doing a lot of projects like this lately and I should be able to crack this out quickly for you. Just click my name above and send me a message.

Glancing at your sitemap, I can see why you’re concerned, you have a lot of translated pages at manual locations and they’d need to be matched up.

One thing Webflow doesn’t really provide a facility for is pages that exist ONLY in a locale- there always needs to be an primary-locale page.

An example of that might be your /terms section, because it looks like you might have German-specific terms pages like /terms/datenverarbeitungsvertrag-2-7 that may not have an analogue in your base UK locale. Essentially you can solve that by having a blank primary locale page, and be a bit creative with a small bit of custom code or redirects, but it’s an interesting exception case.

If you’re wondering why my responses are so thick- it’s because I was in the middle of writing Sygnal’s localization guide. Your questions helped me see where designers are hitting roadblocks in the migration process. I’ve just published this-

1 Like
5

Tanks so much for this explanation Michael! :pray:

It makes a lot of sense what you explain and it indeed seem that we are in for a substantial site restructure as you are referring to…

As our site structure is so different in each of the locales we will end up with a minimum of 50+ blank primary locale pages…

Read your great blog post about the limitations of WF Localization and now the one you shared here and it nicely explains the challenges we face at Famly under your blog headline “Dealing with Locale-specific Pages”. → https://www.sygnal.com/lessons/localizing-an-already-localized-site

What is your take on having: Country-Specific Top-Level Domains (ccTLDs) maybe for our case?

The price of having a UK website on famly.co.uk a US on famly.com, a Danish on famly.dk and a German on famly.de. Is from a Webflow package very comparable to paying for three locales on the Advanced package…

I’ll talk with my team about all of this and I will reach out to you if we need any help with our setup. Thanks for your time and expertise so far!

6

Thanks Esben,

Ah that’s good to know. That can be resolved elegantly with a reverse proxy so that the “blank” primary pages don’t confuse search engines. However navigation becomes a trickier issue, because you want you probably want your localized pages in the main nav, but only when you’re switched to that locale?

I have some ideas on how to make that elegant, using a form of locale-specific conditional visibility, but the best way to approach this depends on exactly how you want the navigation to work. If you do the “mapping” step in my guide first, you’ll have a really good idea of exactly how that should work.

Ha yes, that gives you a lot more freedom and control over your content and organization. But it means a fair but of duplicate admin and I don’t see how Webflow’s localization feature would benefit you there.

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

  • The machine translation, which cuts out much of the translation work / time / cost
  • The ability to easily switch between different locales on the same page
  • The centralized content admin ( but without Editor support )

For you, the translation is pretty much complete I think, and the localized sites have a fair bit of variation on non-overlapping-pages, so splitting the sites makes a lot of sense.

I think the main decision would be about the future.

  • If the variation in sites will increase ( different art, different content, different pages ) then separating benefits you
  • If you have a lot of new content planned for the future, and you’re currently spending a lot on outsourced translation services, then Webflow’s localization benefits you

Always tradeoffs to choose from :slight_smile:

7

Hi again!

Thanks again for your input. I’m currently working on a workaround with my team to try and solve it natively with Webflow and without too much custom code. It’s quite complicated and It’s not the perfect setup but it will work well for us we think.

When we are done and have documented the setup I can share that with you if you are interested? :slight_smile:

8

Hi Esben, we’re having the same issues at the moment, we have a bunch of pages that are locale specific. For example, we have services we offer in one country but not another, so we need to have these pages made but only exist on their appropriate locales.

I’m really keen to hear how you overcame this problem! Let us know?

Thanks so much, this thread has been really useful so far.

9

I’m keen to hear Esben’s solution as well.
So far the only solution I’ve rough-prototyped that I like is this one;

  • Reverse proxy, intercepting and modifying all pages
  • In Webflow, you add a custom attribute like avail-langs=en,es,jp which describes the locales that this page / element is relevant for.
  • For restricted pages, you put the attribute on the <body> element directly
  • For pages/elements that are valid at all locales, you don’t need the attribute.

Reverse proxy;

  • Checks the <body> element for the avail-langs attribute. If it exists and the current lang is in that list, it returns that page. Otherwise, 404 or redirect, depending on your design goals.
  • Updates the hreflang alt links so that they only include the correct pages.
  • Scans the page for other elements with avail-langs. Removes elements where the current lang is not in the list given. So, locale-based conditional visibility.

This works quite well because;

  • Relatively easy to admin
  • Fairly good coverage of the changes required
  • Supports locale-restricted pages
  • Supports locale-restricted elements
  • Works with standard navigation as well
  • Works with collection pages and collection lists, by storing that locale list in a text field, and binding it to a custom attribute.

Limitations;

  • Without a centralized map of the restricted pages, the sitemap isn’t easily fixed, so it will still indicate all locales are available, and will point to some pages that return 404’s or redirect somewhere. This means a manually-updated sitemap, or else engineering a separate piece of the reverse proxy.
  • Doesn’t support ECom products because Webflow’s ECom Products collection doesn’t support CMS custom attribute binding. However ECom doesn’t work with localization anyway yet so this is more of a future issue.