Honestly, I'm impressed with how Webflow has implemented the new Localization feature. It's mostly awesome.
But, there are a few big gaps, and if you're considering using Webflow's localization on your website, you need to know about them.
This page is a summary of the bugs & problematic limitations I'm aware of, as of Jan 2024. Be aware of these limitations so you're not blindsided.
Anecdotally, I can say that my first attempt of English to Chinese blew away some of my Chinese colleagues I ran it by. They found it difficult to believe it had been translated by AI.
Webflow lists about 184 Locales as options, however not all of these actually support machine translation - and [ 09-Dec-2023 ] there is no indication as to which ones Webflow can translate, and which it cannot.
Currently Webflow uses Amazon Translate as the underlying translation engine, which supports these 75 locales only;
Afrikaans, Albanian, Amharic, Arabic, Armenian, Azerbaijani, Bengali, Bosnian, Bulgarian, Chinese (Simplified), Catalan, Chinese (Traditional), Croatian, Czech, Danish, Dari, Dutch, English, Estonian, Finnish, French, French (Canada), Georgian, German, Greek, Gujarati, Haitian Creole, Hausa, Hebrew, Hindi, Hungarian, Icelandic, Indonesian, Irish, Italian, Japanese, Kannada, Kazakh, Korean, Latvian, Lithuanian, Macedonian, Malay, Malayalam, Maltese, Mongolian, Marathi, Norwegian, Farsi (Persian), Pashto, Polish, Portuguese, Portuguese (Portugal), Punjabi, Romanian, Russian, Serbian, Sinhala, Slovak, Slovenian, Somali, Spanish, Spanish (Mexico), Swahili, Swedish, Filipino Tagalog, Tamil, Telugu, Thai, Turkish, Ukrainian, Urdu, Uzbek, Vietnamese, and Welsh.
The other 109 in the list are likely to be less common languages on the World scene - and will need to be translated by hand or using some other system with the API.
This limitation affects both the locale you are translating from, and the locale you are translating to. If your site was originally written in Hawaiian, you likely will not be able to machine translate it to anything else.
If you encounter this problem, Webflow support recommends checking out the Localise app integration Webflow has, as it appears it may offer some added machine translation support, with designer integration. However as far as I can tell this is not at all "compatible with" Webflow Localization, so you cannot easily have e.g. 2 locales under Webflow Localization, and another 1 through Localise. If anyone explores this further, let me know.
Note that this limitation extends to language variants or dialects, so [ untested! ] if you want to translate a US English site to Australian English, it's likely that Webflow's localization can't help you do that.
In another Amazon supported-languaged table, you can see that there are distinctions between e.g. Spanish ( es ) and Mexican Spanish ( es-MX ). Likewise with Brazilian and European Portugese ( pt and pt-PT ).
However to be fair the manner of speak, idioms, phrasing, and vocabulary aspects are likely to be different across different locales anyway. I'm not sure how Amazon Translate would do in effectively translating the meaning and flavor between American, British, and other English locales.
Another big win that impressed us is how well integrated the translation process is into the site's content structure. To be certain, there are significant problems that need to be resolved - but Webflow's rigid separation of content and style has made it possible to preserve styling accurately while translating the content itself.
In a similar fashion, CMS items are translated field by field, locale, by locale, within the CMS.
I'll touch on the workload of this later, but for now the important thing to see is that you have specific control over your translated content.
Overall, most things translate well;
A few things do not;
Unchecked;
As of 13-Dec-2023, the designer will try to localize HTML Embeds as well. That has the effect of "freezing" and "translating" the content. If you later update the Embed content, including CSS or JS, it will not be propagated to your locales unless you re-translate it.
Whoopsie. That means your Spanish page, for example, might end up with different CSS and JS than your English page- which is pretty cool but is probably not obvious, or what you intended.
These element are also picked up automatically if your right-click-translate a containing element, so watch out for your Nav components in particular where you're most likely to have Embeds.
Best practices-
Overall, this is workable. You get details element-level, and CMS item-field-level translation control.
The key thing to understand is that translations work as "overrides" or the primary locale content. When you translate an element or a field, that content is copied and frozen - and it will not change until you re-translate it.
In-Designer;
CMS content translation;
In-Designer ( Editor mode );
In-Editor ( the site-integrated WYSIWYG content editor );
All translations are performed from the default locale. However, when you update content in the default locale, it does not automatically get updated in the translated versions.
Ideally, changing an item in e.g. the CMS would then alert you unobtrusively, and give you the option to auto-translate to all of the dependent locales.
Likewise there is no reporting view that can show you e.g. that the primary locale's homepage has been edited after the German translation was last generated.
Test- are all field types localizable, e.g. prices etc. What about formatting of content, is it locale-aware?
Here's where things really begin to fall apart for me. While the initial translation process is workable, the ongoing administration process is quite constrained.
At present this is our most substantial issue with Webflow Localization. This affects everything relating to our update processes and agency workload, to to our client's real-world costs, after localization has been added to a site.
We've not tested this directly, however;
This means;
Site-level;
Page-level;
Notes- https://university.webflow.com/lesson/localize-page-settings?topics=localization
When the locale switcher is properly set up, and is easily accessible on mobile devices as well, it's very easy to navigate.
This feature is available only on more expensive localization plans.
Not ideal for such a fundamental feature, but you could roll your own with JS or a reverse-proxy setup.
Also there appears to be a limitation in that the current 18-Dec-2023 version of auto-routing detects language but not geo-location. As a result, sites which have multiple dialects of the same language ( e.g. English - US, UK, Aus, or NZ? ) likely will not automatically route visitors ideally.
Contact us if you want to discuss a custom build for that type of capability.
This feature is available only on more expensive localization plans.
Localized paths are ideal for SEO, and for user navigation, and are available on the more expansive plans.
For the most part, when you switch to a locale like Chinese, Webflow will automatically prefix all of the on-site paths with /zh/, and leave external URLs alone.
However there is a gap;
This is a common problem because you may well have a blog article which links to a Product page... these URLs are not picked up and localized.
Let's say your you have an English ( primary-locale ) site with a German alt-locale. If you store a link to /about in the CMS, and a user is viewing the German translated version of your CMS page, clicking that link will take them to /about rather than e.g. /de/about. This means they'll be switched back to the English locale.
To test- rich text elements and current linking approach.
Note: recently, Webflow fixed a longstanding issue with CMS link fields, which previously did not permit root-relative paths. Now they do, which to us suggests that this solution may be in-progress.
I like Webflow's approach here. Site search restricts results to the current locale. If you're on /search, you get only your primary locale results. If you're on /de/search, you'd get only German locale results.
Some Utility Pages, like the Access Denied page used in User Accounts, are also reported to force the user back to the primary locale.
https://discourse.webflow.com/t/localization-in-webflow-link-routing-doesnt-work-on-user-page-pages/264418
Designers are often confused by the Current Locale state under the style panel, which doesn't seem to work as expected.
My best guess is that this is targeted at Enterprise customers, who have the ability to do Locale-specific styling, and that this state indicates a style applied only to the current locale ( whatever you have currently selected in the top left locale toggle ).
Webflow appears to have a specific approach to localization, which I like- but which won't match what some people expect.
I like this design because it's clean and predictable;
However this design precludes at least two specific things that some designers might expect;
Basically zero support. For client-side JS & library developers, there's currently no easy way to determine-
Also;
This means some significant limitations. If you have any scripts which do any kind of navigation, you will either have to force your users to a specific / default locale, or you'll have to figure out how to determine the selected locale and the path of the target page.
You can determine the current locale overall by looking at the html lang attribute, but that doesn't actually tell you if localization is in use on the site.
? API?s for static pages and for CMS?
A bit at the higher end, in part because Webflow does not charge for the translation itself. But the integration is excellent.
If Webflow sorts out client access so that they can localize through the editor, it will be a pretty much perfect solution.
Even for non-localized sites, the primary locale must be set to ensure proper site operation. There are two situations it seems to create;
Here's how to set the primary locale-
If the site wide localization language code is set under your dashboard site setting, it can override certain published settings of the new Webflow Localization feature.
Make sure to clear the Language code and save, if you're having problems.
If you localize a set of elements e.g. the entire body of a page, it may pick up image elements as well, and "clone" them into the localized version.
This means they no longer track the main image and if you update the main image the localized image won't match.
This can happen even if you are on the Essentials plan, which does not support localized assets. That means that when you're in an an alternate locale in the designer, the settings pane gives you no image options.
You can tell it's localized by looking in the nav. You will see a globe next to any items that are "cloned" and localized.
However, you can fix this by right-clicking the image element in the nav, which will give you a "reset all image settings" option at the top of the menu. This unlinks that image from the localized version and it will track the main image again.
It's possible to auto-translate by right-clicking the appropriate elements in the left-side navigator. Otherwise it's difficult to access.
https://www.loom.com/share/79b111ed441f418f94bdb3e73ee48c17
https://discourse.webflow.com/t/how-to-localize-form-success-error-messages/266764/4
When you first begin setting up Localization, you'll hit a point where you need up upgrade your plan, either because you've hit your translation limit or because you're ready to publish.
The pricing screen is a bit confusing, because it shows both the pricing for localization, and then the combined monthly pricing including your regular site hosting,
Once you've purchased a Localization plan, you'll need to refresh the designer in order for it to be aware, and to allow you to publish those locales.
Make sure the locales you need are actually supported for machine translation. Most common, popular languages should be supported, but if it's not on Amazon's list... test it first.
Who will be editing this content? If your clients rely on the content editor, and they will be doing the localized content admin themselves, they will have significant problems [ Dec-2023 ] with localization.
Localization works best when your localized versions match the primary locale page-for-page, element-for-element.
If you have significant variation, like pages that exist in German but not in Spanish, or sidebars that only show on your Japanese-locale pages, you will need some creative solutions to keep your site structure, navigation, and SEO clean.
Make sure you're OK with the limitation of localization paths like /de/ rather than e.g. https://mysite.de or https://de.mysite.com as access options.
Note, if you need special domain support, Sygnal may be able to help with a reverse proxy solution. Contact us to learn more.
Make sure you are ok with these restrictions-
Consider integrating the locale switcher into your main nav, possibly with flags, localized locale names, and easy access on mobile devices.
Check out our locale switcher course on how to make your locale switcher more visible and accessible.
Any script-based navigation will struggle without the ability to know the current locale, and how to navigate to other localized pages on the site.
FS Filter must be adjusted to deal with localized content, particularly for checkbox / radio-button matches.
Consider all of the impacts to your conversion tracking. Here, standard non-localized URLs might be easier to work with.
UNTESTED concern only - how does Localization impact this?
Decide whether you need localized slugs and how they will work.
Localized slugs cost more ( about double the monthly fee ), and chances are, you'll need to hand-translate all of your slugs.
If you use instance properties on your components for content ( such as hero area H1's ), those are not currently localizable.
Check this, I'm working on a forum mention. I'm not sure of the limitations there, it may be that the content cannot be translated, or it may specifically be things like regional or locale-specific pricing, emails, checkout and other utilitarian aspects that are not localizable.
The API doesn't support automated localization, which means any feeds or sync operations you have will likely only be able to add un-localized content.
You'll need a separate tracking solution to create localize tasks for someone with Designer access.
SEO is pretty solid [ 23-Dec-2023 ], but there may still be some limitations, check them out first.
