Launching a Multilingual Site on Webflow

Introduction

In this post, we have elaborated on the 3 different approaches we evaluated to launch an internationalized site on Webflow: creating language-specific folders, using separate Webflow instances for each language, and employing a third-party product (Weglot). Read further to know how we settled on the final approach (Weglot), and the advantages involved.

Client Need

Moloco is a Pre-IPO tech firm based in Silicon Valley. It is also an international company and operates in Korea, Japan, and China. In preparation for their IPO, Moloco wanted to completely redesign and rebuild a multilingual website that will cater to the needs of their global stakeholders. 

Exemplifi was selected as Moloco’s website development partner, who helped them achieve this on the Webflow CMS platform. The resulting website is www.moloco.com. Exemplifi also ensured that the new site was internationalized for other languages - Korean, Japanese, and Chinese to be specific. You can visit these sites at www.moloco.com/ko, www.moloco.com/ja, and www.moloco.com/zh respectively.

‍

The Multilingual Requirements

Our client articulated the following requirements during our kick-off discussions:

• All static and dynamic page content had to be translated into regional languages.
• The recommended CMS platform was required to enable website admins to change images and other media assets uniquely for each site, and also allow them to control which pages or blog posts would be published for each site. For eg., Korea wanted only a few specific blogs from the main site based on the products that they sold in the country. 
• The domain URLs had to be /ko /ja and /zh, instead of subdomains like ko.moloco.com, ja.moloco and zh.moloco.com to avoid SEO inefficiencies.

Webflow Specific Approaches Considered by Exemplifi

Given these requirements, we identified three distinct approaches for the Webflow CMS: 

• Create language-specific Webflow folders
• Dedicate unique Webflow instances to each language
• Use a third-party product

1st Approach: Create Language Specific Webflow Folders

In this approach, we proposed to create Webflow folders for each language, and then duplicate the pages as shown in the image below:

After copying the pages, we would manually translate the content for each of the pages. Based on the user’s language selection, we would then serve the content from those specific folders.

Our rationale behind this approach was:

• Being very intuitive, this approach would allow content administrators for each language to simply navigate to the relevant folder and make their edits. 
• All language-specific folders could be managed within a single Webflow instance and would not necessitate any additional costs to our customer.
• Any symbol created to power the pages would work across all the folders. 

However, when we attempted to implement this solution, we ran into a few challenges. We realized that all CMS collections (for blogs, news, articles, etc.) would need to be duplicated, and we would need to change the queries in language-specific templates to point to the Webflow collections unique to that language.

Another concern with this approach was that we would quadruple the number of static pages on the Webflow instance. When we put it in numbers, we found out that the default English language site, alone, had around 60 static pages, which would become around 250 static pages after adding in the three languages, required by Moloco. 

This brought us to face one of Webflow’s fundamental limitations, where an instance is limited to only 100 static pages. Consequently, we realized that this would become a major bottleneck, and eventually prevented us from implementing this solution. 

‍

2nd Approach: Dedicate unique Webflow instances to each language

Foreseeing the risks in the first approach, we attempted to get around the static page limit (of 100 pages per instance) by considering a unique Webflow instance for each language.

We had no doubt that this approach would scale beyond the three languages, and support as many countries as our client intended to expand to, in the future. 

‍

However, upon further assessment, we identified a few risks with this approach as well:

• Webflow’s enterprise pricing is based on the number of instances we stage, and this would grow at least two to three times if we followed our approach. Our work culture would not allow us to put that extra cost burden on our client without a reasonable explanation. 
• Another limitation was the content workflow. For example, if Moloco added a blog on the English language instance, they would have to manually copy this, or manually create it again within all the three other instances. There is no way to automatically replicate the collection content across instances. Unlike our first approach, where this is possible. This would add a huge overhead to the client’s content/marketing team. 
• The final limitation that we ran into was that symbols could not be copied from one instance to another. So, when we tried to duplicate an instance, a lot of content such as collections, pages, and templates got copied over – however, symbols couldn’t be copied. This was a problem because we would have to unlink all of them, and relink them in the new instance, which defeats the purpose of symbols. 

Hence we decided to discard this approach too.

‍

3rd Approach: Using a Third-party Product (Weglot)

‍

As the next steps, we quickly began to explore the marketplace for third-party products which would be a good fit for all our requirements. In this post, we will not delve into the details of all the products that we assessed. Suffice to say that we settled on Weglot which is well-integrated with Webflow. 

The advantages of our third approach and these products, as compared to the earlier approaches are as follows:

• No manual translation is required. Weglot automatically translates site copies and allows content editors to fine-tune the language afterward.
• We didn’t have to create different folders or multiple instances. This makes the content workflow very simple. For example, after an English language blog is published, it is automatically translated by the third-party tool, and available for all the other three languages. If a content editor for a particular language decides to not use it on their site, they can simply mark it in Weglot and it won’t show up there. 

Needless to say, this comes at a cost to the client, but they felt that our proposed solution was perfect and was worth the price! 

In our next post, we will dive deep into the implementation details about how to configure and use Weglot. We will also elaborate on some tricky aspects of launching the site with Weglot. 

If you liked this insight and want more updates, we’d love for you to join us on Linkedin at Exemplifi, Facebook at ExemplifiSites or Twitter at ExemplifiSites.