 Okay, so let's start. Our next speaker is Pascal Barhila, who is a co-worker of Dominic who spoke earlier today. He's based in Zurich in Switzerland, which is a multi-lingual country. He's been working with WordPress for half of his life, focusing especially in improving WordPress internationalization to make the web a better place. Today he will be sharing how to make use the latest and greatest technology to make your WordPress plugin or theme free internationalize. Please welcome Pascal. Alright, so as he already mentioned, today is all about the different ways of making your WordPress plugin and our theme sustainable, and especially the workflow around this. I will be tweeting slides afterwards, so this is my Twitter handle where you can follow me or just check for what I treat the slides. So obviously this talk is about internationalization in WordPress. Over the years WordPress has steadily improved the way we work with internationalization. Overall it does a very good job at this. However, challenges still exist and there are lots of things that we can make better and should make better. In this talk we will look at improving the internationalization workflow in particular and try to split things up into three topics. So first we're going to look at the bare basics of how internationalization works in WordPress and the history of that relationship. These things don't change no matter what your individual workflow looks like. Dominic talked a bit about this in the morning in case you want some deeper insights and have a nice talk. Make sure to watch the video afterwards. Second we look at how we can actually internationalize our WordPress plugin or theme. And what does it take to make our project available to people all around the world, no matter what the language is. And finally we will explore how we can reduce the barriers and improve existing workflows when it comes to internationalization. Before I start I want to quickly explain some of the terminology in this area of topics. This is about some of the terms you hear quite often in this talk but also online. We're talking about translations in WordPress in general. First of all, when I speak about internationalization I refer to the process of creating something that can be adapted to specific local languages and cultures. In other words, it's about making your project translatable. We don't actually say translation. It's more precise to say localization because it's about making the English software like WordPress work in another language like, let's say, Spanish. There are differences in Spanish. Like Spanish in Mexico is different than Spanish in Spain. So put another way, we can say that localization is like translation but with a cultural twist to it. It's not just about written words. It's also about things like symbols, units, date formats, thumb formats, or whether you drive on the left or the right side of the street. These things are all contained in this little word called local. So we're talking about localization and translation. We don't refer to the language itself. It's always about locals which contains the region and the cultural preferences. So with this settlement I want to explore a bit of WordPress' history in this area. WordPress has been internalized for many years now, I think at least 10 years, and over 50% of all WordPress websites are non-English. So this is a really important area for a project. And without this, it wouldn't be that big of a notch. So that's why it's so important to take other languages into account when you want your WordPress, when you want your software to be used around the globe. Internationalization was crucial for the popularity of WordPress because English is not the main languages in most countries, right? And as soon as WordPress added support for internationalization, it was quickly translated to German and Japanese and many more languages. But I think these two were first. One big accelerator for this global adoption is the translation platform available on translatedworkpress.org. This platform allows thousands of people to fully translate and fully localize to projects. So it's not just for WordPress, but also for plugins, for themes, and I think even the WordPress mobile apps can be localized on this platform. As Dominic mentioned in his talk, it's built on an open-source WordPress plugin called LogPress. LogPress allows setting up multiple projects and translating them to, I think almost 180 different locals, so basically almost every local there is, can even translate it to English, I think. And the good thing is WordPress.org, there's quite a community around this, with thousands of translation contributors and editors. So if you publish your WordPress plugin on WordPress.org, other people can join the project and translate it for you, which is really cool. And if you know the free translation editor called PoEdit, LogPress is basically like PoEdit, but in the browser. And it's 100% open-source and free. Yeah, in case you haven't heard of it, there are just the links, if you want to look them up. One thing, there was a direct benefit, a direct result of this translation platform was the introduction of language packs in WordPress. So language packs allow you in WordPress.org to ship translations independently of the software. That means, A, you don't have to model the translations with your plugin, B, when you install the plugin, so if you're in a dashboard, browse plugins, install it, WordPress automatically installs the needed translations for the plugin. And C, as soon as a new translation is available for your plugin, like someone fixed a tie bar or added missing translations, you can install it right away. You don't have to need for the next plugin update to install the translations. It's really cool. And a big improvement we made rather recently in WordPress Core is that individual users can choose their preferred language in the admin user profile. So you go select local in your user profile and you do so without affecting the language of the whole website. And when you add a new language, WordPress will automatically download and install the language pack from the translation of WordPress.org. Now that we have explored the role of internationalization in WordPress and the benefits of flagging packs, let's have a look at how these all come together for the benefit of WordPress plugin developers. So for this, we build a little plugin. For this example, I assume that we want to publish this plugin on WordPress.org, just like Jetpack or X-Men or thousands of others. And the most basic WordPress plugin consists of a single PHP file. It's super easy and this PHP file can be with everyone. And for internationalization, WordPress provides a couple of get-taps functions to make your plugin localizable. And if you want to dispute our plugin on WordPress.org, all we need in addition to that PHP file is a readme, which basically is documentation for the plugin. So in the end, the plugin's folder structure looks a bit like this. We have a folder called myPlugin, which contains the main plugin file, which we yielded into myPlugin PHP and the readme file. Here's a simplified version of that plugin file and it consists of some metadata like the main, the version, the description, the URL to the plugin. And at the bottom, just for the sake of this example, I have a single translation function. It's one of the get-taps function WordPress provides. In this case, the first argument is the text we want to translate and the second argument is the so-called text domain of the plugin. In here, this text domain is myPlugin again for WordPress.org. This needs to be the same as the folder named from before, but it makes it easier to make it a bit consistent there. And another detail is in the readme, we say that this plugin requires at least WordPress 4.6. You don't really have to worry about that too much, but this is the version where some changes were made to WordPress.org and to make things easier for the language packs. So, we have our little plugin. Now we can submit it to the WordPress.org plugin directory. When we do that, as soon as it gets approved and we upload our plugin, it is available on the WordPress.org again with myPlugin in the URL. So, myPlugin is in the folder name, it's the text domain, and it's also the URL of the plugin. And as soon as we upload our plugin, we can translate it. WordPress automatically finds the text from our plugin and we want to translate it into every language that we want. And of course, other users can do that as well. Now, as soon as we install our WordPress plugin on our website, WordPress will automatically install the needed translations. And when new translations are available, you can easily update them as well through the dashboard without having to update the plugin. There's nothing else we have to do. It just works. The plugin is fully translated. You can verify this by checking the languages folder inside WP content. When installing the plugin, you'll see that WordPress adds new files. For this example, it's the version of the plugin and they're downloaded to the folder. So, basically, we only have to do three steps. Write a plugin, publish it on WordPress.org, translate it. Rest just works. All between these steps, WordPress does everything else for you to handle the translation. What if you want to write a plugin that we don't want to publish on WordPress.org? It could be a private plugin for your website or maybe for a client and you don't want to publish anywhere. The thing is, things aren't getting a bit more complicated in this case. The first step is always today. You start by writing some PHP code and after that, you have to do some stuff. So, as I mentioned before, WordPress.org automatically finds all the texts that we want to translate in our plugin. Now we have to do this on our own. And this part is called string extract. So, we extract all the texts from our plugin that we want to translate. So, for example, this example plugin, all the things we can translate is the plugin name, the description, even the URL and the author information and, of course, the text at the bottom. These are all things that we can translate. And to do this extraction, there are few tools that can help us. The oldest and purpose most common is called make. That's the same tool that it's running on WordPress.org. It's used for blog press there. There are also helper scripts that make it easier to use it like brand scripts called brand.mpi.htl They also use make.com and you can also use PoEdit. The editor I mentioned before can do that as well. Plus you can do the translation as well. So, when we do the string extraction with one of these tools, we end up with a translation catalog again. It's called myplugin.plg and this file contains all the strings later translated. And since you're not using the WordPress.org translation tab form, this file is not added to WP content slash languages but it's at our plug-in folder. Of course, now we have to translate all these strings but we are not on WordPress.org so we can't use the translation tab from there. So we need a tool that can do this for us. You can either do it manually maybe but it doesn't work. So I think PoEdit is the most popular solution for this. When you translate the plug-in, for example, to German, you'll end up with the new PO and MO files containing the translations that WordPress can read. Again, these are part of the plug-in folder and not WP content. The problem is we can't just add these files and see what happens. We have to tell WordPress where these files are and to load them. So for this, we need a function called load-plug-text-domain. It basically loads all the translations from our language folder in the plug-in and loads them all into memory. And whenever WordPress finds a string from our plug-in with this text domain in my plug-in, it checks to see if translation is available. In summary, we have to do lots of manual things. We rather plug-in, we have to do the string extraction, we have to do manual translation. We don't benefit from the WordPress.org translator community. And also we have to manually load the translations because before that, it was done automatically. So let's compare these options side-by-side. Again, we can see that WordPress is able to do lots of heavy lifting for us in our plug-ins. It's a much more complicated process. We have to worry about string extraction. There's no translation community. We have to manually load the translations. And for WordPress.org plug-ins, we benefit from so-called just-in-time loading of translations. So WordPress only loads them when they are actually needed. It makes your website a little bit faster. And we thought this can't be right. This can't be solution. It's not something we want for our plug-ins. Having so many manual steps is not sustainable when you write dozens of private plug-ins for your clients. In order to solve this problem we came up with a solution called Traditore which is Italian for translator. And Traditore is basically WordPress.org for everyone. It allows us to have the same benefits for private plug-ins as for public ones. So to be a bit more precise it works like the WordPress.org translation platform for your own private projects. And having our own translation platform means we and our clients can easily translate all the websites all the plug-ins using the web interface as well. And it's also built on block press. So the same software that runs Translator WordPress.org is also used for Traditore. So when we decided to build this we tried to automate as much as possible. And right now it works like this. Wherever, whenever you push changes to the plug-in. So your plug-in is hosted on Github and whenever you make changes the code gets sent to Traditore and Traditore then does the string extraction that finds all the strings and sends them to block press. And after that you can just translate everything on the website and as soon as you change these, as soon as you make translations Traditore creates a language pack just like WordPress. And now when you install this plug-in that you built and translated almost a language pack from Traditore. And for a string extraction we found all the existing solutions to be very buggy and inefficient. Plus we couldn't use something like PoEdit for such an automated task. So that's why we decided to build our own using WPCLI which is the official command line tool for language-based WordPress. So this command makes it easier than ever to extract strings from a WordPress plugin or speed. All you have to do is to like WP, IHA and make a pop-file point it to the directory of your plug-in and optionally define the target file and it figures out everything else and you don't have to worry about anything. So in Traditore we use this WPCLI command to do the string extraction and send all the strings to an important tool WordPress. And we thought this is something that's not only useful for Traditore but almost every worker's developer needs this. So that's why we fully open-sorted everything under the WPCLI umbrella and now when you download WPCLI it's actually bundled this command. So if you're using the latest version of WPCLI you don't have to do anything this just works. So after we run this WPCLI command and import the strings into WordPress Traditore actually can notify you on Slack about the changes it made. This way you always know what your current state of your project is and when language packs are being built. So in this example I make some change to this plugin and it said hey we have 85 new strings and after I did some translations it generated new zip files and new language packs and it notified us again. So the last step we need is a way to tell workers hey I built this plugin and I use Traditore so instead of workers.org please look elsewhere for the translations. And for this we built a little help script to use it you just specify the plugin Slack and point it to the API of Traditore where you can find the language packs. If you need a visual representation of this all the websites now download things from either workers.org translation API there or from the Traditore where we and our clients update translations independently of our development cycle. So if you compare for again we now have workers.org and Traditore on the left side with the same benefits they're easy to use. We have a translation platform where we can collaborate with others and we benefit from workplaces just in time loading of translations. And everything is automated as possible of course you don't have to use it if you want to go the manual way for your private plugin everything is fine but I think Traditore is a good solution for that. And if you want to learn more about this whole workflow I actually wrote a blog post about it you can find it on our company blog and it goes a bit more into detail technical aspects of how everything works. And I'd also like to point out that everything we built to make this happen is open source and available on GitHub. This way you can run your own translation platform powered by WordPress. Feel free to check it out ask questions for kids, open issues create cool requests whatever you want. So what I've shown you so far is just the current state of the WordPress internalization landscape. There are still many things that we can and should change First of all I want to make Traditore even better Honestly, I've fully finished it worked really well but the next step is to fix some bugs makes it easier to use not only with GitHub projects but with GitLab or BitPocket and we'll also work on improving documentation for the plugin as well. The good thing is Traditore gives us a good idea of things that we can change elsewhere. So whenever we see fit we try to suggest these changes also to the WordPress org translation platform. Since both tools use Gloppress Underhood they're naturally very similar and share some of the same code base. So one thing we're currently looking at is bringing this WPCLI command I mentioned earlier to WordPress org as well to work so much better than make a pot and other solutions. Another big thing that's around the corner is JavaScript internationalization. So as we all know WordPress is getting a new editor called Bloomberg and the editor is entirely written in JavaScript which creates lots of new challenges for internationalization purposes. So we'll have to see how we can best adapt tooling to this new situation and make some changes to WordPress org so you as a plugin developer can use all the new things in your product as well. Alright, so I think there was lots of information to process so far I'll try to sum things up for a bit. So first I looked at the differences between internationalization and localization. Then I explained some of the efforts going into WordPress core to improve these areas and after that I compared the workflows for internationalizing and localizing those public and private plugins. So where we could rely on WordPress org to do all the heavy lifting for our public plugins we had to follow manual where lots of manual steps for our private plugins. This starts with string extraction and continues with translation and translation loading parts. After having something that just works there's a way more work for private projects. Also you don't benefit from the community of WordPress org. In order to fix this, we created a tool called Trageditoria which is essentially WordPress org for everyone. So it's a combination of WordPress and WPCLI to help make this happen and automate all the steps we had to really take before. It doesn't stop with Trageditoria though. There are lots of ways to further improve Trageditoria. We can also learn from these things and to help improve WordPress org translation and translation platform of WordPress org thanks to our learnings from Trageditoria. So a good example for this is JavaScript internationalization. Because we have this private platform we can rapidly iterate and find a solution that we can then work to work support. Because this is something that WordPress needs to figure out as a whole, as a community. Because at the end all projects can benefit from this. Alright, so with this I'm finishing my talk today. Thank you all for listening. Thank you. Please speak in Japanese. There's one more question. Okay, so this is about JavaScript internationalization for non-workers files. Okay. So what we have right now in the WPCLi script it extracts strings from JavaScript files that use the WordPress they use the same library as Gutenberg does where you have to save the underscore functions. This already works. If you're doing something else or want to translate something that's not a WordPress to do this or if you use a React component that's the translation but these are things that we still need to figure out. We don't have a fit for all solution for that yet. Unfortunately. I hope that answers your questions. Thank you. Any other questions? I have a question that truck Yes. Is there any screen shots or capture or working things that you can do? I don't have like a screen shot right now. I mean the tutorial works kind of in the background. Right? You just publish your changes from plugin to GitHub everything else. The only thing you see is slack notifications and the translation platform which is CloudPress which looks like a translated WordPress tutorial. It's the only point of interaction with the tutorial. It's like that kind of WordPress made it to the translation. Works in the shadows in the background. Thank you. Any other questions? That's it I think. Please give a big applause once more to Master. Thank you for your talk.