This week we had 79 active reviewers! Great job everybody and thank you so much for contributing to reviewing themes! Even one theme a week can make a difference! Take the time and thank the following people when you can!

Weekly meeting agenda

Our weekly meeting is on Tuesday at 18:00 UTC in #themereview. What shall we talk about?

It’s good to every now and then have an open meeting so we can talk about anything that people want to. Lets do that this week. There is no set agenda so please add what you’d like to talk about in the comments.

I’m not sure if this is an appropriate topic for a meeting, but I’d like to talk about the way themes abandoned by reviewers can be handled. As far as I understand, at the moment it’s up to a reviewer to pick a theme without any specific order. It’s possible themes stay there for months while themes added later but never abandoned by a reviewer could make it to the approved or even live themes list much sooner. This system seems to inadvertently penalize theme authors for someone else’ s actions (the reviewer’s). I’m aware it’s a difficult issue and perhaps one that will disappear once the new automated system of uploading themes is in place, but it’s affected me and a few people, so I mention it in case anyone else would like to discuss it too.

Can we have a better `approved but not live` queue so that reviewer can give that link to developer after theme is approved? I believe Report 24 has some issues. Even after commenting or mentioning it in Slack queue order is changes which is not the expected behavior. Thanks.

@Otto42 is there a way to display the timestamp of the state-change, either from “reviewing” to “approved”, or else from “open” to “closed”? I think we’d need a custom SQL query to generate a “closetime” parameter. But if we can do that, we can add it to Report 24, and sort by closetime. That would prevent the queue from changing due to new comments being added to closed tickets.

The front page shown in the WordPress.org theme previewer has been a subject of much debate. There’s some movement on getting better demo content, but the front page is the first impression. We want it to look good and best represent what our themes are capable of.

Given the prevalence of non-blog themes, there needs to be a bit of balance here. I’ve thought long and hard about what the best route would be for handling this. The following is my proposal. I’d like to get all of your feedback as well as check in with @otto42 on the feasibility of it before creating a ticket.

Let me know your thoughts.

How the front page should be shown

I wanted to keep this simple and make sure that it works with both regular blog themes and themes that have a custom front-page.php.

The previewer should have some code that checks:

If front-page.php exists, override front page setting to show a page.

Else, show regular blog posts.

The idea in code

Note: This is potential code for the previewer to better describe my idea. It’s not something to put in your themes.

The following bit of code is a rough draft of how I think a feature should work.

Something similar to this was my plan, actually. The problems I encountered were not with faking it out like this, but mainly with getting the stupid previewer to work the way I want. That will take more effort than I expected, but now with 4.3, it might be a bit simpler.

Yeah, basically, the idea is to use every effort possible to showcase every theme in an “optimal” setup, with fake content. Faking out the preview ain’t hard. Getting the customizer to work safely is really annoying. Everything I wrote, I was able to easily hack. That gets old after a while. 🙂

Also, we can adjust later for rare cases we missed. I have a half assed plugin to do it. It’s terrible, but a starting point.

tl;dr: Theme translations and language packs are coming to WordPress.org and they’re awesome.

Howdy all you wonderful themers and theme reviewers,

The meta team has been working hard to enable theme and plugin translations on translate.wordpress.org. For themes, we plan on importing all active themes into WordPress.org – that is, any theme updated within the last two years. We expect to import them in the next few days or weeks, at most. This will involve importing ~1500 themes, which, combined, have about 315,000 total strings. After duplicates, the number drops to only 80,000 unique strings.

Below are some things you might want to know.

Why do I want WordPress.org managing translations for my theme?

WordPress.org provides translations in dozens of languages and is ever expanding as new contributors join. (There are currently 140 locales on translate.wordpress.org, but not all are active.) While you may have translated your theme into a few languages (or none!), there are likely more translators on WordPress.org in more languages.

But that’s not all! Themes in the WordPress.org directory will be able to take advantage of language packs! That means smaller download sizes for users, because themes will no longer need to ship translations. Eventually, we also plan to give priority to localized themes in localized directories; e.g., someone searching the Romanian theme directory will see Romanian themes prioritized over English-only themes.

What if my theme already ships translations?

Translations that are already shipped in themes will be initially imported into translate.wordpress.org. Again: we’ll import the strings and the translations on the initial import. We won’t continue to do that because the end goal would be for theme authors to remove the translations from their download, allowing language packs to fill the void.

What if I don’t want to use WordPress.org to manage translations for my theme?

Then you don’t have to! Translations shipped in a theme take precedence to language packs. If you continue to ship translations with your theme, WordPress will ignore the language packs. However, if a translation is available in a language your theme doesn’t support, WordPress will use the language pack for that language.

To fully support language packs, you’ll want to remove translations from your theme in your next update.

What if I want my translators to approve translations on WordPress.org?

We’ve written up a plan for working with the polyglots team to enable this. There will be some initial pain in adding new, project-specific (aka theme-specific) translation editors, but afterwards your translators will join a growing group of WordPress translators and help make the entire ecosystem better.

Other questions?

Just ask! We’ll watch this thread and answer any questions you might have.

Wow this is good stuff! However it would be even better if you’d allow non-wordpress.org themes to also store their translation files on wordpress.org. Is there a possibility that you add this in the future?

If you’d allow that, you can make wordpress.org the Nr 1. place to be for theme translations 🙂

Currently, we have no intention of opening the door to non-WordPress.org themes. I don’t see that changes in the future either, but anything is possible.

Essentially, translations (and language packs) will now be one of the benefits to being part of the WordPress.org ecosystem. If, as a theme author, you do not wish to release your theme for free, under the GPL, on WordPress.org, and within the bounds of the theme review team, you don’t get benefits of the ecosystem.

Hi,
One of my theme users just translated remaining strings of the theme to Czech language. He says the status is ‘waiting’. Now, my question: what should I (as theme author) do in order to accept/approve those new translations? Thanks.

Strings must be approved by a translation editor. You’ll need to contact the Czech team of translation editors to encourage them to approve the strings. Additionally, if you feel comfortable, you can ask them to make your theme user a Project Translation Editor. They can then approve Czech strings just for your theme.

Theme review team weekly meeting notes

Points from meeting:

We should reconsider our keywords in our roadmap. Can we automate them? Can we have people able to update them?

We need to do a survey just on tags.

We began talking about how we should improve the admin interface for those with themes on org. The UI needs to be more friendly. How can they manage their entire theme?

Actionables: @greenshady to think about tags and with me come up with survey suggestion. @grapplerulrich: to get an easy cull list of tags. Add to roadmap: tag survey, redoing tags, theme admin on org.