Known Localization Limitations & Bugs

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.

• Limitations on who can perform translations, which make it difficult for clients to maintain a localized site independently
• Lack of automated translation support
• Limitations on what languages can be machine translated
• Limitations on how a localized site can be constructed, such as the inability to have locale-only pages
• Lack of support for custom domains, and subdomains
• Complete lack of developer support on navigating and augmenting a localized site with client-side Javascript.
• Various issues around certain aspects of translation, such as numeric formats

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.

The Translations

Machine Translation Quality

• + Overall the quality of the machine translations seems excellent.

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.

Machine Translation Coverage

• - Exactly which locales support machine-translation is unclear.

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.

Limited Locale Variations

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.

Bug notes

Integration of the Translations

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.

• Translation is done per-element, from the perspective of the alternate locale. That means, you choose what gets translated and what doesn't.
• Any element you translate will have its style as faithfully preserved as possible, while the content is translated.
• Complex elements, like rich text elements, will preserve their structure well - headings, lists, blockquotes and so on, while translating each element.

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;

• + Rich text elements translate beautifully, preserving all formatting. Ace job, Webflow team.
• + All text elements
• + Component static contents
• + Most CMS content

A few things do not;

• - Component instance properties
• - Text string parts of SEO fields in Collection Page settings, e.g. _{{{ Title }} | News Article}, the Title would be translated but not the "New Article" part in the settings field.
• - CMS Option fields
• - CMS Date fields are not localized

Unchecked;

• RSS
• METAs
• Dates, numbers, currencies...

HTML Embed Localization Issues

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-

• Probably separate your _<style> and _<script> embeds from actual content embeds so that you can control localization separately.
• Be careful to keep these unlinked, or to watch them carefully.
• If you accidently translate an Embed and have "frozen" it problematically, you can go into each translation and right-click that Embed to "reset" / unlink it.

Access & Translation Process

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.

Designer Experience

In-Designer;

• + Right-click on any element to translate it and its children
• > + This also works in the navigator, so you could translate the entire page by right-clicking the body element
• - All translations must be done per-locale, so if you have 5 locales, you must switch locales 5 times to translate each item.
• > - And the same with future updates
• > - There is no way yet to right-click the element and translate it for all locales
• > - There is no way yet to set auto-translation for an element ( which is highly relevant to updates, automation through the API, and to Editor use ).

CMS content translation;

• - Cannot be done on the designer canvas, must be done in the CMS popup windows
• - Must be done one record at a time, ~~one field at a time~~
• > + Webflow has just added single click translation for a single full CMS item. however you must select the locale first still, so each locale must be translated separately.
• > - No way to right click column headers to translate all items for a specific field
• - Apparently No "translator" role that restricts access to these functions.

Content-Manager / Translator Experience

In-Designer ( Editor mode );

• Webflow has just added the ability for users with access to the "editor" mode of the designer to perform translations

In-Editor ( the site-integrated WYSIWYG content editor );

• - Zero editor support for translated pages.
• - Clients cannot self-administer their own translations without designer access.

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.

• + Appears to support locale-specific CSV import

Test- are all field types localizable, e.g. prices etc. What about formatting of content, is it locale-aware?

Content Updates & Ongoing Administration

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.

• There is no Editor support, which means any Editor change made by a client must be communicated to the designer to make the corresponding updates in the translated versions.
• Similarly there is no means to mark an element as "auto-translate changes", which means that future changes to the primarily locale are not picked up even when they're made in the designer.
• > Of course there are some companies who have the time, resources, and capability to hand-review and manually update their alternate locales, but our research indicates that 99% of clients only have the time and resources to update the primary locale, and need all other locale updates automated.

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.

Automation and API Feeds

We've not tested this directly, however;

• + The v2 API appears to support localization at least in the context of Apps. It's not clear how this relates to the standard CMS API.
• It's unlikely this has automation hooks built in ( e.g. add a CMS item, have it auto-translated to 4 locales ).
• It's unlikely that automation platforms like Zapier and Make support the v2 API well yet.

This means;

• Anything auto-adding data to your site, e.g. Make scenarios importing RSS feeds will not translate that data
• Any inbound syncs, like Whalesync or Power Importer Pro which pull data from sources like Airtable will not translate that data
• You'll need some kind of worklist creation to track and indicate to you which new / updated items need to be translated. Push tasks into Trello or Jira for example, for someone with designer access.

SEO

Site-level;

