I had an experience at a WordCamp in 2016 that I wanted to take a moment to share. It was unexpected and made me reflect on my involvement in the WordPress community and why participating is so important to me.
Let’s travel back to 2014. I was teaching a workshop called Plugin Development from Scratch at WordCamp Providence (now WordCamp Rhode Island). This would be my third year in a row speaking at this WordCamp, but it was my first time running a workshop. Participants would learn how to build a plugin using basic WordPress action and filter hooks, APIs and best practices.
As I was going around the room to answer the questions people had, there was one person that had many more questions than the others. I spent as much time with her as I could while continuing to run the workshop. I could tell something was not quite making sense to her yet and did my best to explain things to her.
The workshop went on and eventually came to an end. The participants slowly filed out of the room until there were only two people left: the person with all the questions, and myself. She had a few more to finish off the day, so I spent some more time with her to ensure she had the pieces she needed to continue on her own.
WordCamp ended, and I went on with my daily life. When the next WordPress meetup came around, the person from my workshop showed up. She had more questions related to the material in the workshop and told me that she was determined to get her example plugin to work.
This went on nearly every month for a year. She continued to show up with questions ready to learn. WordCamp RI 2015 & 2016 came around and she volunteered, helping to organize both years.
At the speaker’s dinner for WordCamp RI 2016 I had a chance to catch up with her. It had been several months since our paths had crossed at a meetup, and she, of course, had a handful of questions for me. This time was different, though. Her questions were far more advanced than the last time we had talked.
“I am really impressed, Karen. You’ve come a long way!” I told her.
“It’s all because of you. Your workshop changed how I saw everything. Because of the way you explain things, something clicked. And all of a sudden, everything made sense.”
When I was driving home I reflected on what she said to me. It caught me off guard. I always contribute to WordPress and speak at WordCamps because I enjoy it. But I had never thought about what impact the things I said would have on the people who attended my talks.
Because I took the time to teach a workshop (that I was afraid no one would receive any benefit from) and answer some questions, someone received a level of clarity that helped them understand WordPress better. And this improved their ability to make a living on WordPress.
I started to think back. I was once that person. We all were. Even though we may not be able to trace our own eureka moment back to an individual person’s instruction at a workshop, the collective pointers that we receive from the people we interact with in the community play just as much a part of our skill sets as the long hours spent at the keyboard combing through the files in WordPress Core.
No matter what level your skills are at, there is always someone who can learn from you. Don’t be afraid to offer help. Open source a project you have been working on. Answer questions in the support forums. Attend local meetups. Speak at WordCamps. Translate plugins & themes. There is a way to contribute to the community for every person.
This is why I love the WordPress community. The number of people willing to take the time to teach, mentor, give guidance. Everyone belongs, everyone has a right to be there. WordCamps pull all of these people from all walks of life together to collaborate, to help, and to learn about WordPress.
This is why I WordCamp.
There are many like it, but this one is mine.
First, in case you are not familiar, here is a little bit of background on how translations work for WordPress.
Way back in 2013, WordPress 3.7 added support for something called language packs. When combined with Glotpress and a few automated processes behind the scenes, anyone who is multilingual with a WordPress.org account can translate plugins, themes, and even WordPress core through a simple front end interface.
Once a specific locale reaches the 95% translation mark, a language pack will be generated and automatically made available to anyone using the plugin on their WordPress site with that language locale selected.
Anytime you push an update to your plugin’s SVN repository, identical strings from past versions are automatically synced to the most recent versions. You can even watch this happen in the #meta-language-packs channel of the Making WordPress Slack.
Now, on to the issue that I experienced. When I pushed my updates to the plugin’s SVN repository, I noticed that the “Stable” column was empty. This was weird because “Development” and “Stable” were the same code.
I had committed my new code and changed the plugin’s stable version in the plugin file’s header in the same commit. Because of this, the automated processes that generate the translations behind the scenes could not generate a list for “Stable”.
To fix this, just make a commit to the plugin’s repository. I did this by increasing the version number while leaving the stable version alone. I watched the #meta-language-packs channel for my plugin to be regenerated after doing this, and all was well.
Do you speak another language? Hop over to the Toggle wpautop translation page and spend a few minutes translating my plugin. All contributions are appreciated.
For more background info on how translations work on wordpress.org, check out these Make WordPress blog posts.
If you are a plugin or theme developer and want to learn more about using language packs in your code, read through the core handbook for Internationalizing Your Plugins, and Internationalizing Your Themes.
I hope that someone finds this helpful!
After some investigation, I realized that the file it specified was only 25KB. However, at some point in its history it was over 100MB, Because I was pushing the entire commit history for that repository, it was rejecting everything.
The solution is to remove the file entirely from the repository’s history. It took some trial and error for me to find something that worked for me because most snippets relied on history already existing in the origin repository. Here is what worked for me:
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch path_to_file" HEAD
Hope this helps someone!
At WordCamp Rhode Island 2016, I ran the Contributor Day workshop. Before we got to work contributing to core, I gave a short presentation about how the WordPress development process works, and introduced them to the tools they would need to be familiar with.
I followed the Trac tickets that the participants became involved in. By my count, 5 first time contributors were credited in WordPress 4.7.
Congrats to all of the first-time contributors from WordCamp Rhode Island!