 Hi, I'm Sergei, and my talk is about managing a local WordPress community. My WordPress story started with translating a few strings into Russian in 2007. I'm managing Russian translations and support forums since then for almost nine years. A couple of years later, I started actively working on WordPress core, and now I work as a WordPress core contributor at Hust. I'm also participating in an Apologots team, which translates WordPress into more than 100 languages. The support team, which runs the forums and tries to make sure the users who need some help can get it. And the meta team, which runs the infrastructure behind WordPress work. So, what does a local community mean? It can mean an online community with their Rosetta block forums, documentation in your language, and translation. It can also mean an offline community in your city, meetups, and if there's a large community, also work camps, I'm gonna talk about both online and offline community. So, what the Rosetta block is, it's a center hub for your local, and the place users go to download WordPress in their language. It has a news section, the theme directory translated into a language, the plugins in your language, and the support forums where users go for help and communicate with each other and answer each other's questions. It also has the documentation part is a codex. It's a lot of collection of wiki pages with functional reference and examples. So, an important task for a local community is to provide translations for WordPress core plugins and teams. I think it's maybe the most important task. When a new WordPress version is released, Apolograd's team keeps an eye on the local stats. Here's how it looks, and makes sure that there are no issues and the locales that need some help can get it. We want to make sure that WordPress is translated into as many languages as possible. So, how do we keep translating efficiently? It depends on what you would like to do. If you'd like to stay in touch with the core team and report any issues you've noticed with the strings, then I'd suggest translating WordPress trunk. It's Russian currently in development. If you'd like to provide better Russians and release candidates in your language for your users, you can do that as well. The upside of this approach is that you don't have to translate hundreds of strings at once on the release week, and the downside is that it takes about an hour per week, and most importantly, the strings can change later. So, if you don't like to make too much edits, that's absolutely fine. And then I'd suggest waiting for a string freeze. It's generally announced a couple of weeks before the release. In the past, when you wanted to translate a plugin or theme, you needed to get a pod file, which is a translation template, to allow a software like PoEdit to create PO and ML files and email them to the plugin author. The good news is that now you no longer have to do that. You can translate almost any plugin directory on translate WordPress.org site, which is powered by the software called LogPress. I say almost any plugin because some plugins might not be properly prepared for localization. In that case, you should report the issue to the plugin author. So, it sounds like it's now easy to translate plugins and themes and everything is great. Well, it's not that simple because if you have several thousand plugins and themes to translate, you cannot and should not do it alone. On the translate WordPress.org site, there are three different roles. The general translation editor, or GTE, who oversees translations for the whole locale. The project translation editor, or PTE, who translates a particular project like a plugin or theme or WordPress core, and translator who occasionally contributes a few streams. So, in order for the translation system to work efficiently, you should have as many PTEs as possible, and you also have to make sure they have read and understood the style guidelines for language. So, how do you get more PTEs? When someone has translated a plugin after a post request on a blog to assign that person as a PTE for their plugin, you should monitor those requests, check the strings, and if everything is okay, add that translator as a PTE. If there's an issue, let them know what it is and how to fix it. You don't have to monitor the blog manually. You can set up a notification for the locale code in your WordPress.org profile. You should create a translation guide to refer new PTEs to and document the team's best practices to make sure everyone is on the same side. Currently, there's no way in WordPress to reject a string with some feedback, so if you'd like to explain the reason for the rejection, you have to find a way to contact that translator. Another important part of a local community is support forums. I like the forums pretty much because answering questions from other users is a great way to learn. Most of my WordPress experience comes from tinkering with code per someone's request on the forums. However, once you start answering questions, you begin to represent WordPress itself to the user. You should take that into account. Users don't come to the forums just for fun. They come frustrated with a particular problem and need a solution. So don't be condescending, be helpful. Like with plug-in and team translations, you cannot and should not run the support forums alone. So when someone shows up and starts consistently giving helpful replies for a certain amount of time, consider making them a moderator or administrator. There will be a lot of similar questions from different users, so it might be a good idea to create an FAQ page and make sure you have a forum rules or a forum welcome page as well. It's also a good idea to read the support handbook available on make.org. It has some general expectations and advice for support contributors. You should empty the spam queue regularly because otherwise, some replies can easily be lost, especially if they have links in them, which would be frustrating. No need to do it manually. There are browser extensions you can set up for that, like visual ping for Chrome or the still web monitor for Firefox. If you're on WordPress Slack, you can participate in support team meetings on Thursdays and say hi to other members of the international support team. You might also want to create your own Slack team to discuss things specific to your locale and your language. So when you think about WordPress documentation, I guess the first thing that comes to mind is Codex. It's a collection of wikipages with function reference and examples. The upside is that anyone can edit, expand or translate it, and the downside is that it might be hard to find some information because there's no clear distinction between user reference and developer reference. It's kind of a mix of both. That's why Codex is no longer actively developed, so supported. In the future, it will be replaced with a user reference called name Hub Hub, which is currently under development, and code reference, which is already live on the WordPress org. There are also some handbooks for plugin and team developers and for some contributor teams. At the moment, all of them are in English, but perhaps in the future some of them will be translated into other languages. Let's talk about the offline community. I recently started the WordPress Meetup in my home city and would like to share my experience. WordPress Meetup is a group of two or more people getting together on a regular basis and discussing WordPress related topics. There can be any number of attendees and they even can have any formats. So what should you do? There's a good chance you already have a WordPress Meetup in your city which you can join, but what if not? What if there's no WordPress Meetup in your city? Then you should start one. If you haven't seen Tycho's talk this year at what Camterina is called, your local WordPress Meetup is only a few steps away. It's on WordPress.tv and it's very inspiring. I highly recommend it. So how do you start a WordPress Meetup? There are three simple steps. Find a venue, go out to some friends and have a fantastic Meetup. That's it. It's that simple. It might be a good idea to check out existing resources in your city. Maybe there's already a developer group that would be interested in WordPress, maybe a PHP group for some general interested people. When planning the Meetups, you should pick a regular day of the month, but also make sure it doesn't clash with other iterative events. Create a Slack channel to discuss potential ideas and create a website or a Facebook group or whatever to post photos and news. You can choose any formats for the event you like. You can hang out in a coffee shop or have something more official, whatever works for you. It helps to have an agenda and prepare it in advance. For example, you can invite the speaker. You can let everyone discuss their recent WordPress projects. You can have a contributing evening and again, whatever works best for you. If you've been thinking about starting a WordPress Meetup, but haven't yet, just do it. Okay. I have a short talk and to summarize it, I think WordPress is a unique project and what makes it great is the community where everyone is welcome. It's the most open and friendly community I've ever seen without all of us. It's just software. It's okay. It's all for me.