Anyone who has worked with website localization knows that it’s not always a walk in the park. Not only do you have to worry about translating the content correctly, but you have to be extra careful when tossing around the inner workings of the site, which are dressed in all sorts of fancy html and javascript code-ture (my attempt at a play on words – take it or leave it). Therefore, it’s best to plan your localization strategy out well, otherwise the QA team will have their hands full!
Take a look:
The good news is that certain plug-ins can take our human brains out of the equation, allowing each bit of software to talk it out themselves. One example of this is a popular plug-in called WordPress Multilingual (WPML).
In the video above our team gives an overview of what we learned when recreating a localizing the Women in Localization website (our version is currently unpublished) using WPML into Spanish and Chinese (languages that expand and contract, respectively). As the original website is not currently localized, we wanted to see what creating a localized version would entail.
We built our WordPress site using the Sydney Theme (non-pro version) and included a front page with several sections, stand-alone pages (About Us, Resources, Mentorship Program, Volunteer Opportunities), an events page (with makeshift events), a blog page (with makeshift posts), and a contact form. We intended to localize the entire site.
Thanks to WPML, getting this localized website off the ground was a synch. To learn more about WPML: https://wpml.org/home/about-us/
Aside from the core WPML plug-in, we also activated the WPML String Translation, WPML Translation Management, WPML Media, WPML Multilingual CMS, and Contact Form 7 Multilingual plug-ins. The majority of the pages were translated via WPML Translation Management in order to send the XLIFF files off to Memsource and import them back into WordPress.
However, as noted in the video, our journey did not end here.
In order to make our front page more exciting, we made use of the PageBuilder plugin by SiteOrigin. This allowed us to add cool features like Services including Call to Action Buttons, an Employee section, Statistics, Testimonials, and a Social Profile section. Although these were rendered beautifully, they soon became the bulk of our QA work.
The typical QA when it comes to WPML is done through the WPML String Translation plugin, where you simply search for the untranslated strings (such as in widgets) and manually modify the translation. However, the untranslated strings on our front page (using PageBuilder) didn’t show up. And what do we get when trying to manually edit the translations from the front page? In short, the whole page.
Having worked with html, I thought, “hmm okay, I’ll just carefully modify the translations and preserve the code.” To my surprise, the translations were actually already there! WPML did its job! So…why wasn’t it showing up?
After scouring the internet for answers, I came across this VERY useful documentation about using WPML to translate PageBuilder by SiteOrigin: https://wpml.org/documentation/plugins-compatibility/using-wpml-siteorigin/
Did it answer my question? Not really, but it did let me know that WPML doesn’t handle these types of pages the same way. According to the documentation, the proper method for localizing these pages is as follows:
First, turn OFF the WPML translation editor!
Next, duplicate the page:
Then, you’ll have a little notification asking if you would like to translate the page independently, which will ONLY show if you have already turned the WPML translation editor OFF.
At this point, when you update and edit the localized page, you won’t have to deal with fishing through the code to find your strings, but will be able to update them manually, just like the original page!
Although we spent a lot of time banging our heads against the wall before we discovered the proper way to localize PageBuilder by SiteOrigin, it was a valuable experience in doing proper research early on in the development process before attempting to localize post hoc. Similar to how proper internationalization can save you time down the road, understanding how features such as page builders fit into your localization strategy will save you a lot of backtracking as well!
WPML is a wonderful tool, but not without its limitations. Hopefully, compatibility will improve in the future, but until then, here’s to working upstream!
To learn more about our experience and few more tips and tricks, please check out the blog posts made by my team members, Marianna Guedez and Ying-Ting Wu!