• + Sitemap.xml looks great
• + Canonicals are auto-generated properly for localized pages
• - Redirects are not automatically localized. Make certain that if you redirect a page, that you also redirect the localized variants of that page.
• - No support for locale-specific subdomains like _{fr.mysite.com}.
• - No support for locale-specific custom domains like _mysite.fr.

Page-level;

• + Page head now includes hreflang self-referencing or x-default links.
• > - However, there are still some glitches in that the paths are suffixed with a trailing _/, which redirects, e.g. on the homepage, /en/ redirecting to /en . This is considered incorrect SEO practice for canonicals and alt hreflangs, as it sends mixed signals to the search engines.

Notes- https://university.webflow.com/lesson/localize-page-settings?topics=localization

Website User Experience

When the locale switcher is properly set up, and is easily accessible on mobile devices as well, it's very easy to navigate.

Automatic Detection & Routing

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.

Localized Paths

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.

Navigation & URL correction

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;

• - All CMS items which have URLs pointing to pages on your site are un-localized, and will navigate the user back to the default locale.

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.

Site Search

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.

• + Site search works elegantly.

Utility Pages

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

Locale Switcher

• + Automatically displays all published locales
• + Can work in a range of setups including a dropdown
• > + Including showing the currently selected locale on the dropdown header
• - No ability to sort the list
• - No localized locale names, Chinese is shown only as "Chinese"
• - No support for flags or other indicators associated with each locale

Current Locale state

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 ).

Localization Design

Webflow appears to have a specific approach to localization, which I like- but which won't match what some people expect.

• You have your main site, which is intended to be a single, primary locale
• It can have pages served as e.g. /about, or as /en/about, the locale language code is optional for your primary locale
• You then have a locale, let's say it's German. Every page on your site will have a locale-specific version, e.g. /de/about. This exists even if you choose not to translate that page.

I like this design because it's clean and predictable;

• Every locale has a version of every page
• They all begin with that locale's path prefix
• Things like navigation and the locale switcher make more sense in that they manage this context
• All of this is important for predictability in any custom code driven navigation you need
• It's SEO-friendly, since Webflow has the correct alt hreflang links in the page head and in the sitemap.

However this design precludes at least two specific things that some designers might expect;

1. Every page will have a localized "version", even if you choose not to translate it. If your site has 100 pages, but you only want 14 of them translated to Japanese, you'll still get 100 "localized page paths". No harm there, but it's important to understand.
2. You cannot have ( as far as I'm aware ) a localized page outside of its localized path group. If your primary site is English and you have Japanese as an alt, your English page might be /about, but your Japanese localized version ( even with custom paths ) cannot be at /about-jp. It must be under the locale identifier, e.g. /jp/about.

Developer Limitations

Basically zero support. For client-side JS & library developers, there's currently no easy way to determine-

• - Whether localization is installed on this site
• - What locales are supported on this site
• - Which locale is currently selected
• - Whether you're on the default locale, or an alt locale

Also;

• - No ability to trigger a locale-switch from the current page
• - No ability to get the URL of the current page for a different locale

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?

Cost v. Value Proposition

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.

Bugs

Primary Locale Must be Set

Even for non-localized sites, the primary locale must be set to ensure proper site operation. There are two situations it seems to create;

• Script errors in the browser console, which may impact the operation of some elements like sliders (?).
• Missing CMS items from the sitemap.xml.

Here's how to set the primary locale-

Site-wide Language Code Conflicts

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.

Unintended Element Localizations

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.

Bug notes

Form Success / Error Messages cannot be localized

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

Miscellaneous

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.

Top 10 Things to Consider before Localizing

Are your locales supported?

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.

‍Content administration

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.

‍Site structure and overlap

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.

‍Path-only locale separation

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.

CMS limitations

Make sure you are ok with these restrictions-

• Option fields do not currently translate
• Date fields do not currently localize

‍Consider how you will make locale options & switching obvious, attractive, and accessible

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.

‍Script-based navigation & site features

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.

‍Analytics and page tracking

Consider all of the impacts to your conversion tracking. Here, standard non-localized URLs might be easier to work with.

‍Sorting & Filtering of CMS lists

UNTESTED concern only - how does Localization impact this?

‍Slugs

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.

‍Components

If you use instance properties on your components for content ( such as hero area H1's ), those are not currently localizable.

‍ECommerce is currently unsupported?

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.

‍API-based Data Automations

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

SEO is pretty solid [ 23-Dec-2023 ], but there may still be some limitations, check them out first.

‍