Sorry that I create two topics. I tried to put both in one, but I’m not allowed to add more than 10 pictures.
I’m facing a lot of issues after I activated localization on my website. I already created an issue at support but after a couple of days I still have no answer. I understand they are busy. But now my project is getting to a hold. My editor can’t edit the text, because the new Localization feature has broken the Webflow Editor. I’ll probably let my colleague work in the Designer instead of the Editor, but it would be very nice if this issue will be fixed.
To make sure there is no problem with created components I added a whole new Site in the Workspace and started from scratch to see if the problem also exists on a clean site. On this second website I also activated Localization and added two locales. English (primary) and Dutch.
Using the designer I added a heading and paragraph to the Home page.
Using the designer I translated the Home page into Dutch.
I published it and everything looks great. There is an English and a Dutch homepage. But when my colleague tries to update the Dutch text the following happens.
When he goes to the Dutch page he sees the Dutch heading and paragraph.
But when he hits the Edit button or goes directly to the Editor by added ?edit after the url, the Webflow Editor opens, but it doesn’t show the Dutch text, but the English text
When the text is changed, saved and published it is changed for both locales. For English and Dutch.
Yes currently the Editor does not work with localization.
It would be nice if Webflow at least had a clear error dialog so that people don’t break their sites with it or lose content.
Webflow hasn’t announced their plans on this, most of the community is guessing that Webflow is no longer really supporting the client editor (?) and is instead gradually replacing it with the “Editor” role in the designer, which you can see in the top-right. This is due in part to the large number of Editor bugs that have appeared over the past few years, which remain unfixed.
However if this is the direction Webflow is planning, there are a lot of problems with this approach;
It’s not actually wysiwyg anymore, in the way that the client Editor is
It’s quite inconvenient when editing CMS content, to be bounced over to the non-WYSIWYG CMS record editor. Breaks the whole editing-review process on e.g. article releases.
It’s not integrated into the site, so harder to launch
Access to the designer, for clients, hasn’t been worked out either. They either need a paid freelancer account, and you invite them into your workspace ( where they then have access to ALL of your projects ) or you have to setup a workspace for them, move the site there, and then invite your own freelancer account in. This changes ownership, access, billing, a bunch of thing.
There doesn’t seem to be a way to restrict a user’s designer access to Editor-only permissions, outside of Enterprise-level plans.
So, no solutions really. At the moment, consider the Editor a no-go for your localized site clients. You can migrate the site to a new workspace, rehost it, and invite freelancers. Pretty much that appears to be the only functioning option at the moment.
I’m keen to hear what support shares, it’s difficult to plan ahead or even to tell clients what to expect if we want to recommend hosting their site with Webflow.
I agree with all your points and am also pretty keen to see what will happen here.
I work with very small companies, and so access delegation is a pain point for us. If CMS and content admin becomes less accessible to end customers, that erodes some of the best selling points for using Webflow.
Customers not feeling like they have “ownership” over their websites is after all, one of the major topics in Webflow’s own “The 2024 State of the Website” report. So I really want them to get this right!
I just received the following message from support:
Hi Martijn,
This is Rachel from the Webflow Technical Support team. Thanks for contacting us about an issue editing a localized CMS item.
I apologize for the delay in getting back to you regarding this issue, we are currently experiencing a higher than normal volume of customer support requests.
At this time, localization has been optimized specifically for the Designer. The Editor will still work as expected for the primary locale, however, it isn’t possible to make edits to secondary locales or access localised content from the Editor.
However, collaborators can use the Designer’s Edit mode to access these features. Edit mode is available to all members of a Workspace: Webflow University | Edit mode
Please let me know if you have any further questions.
Kind regards, Rachel
Clearly Michael is right about everything. I’m new to Webflow. Usually I develop in React, but for this project we decided to go for Webflow to speed things up. I’m designing/developing in the Designer, my co-worker writing the text in the Editor. It seems perfect. My co-worker is not a developer so he can’t screw things up because with the Editor you can only edit the texts.
Once the localization was available I added this functionality because we need two locales. At first I was very impressed. I work for a Translation Agency and because of this I’ve seen many poorly localization implementations in different CMS systems. Their marketing about localization is very good, but they are lacking to provide clarity about what it can’t do. On another forum post I already found out that Ecommerce items are not part of the localization. And now I have to find out by myself that also the Editor is not part of it. Keeping me in the dark for a week. Would be nice if Webflow would communicate this cleary.
Having those high price tags in mind, I don‘t get over the fact that the Editor, a crucial tool for clients, hasn‘t been considered for localization right from the start. Even more so, there should be a BIG warning sign on any localization info page that you should avoid using this service if your clients rely on the Editor.
As Kevin mentioned above, the Editor is a big selling point for Webflow. The Designer’s Edit mode is a totally different thing and less comprehensible to clients.
Bumping this up as this is a problem for our team too. Big fans of anything Webflow, but the product marketing on this is better than the product technical documentation. We had challenges in even finding the localisation settings (‘site settings’ for me is typically the site project settings, though not in this case).
Everything in the designer is absolutely slick wrt localisation, super easy to use & well polished.
However, not having this functionality in the editor is a big no/go. This will essentially mean that we have to loop all of our customers into our tenant, which is unmanageable.
I’m in a dialogue now with Webflow support regarding a different issue I encountered regarding localized HTML embeds. That’s not relevant here, except that it connected into the problem area of “how do you keep alt locales in sync with your primary?”
I’m looking at my client projects and these things are true almost without exception-
My clients rely on automatic machine translation
They’ll almost never review the translated content, and probably don’t even have the resources to. If a customer were to report something was incorrect, they’d want to fix it, but that would be a very exceptional circumstance. ( and they’d call me )
My clients rely on the Editor, and regularly create/edit content, but ONLY in the primary locale.
They wouldn’t really benefit from access to alt locales in the editor, as much as they’d benefit from an auto-translate feature or some simple “click to translate to all alt locales.”
So I’m toying with this line of thought.
At this point, I think the ideal solution would be to add an auto-translation feature, by element.
I imagine it would work like this;
In the primary locale, right-clicking any element would allow you to toggle a new checkmarked menu item “Auto-translate for all locales”. When that’s on, any changes to that element would be auto-translated.
In an alt locale, right-clicking any element would give that same checkbox, but ALSO a checkbox “Auto-translate for this locale only”. Same thing, but it’s a locale-specific setup. That gives you the ability to exclude certain locales from auto-translation if you want to admin them manually.
For CMS content, I sort of feel this should work the same way, at the element level in the designer- however I don’t think that’s how Webflow designed CMS translation. I think it’s designed at the field level, so…
This function would actually appear in the CMS instead?
But ideally would be mirrored on bound CMS fields, so that designers can do most of the translation setup in the designer.
This solves a third issue which is that right now, afaik, you have to translate CMS data item-by-item. If you have 1,000 items, omg. Makes much more sense to me to translate field by field.
This change is most important for CMS template pages, since adding a new blog post, editing a press release or service page… those changes need to be reflected immediately in all locales.
But I think the approach works for static pages also.
For my clients I think this would pretty much eliminate the need for them to be able to directly access localized content in the Editor, at least for now.
I’m very curious if my client scenario is true for most other design teams here also?
It makes me mad that there is no clear statement about the “Editor” support for Locales>
This is what Ida (Webflow support) says:
“Given that our new Localization features were optimised specifically for use inside the Designer, including the new Edit Mode feature that is available in the Designer. We do not currently support Localization via the Editor. With this in mind, transitioning your translator over to utilise Edit Mode in the Designer is the best way to ensure that they have access to the new Localization features.”
Our choice for the Webflow platform was largely based on the perfect wysiwyg editor, so I could easily convince my clients to migrate from WordPress to Webflow with all the extra costs. $ 12,00 per month per language is in fact outrageous, certainly without the Editor feature.
