 So internationalization is one area I particularly like in software development, and it's great to be here today talking about it So my name is Pascal. I'm 24. I'm a software engineer. I'm also a WordPress core committer and contributed to like lots of other stuff in WordPress and I came all the way here from Switzerland to talk about WordPress, but I also learned about the craft beer industry here in South Africa, so I have to try that as well Obviously this talk has to do something with internationalization over the years WordPress has steadily improved to the way we deal with translations and overall it does a very good job at it and But there are always new things around the corner and ways to improve existing stuff and today we will look at We'll have a look at improving internationalization workflows in particular and I tried to split this talk up in in three areas so first we're going to Look at the bare basics of how internationalization and localization and WordPress work Just so you get a better sense at how all these parts interact with each other and Second we'll look into how we can internationalize our own WordPress plugin or theme so it's like a simple example how this works and like what does it take to make a project available in other languages and Finally, we'll explore how we can use barriers and improve existing workflows when it comes to internationalization in WordPress projects and this is especially interesting for like private plugins or private project for example premium plugins or premium themes Etc. Before we start I want to quickly explain the terminology a little bit Like two terms you will hear more here most often in this talk The first one is internationalization super long word. So usually we refer to it as I 18n Where 18 is like the number of letters missing in the middle So this is basically the process of making your project translatable So this way your software can work in other languages and not just English like it can be Spanish or Chinese or German But we don't say translation actually Because it's not just about written words that we translate it's also about things like symbols and units date formats Whether you drive on the left or right side of the road. So this process is called localization Because like you have to adapt to the local look and feel In other words, it's like translation, but it has like a cultural twist to it And also if you aren't that experienced with these topics I encourage you to check out slides of a previous talk of mine. It's called internationalization done, right and It explains like lots of common pitfalls and best practices When dealing with internationalization All right, so with this settled I want to explore a bit of where process history in this area where possess been internationalized for many years now over 50% of WordPress websites are non English or non American English. So this is really a big thing for the project And if you want to your work If you want your software to be usable around the globe It's important to take other languages into account. You just can't like leave it English and like that's it So internationalization was crucial for WordPress as a product project and as a community Because nowadays it's used all over the world in countries where English is not the main language So as soon as WordPress added support for that, it was quickly translated Into German Japanese and many more languages. I think the Japanese guys even translated like source code comments into Japanese like crazy One big accelerator for this global adoption Was the translation platform that was made available at translate the word press org This platform allows thousands of people to fully localize the projects So it's not just for WordPress itself, but also all the plug-ins and themes available on WordPress org and Even the WordPress mobile apps There's like thousands of people every day translating projects there The site is built on an open-source WordPress plug-in called Gloppress So Gloppress allows setting up multiple projects and translating them to almost 180 different locals and a local is not just a language But it's like also language with variants. For example in German We have like a formal German variant and informal German like lots of different stuff So we're present org build quite a community around this translation platform But the good thing is because it's built on this open source plug-in Everyone can run their own translation platform actually if you know the free PoEdit translation editor So Gloppress is basically like PoEdit just in a browser and with multiple people Plus it's open source and free and everything So a direct benefit of this translation platform was the introduction of language packs Language packs allow you and WordPress org to ship translations independently of the software This means three things first you don't have to bundle the translations with your plug-in with your source code and When you install a plug-in WordPress Automatically downloads the translation from WordPress org and as soon as new translations are available It will automatically update these translations without you having to update the plug-in So if there's like a spelling mistake in the translation, you can just fix it on WordPress org and You can update your website Without touching the plug-in. All right Now let's have a look at how all these things from the translation platform how they come together For the benefit of WordPress plug-in developers We start by building a new plug-in and for this example Assume that we want to publish this plug-in on WordPress org just like chat pack Yoast SEO on and thousands of others The most basic WordPress plug-in Consists of a single PHP file and in this PHP file We can use all the internationalization functionality of WordPress provides to make our plug-in translatable And if we want to distribute a plug-in on works at org We also have to add a read me file that explains how the plug-in works Kind of makes sense So in the end the plug-ins folder structure looks like this We have our folder called my plug-in which contains the main plug-in file called my plug-in dot PHP and a read me file and The most simple plug-in file will look like this It has some metadata in it to you know the plug-in name description the version the author and At the bottom for a sake of this example. We have a single string that we want to translate So this is just one of the many functions we can use to translate our plug-in So the first part of this function call is the text we want to translate and The second one is called the text domain. So this is the plug-ins text domain Which is also called my plug-in and it's the same as the folder name from before so this is an important detail These two things have to match Another thing is that in our read me file. We defined that our plug-in requires at least WordPress 4.6 You don't have to worry about that much But this is the version where we added some major improvements to how things work in WordPress and how language packs are loaded Plus, I hope you're running for WordPress 4.9 anyway like nothing older. So this shouldn't be a problem now We have our plug-in and we can submit it to work with org Our plugin was called my plug-in. So as soon as it gets approved and we upload it It will be available under the same name as our folder name and text domain So in this case like WordPress org slash plug-ins slash my dash plug-in and When we've done this We build our plug-in. We published it on web.org It means it's now also available for translation under this translation platform at translate the word org So we didn't have to do anything for it. Everything is created automatically and now users from all over the world can translate your plug-in in their own language and So now as soon as you install the plug-in via the WordPress admin panel you can install the plug-in and WordPress will automatically install the language for it the translation So there's really nothing else we have to do And you can easily verify this whole process by checking the WP content folder Of your WordPress site. So when you install the plug-in and WordPress install the translations files You will see two new files in that folder with your text domain or your plug-in name and Locale so in this case and install the German translation and it's inside WP content slash languages So there's only a few steps. We really have to follow here first. We develop a new plug-in with the available Cat-Tex function that WordPress provides. We submit it to word org. We translate it Install the plug-in boom done Things are a bit more complicated when you develop a Private plug-in or let's say a premium plug-in that you don't want to publish anywhere or at least not on WordPress org So maybe it's a for a personal site a client or something you want to sell First steps are obviously identical. We have to write a plug-in But after that we're kind of left on our own for a bit The most tricky part is called string extraction This is the part where we need to find all the texts in our plug-in that are actually translatable so that we can translate them later on So for example taking this Metadata from before all the parts that are marked bold here are actually translatable in WordPress So that means we need to extract these strings so that we can use a Translation platform like blood press or another software to translate them There are lots of tools out there that help you with the string extraction The oldest one is make pot. There's like grant tools and as mentioned earlier. There's also PoEdit with which Is kind of integrating very well with the word press and WordPress plug-in So these are usually the tools you use to make this happen and When you run this string extraction, you end up with a so-called POT file And this POT file contains all the strings that we can now translate it doesn't contain any translations And since we're not using the word with our translation platform We'll have to save this file inside our plug-in folder and not WP content So since we have to use this pot file for the translation We need to some tool then can read these files and help us translate all the strings Again, this probably is going to be PoEdit again, but there are also tools especially websites or As I mentioned before a lot press which you would have to install on your own server So without going too much into too much detail at the end. We will end up Using the same language as files as before They're just now in the plug-in folder plus we have this so-called POT file which contains all the Translatable strings so when you want to add a new translation you take this POT file Add the translations and save them as Po and MO files Now we just have to load these translations Because they're not these files aren't any good when we don't use them So in our plug-in we can use a function called load plugin text domain And it basically loads all the translations from our folder into memory And whenever WordPress finds a string from our plug-in it can fetch the translation from this memory So in summary we have to do lots of manual steps when developing a private plug-in Not only do we have to do the string extraction ourselves. We also don't benefit from the wordpress.org translator community Also, we have to manually load Translations in our plug-in and we can't benefit from the more intelligent option that WordPress uses For public plugins where it only loads translations when they're actually needed. So if you compare the two Options side-by-side we can see that WordPress is able to do lots of things for us Like it takes on over all the heavy lifting for us for us when we publish our plug-in on web.org For private plugins the whole process is rather complicated We have to handle the string extraction translation parts We don't have to worry about that on wordpress.org and In contrary it even gives us access to a large community of translators that can localize our plug-in and Additionally we benefit from the so-called Just-in-time translation loading I just mentioned before so WordPress will only load the translations When needed and that doesn't happen for private plugins at some point I or we at our company thought That can't be it That's not what we want for our plugins Having so many manual steps. It's just not sustainable when you develop dozens of private plugins and themes for clients And in order to solve this problem, we built a solution called Traditore which is Italian for translator. I don't know why we picked Italian. It's just sound good so Essentially, try the Tory is WordPress org for everyone and It allows us to have the same benefits for private plugins as for public ones hosted on web.org So to be a bit more precise. It's like translated WordPress org But for our own private projects So having this platform Allows us and our client to translate all the plugins and themes using the same web interface as some workers at org Of course, it's built using glutpress because it's a WordPress plugin and and it's free and open source And it's the same plug-in that power is to translate of workers.org What you see here is a super simple bare bones glutpress install Looks very ugly. I know Unfortunately, that's like the default styling on has Doesn't look as pretty as website org, but it gets the job done and All the try the Torah specific things. I will talk about now They aren't visible here because all these things they happen like under the hood So using glutpress in our custom territory plug-in we can easily translate our projects into any language we want and Since it's powered by WordPress, we can even create the user accounts So for example client a can only see the translations for project a and so on With trajectory we try to really make things similar as with represent org And we try to automate things as much as possible and right now it works like this so let's say you've built a plug-in and The source code is hosted on github or git lab or bit pocket just somewhere and Whenever you push changes to that repository when you make a change your plug-in Github sends a notification to try to Tori and try to Tori Then does all the string extraction stuff and pours these strings into lawpress and after that you can just go to the translation platform make all the translations and Try to Tori will automatically create these language packs that WordPress needs and uses so all the now all you need is Install a specific plug-in on your WordPress site or like configure your plug-in to basically tell WordPress Hey for this particular plug-in Don't look for translations on web.org. We have our own platform here And it means your sites translations for this plug-ins are always up-to-date just like if it was an public plug-in and for the string extraction part We had to come up with something new that is more reliable than what is being done on web.org And we found all the existing solutions to be very buggy and plus we couldn't use PoEdit because PoEdit doesn't run on a server and doesn't work automatically So that's why we decided to Build our own solution using WPCLI which is the official command line interface for WordPress so this WPCLI command makes it easier than ever to extract strings from WordPress projects all you have to do is point it to a directory and optionally define the target file name and Maybe some other options and it figures out everything else So this is the command we use under hood in Traditory and of course since this command is not only useful for us But for everyone else We open sourced everything and it's available on Github and it's actually like an officially bundled command with WPCLI so if you're using the latest version of WPCLI You get all the benefits from this command. It just works So after Traditory runs WPCLI And imports the strings into Gloppress. It can notify you on Slack about the changes it made So this way you always know what the current status is and when language packs are built and So the code I mentioned earlier to tell WordPress to look for the translations from your platform Is a simple stat so we built a little helpful script helper script called Traditory registry So to use it you just specify your plug-in Slack Which is like my dash plug-in again and point it to the API of your translation platform We try to do like a simple visual presentation for this So all our client websites now download the translations from either WordPress.org or our own platform Depending on whether it's something hosted on web.org or developed in private And Traditory allows us to collaborate on the translations and update them Without interrupting the development cycle of our plugins and themes Compared side-by-side again with this new approach Traditory essentially does what the WordPress.org does We never have to do all the manual stuff ever again Everything is as automated as possible And if you want to learn more about this workflow, I even wrote the Yeah, quite a large blog post about that that goes a bit into more detail And I also like to point out that everything we built to make this happen is open source freely available on github This way you can run your own translation platform powered by WordPress Here are even the links to the repositories I'm free of free to check them out ask questions fork it Maybe open issues, but please don't I don't want to work. No, just kidding There's plenty of documentation available about how to set everything up There's also a new major release coming out soon with even more features What I have shown you so far is just the current state of The WordPress internalization universe and what we did to optimize the workflow There are still many things that we can and should change so for one We obviously want to make trajectory better The plug isn't yet fully finished, but it already works for us very well And the next step is to make it easier for you to use as well Whenever possible we try to contribute back to the community and so all the things we try to Give back in some way. So for example, we're currently working on bringing the WP CLI command to Represort org so that the translation platform uses the same tool that we built Also, this wouldn't be a WordPress talk without any mention of Gutenberg Especially and now that it is going to be released soon So Gutenberg is the new editor experience for WordPress and I think the release plan for end of November And one thing about this editor is that it's almost entirely written in JavaScript Which creates new challenges when it comes to internalization? Because what I've shown you before is just PHP code, but with JavaScript like everything is a mess And so workers currently being done to make sure all the texts in Gutenberg can be properly translated Because right now you can't translate them on works at org So they're going to be lots of changes in WordPress 5.0. That will affect anyone Doing internalization and localization work For more modern WordPress projects using JavaScript So I know there was a lot of information process. I hope you got better of an overview Though I have how things work under the hoods with WordPress and works at org I don't think we have any time for questions right now But feel free to ask any questions later on you can find me outside in a hallway or maybe downstairs where there's apparently beer, right? Yeah Also, if you're coming to work at Cape Town Doing a workshop there about this topic where you can learn about this in a more like hands-on approach So for now I'm done with my presentation. Thank you very much