 Hey, hello and welcome. Thanks for having me today. I know it's the last talk of the day. Please don't fall asleep. So this talk is for everyone who speaks more than one language, which is probably everyone in here. Today I want to explore some of the available options out there to create multilingual WordPress websites and what it would take to build these capabilities right into WordPress core. So for those who don't know me yet, my name is Pascal and I somehow ended up doing lots of internationalization stuff in WordPress. My WordPress core committer, and as you mentioned, I'm currently working on Google, so basically the Google's WordPress team. And you can find me on Twitter at Swiss Speedy or SwissBody where I will share the link to my slides later. So before we jump right into this topic, I first want to talk about the back story of this. So as I mentioned, I've been very active in the internationalization area in WordPress for quite some time now. But why am I giving this presentation about multilingual websites now? I'm not here just because I like Vienna. It's because something happened. During last year's State of the Word keynote by WordPress co-founder Matt Mullenweg, he announced that one of the next phases, phase four of Gutenberg, would focus on developing an official way for WordPress to support multilingual websites. That was a big announcement. No such plans existed in the past. And even now, there are no technical details yet for what approach core will take. It's still a long way off. And his keynote actually Matt mentioned that Gutenberg phase four is targeted for the year 2020 and beyond. And given that we are still in phase two of Gutenberg, where widgets are slowly being converted to blocks, 2020 is probably a bit too optimistic for that. But still people already started to speculate about the impact of core offering its own standardized solution for multilingual sites and what that solution might look like. And today we are going to speculate as well. So this new commitment to multilingual websites kind of makes sense for WordPress when you think about it. Almost every CMS or open source CMS or platform out there already has multilingual capabilities. WordPress is the only one without. And if WordPress doesn't want to fall behind the competition and reach more users around the globe, it needs to do something about it. The good thing is WordPress actually is already multilingual, at least in some way. It has not completely fallen behind or anything. WordPress has a strong international community and some powerful multilingual features. So let's have a closer look at WordPress internalization for a little bit. First of all, I'd like to point out that WordPress has been caring about other languages than just American English for a long time already. So in version 1.2, WordPress added support for internalization and localization. So that was 15 years ago. And despite there not being that many international contributors to WordPress at that point, to mostly English-speaking people, they recognized the importance of such a feature that allows translating WordPress into any language one wants to. So currently WordPress can be translated into over 100 or even 200 locales. And many of these translations are complete. Others need more contributors. So if you download the translation for, for example, my favorite language, Romange, an official Swiss language, it's like 30% complete. But you can translate it. I'm not aware of any other open source CMS that has that many active translations. Plus, these are not only translations for WordPress itself, but also for plugins, themes, even the mobile apps of WordPress can be translated into these languages. This is also reflected in the statistics available on WordPress.org. These show that the majority of WordPress sites are not in U.S. English. So that's a lot of sites. If you think about it, the WordPress is like powering millions of websites around the globe. That's why we're always trying to improve English, sorry, trying to improve WordPress for non-English speakers. One example, a rather recent one in that history, we added a feature to WordPress that allows every user on your website to choose their own preferred language when working with WordPress. So it's not just one language anymore that WordPress can be used in, but actually in many languages at the same time. But this of course only affects the WordPress user interface and not the content of your website. But what about multilingual content? Well, every time this has been brought up in the past, one will be told that it's not something that is of importance at the moment. It's not needed by most users or it's not as easy to do because WordPress is so complex. And most famously, you've been told that it's plug-in territory. Just install a plug-in for that. The idea behind that is quite simple, is that WordPress core itself should be small and lean and everything else should be handled by plugins. And that's what the plug-in ecosystem is there for. At least that's the thinking. Nevertheless, there have been some efforts in the past to make WordPress a true multilingual CMS. I'm briefly going to highlight some of them. First there was Babel. Not to be confused with the JavaScript compiler called Babel. Babel was a WordPress plug-in developed by an agency called Code for the People. Like six or seven years ago. Its main selling point was that it's using built-in functionality. At the time, it was the only one working well on WordPress.com VIP, which caught the interest of automatic. So the agency has been acquired by automatic around five years ago. And the plug-in was discontinued after that. So it's no longer an option. Next there was this proposal by fellow WordPress enthusiast, Kasper Hoebinger from Germany. He figured that if a complete multilingual website solution would be too big of an undertaking for WordPress, there should be at least like the absolute minimum, a field where you can just declare the language a post has been written in, just a simple select box. And this proposal actually gained some momentum among core contributors and inspired more people to look at multilingual WordPress again. So this was like four years ago, and it led to some very active discussions to work in Europe 2015 in Seville. And a working group has been formed to look into the requirements and hurdles for multilingual support in WordPress. As you might be able to see on the screenshot here, the last post on that block was from November 2015. So unfortunately, that momentum didn't last long. But there were certainly some interesting ideas being shared there, which might be picked up again in the future. So one of the suggestions was to add new columns to the database tables, to specify the language for a post or term, just for better performance and like actual built-in multilingual capability. Let's take a step back real quick and ask ourselves like what would multilingual support in WordPress look like if we could build it from scratch? After all, WordPress is a massive project, and there's a lot of things to consider when doing that. But if you have a blank canvas, there would be no limits. So what's needed? First and foremost, we start with the most important piece of content to post. One needs to be able to translate posts and pages and other content types in whatever language they like. There also needs to be an easy way to edit the current post in another language and to have like a connection between the translation. The same goes for categories and tags and any other content type editable in WordPress, really. Next you perhaps want to translate some posts with lots of visual elements, but you don't want to upload all the images twice. So there would be like some intelligent functionality to kind of share the same images between posts, but you still need to like have translated image captions, for example. And with the new block editor, everything WordPress is going to be a block in the future, so newsletter widget, a block, custom navigation menu, a block. And this should be translatable as well, so this needs to be accounted for, too. Then of course you need to have like a way to have like different URLs for each translation so that your website is going to be like example.com slash DE slash whatever. And that's like for SEO and usability reasons, and they need to be linked to each other so that you can easily navigate to another translation of the current post. And of course this all needs to be fast, activating multilingual support should not suddenly slow down your site, despite there being added complexity. And optimizing for that already starts at a database layer and continues to the presentation layer for websites like your theme. Multilingual support should not negatively infect the content writing experience. Ideally it's barely noticeable. What if you want to hire an external agency that translates your content like actual professionals that know a language that you don't? So there should be some kind of API that they can get existing content from your site and ideally directly publish translations from their own systems. And in the end you just have to put all the pieces together, connecting the dots. So you will end up with a multilingual solution that is not just fast but also very easy to use and basically leaves no questions unanswered. So no matter if you're like a personal blogger, like small business or like a huge corporation with offices around the world, you can just use WordPress. Just works. Now you might have realized it sounds a bit unrealistic. Kind of utopic. We cannot build WordPress from scratch. But instead we have to work with what we've already got. So let's have a look at what we can actually do at this very moment. So for this I picked five different WordPress plugins that allow you to turn your site into a multilingual one. One of them is Q-Translate or Q-Translate X. It is one of the oldest plugins out there for multilingual WordPress sites. Unfortunately it has been pretty much abandoned by its developer. So with no updates in over three years. However there's a successor called Q-Translate XT, I think. It's like a community project that aims to revive the original project and maintain its compatibility with the latest updates of WordPress. The problem with Q-Translate is that all the translated content is stored in the same post, like the same text field basically. And that doesn't scale with blocks at all. So it's not compatible with the new block editor, so you still have to use the old editor if you want to use Q-Translate. So my recommendation is like, please look at other options. One such option is called Polylang. It is one of my personal favorites and also one of the most popular multilingual plugins out there with over 400,000 active installs. Polylang uses separate posts for translations and uses taxonomies to link these translations together, which I think is a really neat way of doing that within the boundaries of WordPress. And compared to Q-Translate, the UI of Polylang is much cleaner. You can see the regular block editor here and only in the sidebar in the corner there you have a small box where you can manage the translations and change the language of the current post. That's the kind of usability you'd want to see in WordPress for multilingual stuff. Besides Polylang and Q-Translate, there's also WPML. It's a paid solution and it tries to cover almost every aspect of dealing with languages within WordPress. And it's probably as old as Q-Translate. So that means it grew a lot over time and it's now quite heavy weighted. It uses a lot of custom database tables and workarounds for core limitations. Multilingual Press is another contender in the field and it just recently published a new completely refactored version. And while previous versions have been partially free, this one is a paid solution as well. Interestingly, Multilingual Press uses the multi-site capabilities of WordPress to turn your site into a multilingual one. This is a very neat approach because multi-site gives you a lot of additional powers within WordPress. It might be a bit overwhelming though because it could be too much if you just want to translate a few posts here and there. But in case you are building websites on webpress.com, VIP, for example, this is their actually recommended solution at the moment. The last one I want to mention is Weglot. They're actually a sponsor of this very workamp here. They haven't been around for that long, yet they already have like 20,000 active installs on WordPress.org, I think. What makes Weglot so different from all the others, it's software as a service that aims to translate all your content automatically or using professional translation services. And because it's a software as a service, it's not just for WordPress, it's for other platforms as well. And because it's an external service, if you install the plugin, all you need to do is basically enter your API key and set the languages that you want to support. But because everything else happens on their servers, it's not really a solution that could be implemented or integrated into WordPress core. So if you try to categorize these or if you want to compare these five plugins, we can broadly use four terms to categorize them. First, we have the customized approach and the WordPress way. Weglot is far away from using WordPress functionality as all the translation stuff is being handled on an external platform. On the other hand, we have polyline and multilingual press as examples of using native WordPress functionality like taxonomies and multi-site. And second, we have the automated way like Weglot unless you hire professional translators for you. And the other plugins also allow you to hire external translators, but their whole selling point is that they enable you to translate your content. So having explored these existing solutions and the things we want to see an ideal solution, let's slow down and think about what's really or is actually realistic. Given the sheer amount of requirements for a multilingual solution and seeing the differences of the existing plugins, it has become clear that there's no one-size-fits-all solution. There's no multilingual Swiss army knife for WordPress. So whatever we end up adding to WordPress needs to be small and flexible enough that it works for many users out of the box, but for any extra wishes, you should be able to extend it and maybe like install another plugin that builds on top of that. Another thing to be considered is backward compatibility. We cannot risk adding multilingual functionality to WordPress and breaking lots of sites by doing that. So we need to do it in a way that is both backward and compatible and also future-proof in case we want to iterate on that later. And for anyone who knows the code base of WordPress and how all it is, you know that this is not going to be a trivial undertaking. So because WordPress cannot have a one-size-fits-all solution, it needs to implement it in such a way that themes and plugins can easily interact with it. Years ago, that would just mean adding some hooks and filters in the code base for developers to extend the solutions. But nowadays, WordPress is way more complex. We have a REST API now. We have a block editor. Everything's going to be a block. And it means any extensibility needs to be way more thorough thinking than just adding some filters here or there. So at this point, we're left wondering what's next? When is this coming? When can you have multilingual WordPress websites out of the box? How can I help? How can I get involved? So the short answer is the time hasn't come yet. As I mentioned before, phase four of Gutenberg has been planned for 2020 and beyond. Before that, the focus is fully on site customization and further improving Gutenberg. No work has yet begun on multilingual support. However, it is important to keep in mind with the current... to keep it in mind with the current development. So just keep it in the back of your head. And as the things we build today affect what and how we can build things tomorrow. Many people, including, of course, the folks behind multilingual press, have mentioned that they see WordPress multi-site as the ideal solution for this endeavor. And since multi-site is already a powerful part of WordPress that is supported by both themes and plugins, it might be worth looking into how it could be utilized for multilingual sites by default, but with hiding all the complexity that is associated with multi-site. So we need to find a way to utilize it for translations. It's going to be very interesting. So if you're interested in this exciting new chapter of WordPress, I highly recommend you to get involved in making your voice heard today. Even though work hasn't yet to start, now is a great time to get involved with the community and get yourself familiar with the code and contributing to WordPress core and the current phases of Gutenberg development. All the current multilingual plugin developers out there are already looking forward to this as well, as it means they will be able to greatly simplify their code bases and they can offer a much improved experience for their users. If there's any progress on multilingual WordPress, you will likely hear it first on make.wordpress.org or especially make.wordpress.org slash core and also on WordPress Slack. You can also be pretty sure that I will treat about any developments in that area. Thank you very much. So thank you. Pascal, any questions? Hi, I really like... Sorry, we didn't hear that down there. It's a fallback. Right. Or if German do is a fallback for the German C, because otherwise you always end up with a mixed English and German version. Is this something you would consider in the future? Very good point. German is a very complex language in that regard, with the formal and informal stuff. The good thing is I'm developing a plugin that allows you to set different fallbacks for your language. So you can have formal German as the default and whenever that is not available, it will pick the informal one and you could even have Spanish as another fallback if you want. So this is currently in development and should be in core at some point that you can do this right out of the box. So that multi-site approach you were talking about, I think that's a really good idea. The question I have is how well do those multi-site plugins that use that approach work when you have an actual multi-site that you want to translate? Good question. So the good thing is, or what makes everything a bit more complex, you can have a multi-site with different sites and each site can be a multi-site on its own again. So you can have a multi-site that is translated and there can still be networks of networks kind of thing. Depending of actual implementation of how it's going to look like, it's still open and how good the support is going to be, we'll see. And you don't know how that works with the plugins that are currently out there, do you? Well, the problem is like, I would say many plugins would just work, but there's just too many plugins and not all of them are really well written. So there's always going to be some breakage. Awesome. Any more questions? Over there. Thanks for a great presentation. Just quickly, maybe I missed it from the talk, but your developer, what would you personally at this moment think would be the best approach or at least the starting point for doing this? So if you want to build a multi-lingual website today with WordPress? No, to creating multi-lingual WordPress in a core. How would you approach it? Multi-lingual? Well, the front end should not be that big of a difference. It should look the same as always. It just have a language navigation. Most of the effects like the content writing, like the backend part of WordPress. Should I go back to... So for example, this is how editing in Poliland looks like. So ideally, really, if you edit content with a plugin, just set the translate, like the language of your post, and on the front end, there should be no difference at all. The only thing that is important is that in your code, it's highlighted that this is written in Spanish or something that browsers and search engines understand. But on the front end, it shouldn't have no impact at all. Sorry, but what I meant is how would you approach it? Would you personally use multi-site? Would you use additional tables, columns? This is what I meant. Well, as I said, it's like a trade-off. Ideally, it would have like changing the database tables in WordPress, but that's going to be hard to not break anything. So the multi-site approach is really worth looking into. But I also like the way how Poliland does it with the taxonomies, because it's also WordPress functionality, and the plugin has proven that it works by not breaking too many other plugins. It really depends on your use case. Multi-site is also really interesting when you have websites for different countries where it not only affects the content, but also you have other content that is only specific to that country, which is way easier for multi-site. And you can also just say user A only has access for the Germany website and not everything else. Thank you Pascal. Do you have any experience handling multiple languages left to right and right to left in the meantime? You mean in the content editing? Well, my website is, for example, it is playing English and Hebrew. Okay, so for right to left languages like Hebrew, there's a lot of things to consider. Obviously, everything is flipped. I know that Gutenberg has some support for right to left languages, but it's not perfect yet. And especially UI can be a bit tricky. If you're a developer and want to have a theme that fully supports right to left languages, one thing I really like is called RTL CSS. So it's like a script or something that you can integrate in your process and basically takes your CSS and whatever there's float left, it turns it into float right. So it's like the opposite for these languages. That is really cool. So it takes a lot of work off your shoulders as a developer. More questions? One last question maybe. Everyone's looking forward to the after-party already. For one? Awesome, well. So at this moment of time, from a user point of view, which of the tools or plugins that you mentioned would you actually recommend? I can say we'd love because they're here. So I've used, I think most of times in the past, I've used Polylang because it's very simple and the user interface is super easy. Multilingual press, not that much because A was a paid solution and might be too much if you have a small website that needs to be translated. But as soon as there's more complexity, you should be looking into something like that. It really depends on the use case. Last one? Really the last, last, last one? Last question. Okay, thank you.