How does Webflow Localization work?
If you're building reverse proxies or doing custom code that requires an understanding of Webflow Localization, this is for you.
While Sygnal doesn't have any direct knowledge of how Localization is engineered or hosted, there's a lot that we can see.
Layered Architecture
From what we can see, it appears that a Webflow localized site operates in 3 layers...
- Your Webflow-hosted site
- Contains your default locale content
- Localization "Essentials" layer
- Contains the support for path-based localized pages, e.g.
/de/* - Adds alt lang hrefs to all pages, including default locale pages
- Modifies the sitemap.xml to include localized pages
- Probably implemented as a reverse proxy ( because it modifies default site pages, and because IP address change when localization is setup ).
- Contains the support for path-based localized pages, e.g.
- Localization "Pro" layer
- Contains an additional layer for supporting localized slugs
- Uses those translated slugs in the alt lang hrefs
- Uses those translated slugs in the sitemap.xml
- Adds auto-routing support
The reason we view this as layered architecture is that each layer appears to work on top of the previous layer.
Example of Layered Design Behavior
An example of this is when you are using "Pro."
Suppose you have a default locale of English and a page at /about . As an alt, you have German, and have localized the slug, so that the localized page is at /de/ueber-uns.
You can see the layered operation in that even with translated slugs setup, the untranslated slug is also accessible- you can access that same translated page at /de/about.
Moreover, it won't redirect, it simply delivers the content you've requested.
Sygnal's Perspective on This
We like the design a lot.
The support for untranslated slugs means that migration paths from Localization Basic to Localization Pro are very clean. After translating your slugs, all of your existing Google SEO and inbound links continue to work correctly.
In some circumstances, it would be nicer to 301 redirect those un-localized slugs to the localized versions, but this is likely to happen anyway as a result of the updated canonicals.
