Localizing a WordPress Website Built with SiteOrigin Page Builder


In this project, I worked with colleagues Marianna Guedez Forgiarini and Christopher Dean to localize a WordPress website we created with the plugin SiteOrigin Page Builder. I was mainly in charge of part of the site creation, and localizing the page into Traditional Chinese.

Creating and localizing the website

We created the site using the Women in Localization website as a basis, and used SiteOrigin Page Builder to build pages on the site, most importantly the front page. We also used the Contact Form 7 plugin and the Events Calendar plugin to create contact and event pages based on the original site as well.

We then used WPML to localize the site into Traditional Chinese and Spanish, since all the plugins used advertised themselves as being compatible with WPML. We decided to export all the XLIFFs at once, and run them through Memsource, translating everything while paying attention to the tags in the process. Then we imported the completed XLIFF files back into the website, and started troubleshooting.

Challenges and solutions

Pages built with SiteOrigin Page Builder

Immediately, we noticed that the pages built with SiteOrigin Page Builder looked the same after importing the XLIFF files. We initially tried to edit the HTML of the page directly, and that fixed most but not all of the problems. After much trial and error, and research, we finally found a post on the WPML forums which elaborated that we needed to duplicate the pages first, then edit the translations into them manually.

The contact form

Next, we worked on fixing the broken contact forms. The most apparent problem was that Memsource completely broke the formatting, so we had to re-format the contact forms by hand, which wasn’t a big deal, as this simply required us to go into the editor and add missing stuff back in.

Next was the dropdown list of 250 countries and locales, which wasn’t translated right, as Memsource saw this list as one huge segment, which made it too easy to break the formatting of the list while translating it. After trying to make sense of the huge segment to no avail, I decided to delete the dropdown and make a new one. While creating the contact form, I lifted the countries and locales list from the original Women in Localization site, and I kept a copy of the list that was cleaned of most formatting. It was much faster to machine translate the list and use the results to make a new dropdown, as country names were something that machine translation couldn’t possibly screw up.

After that, the only thing remaining untranslated was the file upload button. After seeing no option to translate it, we researched the issue, and found that the button’s language was based on the browser settings of the user viewing the page, so we left the button as is.

The contact form localized in Chinese
The dropdown list of countries and locales expanded

The event calendar

After importing the XLIFF files, the event calendar pages for Traditional Chinese and Spanish both broke, showing a nearly blank page. After reading the instructions for the plugin, the cause was determined to be the URL, or slug for the event pages. The plugin is automatically displayed on the URL “/events”, and as we localized the page names into other languages, the page URL changed as well, so the plugin couldn’t be displayed. Changing the URL back to “/events” resolved the problem.

After checking, the pages for the two events we created to test the event calendar had broken formatting as well. Fixing this was trivial though, as it simply required going into the editor to add formatting.

The completely localized event calendar in Spanish.


We originally thought that as all plugins we used were compatible with WPML, the process would be fast and automated, with minimal errors and little manual work. However, as we found out, “compatibility with WPML” can mean many things, ranging from full support of all functions to simply allowing the display of multiple languages. With most of the answers to our problems documented, we probably could have saved time had we done enough prior research, and not tried to fix problems blindly, but I think it also needs to be said that there is no easy and quick solution to localizing complicated websites built with multiple plugins (at least not yet), and proper planning and communication needs to be done before undertaking such a job.


Here is a video presentation I gave with my colleagues, Marianna Guedez Forgiarini and Christopher Dean, in which we give a overview of the project, from start to finish.