Theme Review Team

Updates from August, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Tammie 10:58 am on August 24, 2015 Permalink |  

    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.

    • Maria Antonietta Perna 12:38 pm on August 24, 2015 Permalink | Log in to Reply

      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.

    • Nilambar Sharma 3:23 pm on August 24, 2015 Permalink | Log in to Reply

      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.

      • Chip Bennett 4:37 pm on August 24, 2015 Permalink | Log in to Reply

        @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.

  • Justin Tadlock 5:09 pm on August 20, 2015 Permalink |  

    Proposal: Better front page previews 

    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.

    add_filter( 'pre_option_show_on_front', 'wptrt_show_on_front' );
    add_filter( 'pre_option_page_on_front', 'wptrt_page_on_front' );
    function wptrt_show_on_front( $show ) {
    	return wptrt_has_front_page() ? 'page' : $show;
    function wptrt_page_on_front( $page ) {
    	// 100 is the page ID to show.
    	return wptrt_has_front_page() ? 100 : $page;
    function wptrt_has_front_page() {
    	// Need a check to see if the current theme being previewed 
    	// has a front-page.php template. If it does, return TRUE.
    	// Else, return FALSE.
    	return false;
    • Samuel Wood (Otto) 5:12 pm on August 20, 2015 Permalink | Log in to Reply

      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.

      • Justin Tadlock 5:36 pm on August 20, 2015 Permalink | Log in to Reply

        Sounds good. I’m glad we’re kind of thinking the same thing or similar here.

        • Samuel Wood (Otto) 12:29 am on August 21, 2015 Permalink | Log in to Reply

          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.

        • Samuel Wood (Otto) 12:33 am on August 21, 2015 Permalink | Log in to Reply

          Note: i might push back the customizer code to later in order to create a better preview system now. Not perfect, but, hey. Gimme a couple weeks.

    • Emil Uzelac 5:24 pm on August 20, 2015 Permalink | Log in to Reply

      This is turning into something great!

    • codeinwp 6:10 pm on August 20, 2015 Permalink | Log in to Reply

      Sounds like a good idea for me.

  • Samuel Sidler 5:50 pm on July 14, 2015 Permalink |
    Tags: translations   

    Theme Translations on WordPress.org 

    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.

    How do I add support for translations and language packs?

    @Otto42 wrote up a great post on the topic back in 2013. (Wow, it’s been a long time!) There’s also a great page in the theme developer handbook which walks through how to internationalize your theme.

    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.

    • Jose Castaneda 7:12 pm on July 14, 2015 Permalink | Log in to Reply

      Sweet! Looking forward to this!

    • Milan Ivanovic 1:21 am on July 15, 2015 Permalink | Log in to Reply

      This is huge. Nice!

    • Marcoevich 6:50 pm on July 15, 2015 Permalink | Log in to Reply

      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 :)

      • Samuel Sidler 7:12 pm on July 15, 2015 Permalink | Log in to Reply

        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.

    • Emil Uzelac 9:11 pm on July 16, 2015 Permalink | Log in to Reply

      Good job!

    • Justin Tadlock 1:54 pm on July 18, 2015 Permalink | Log in to Reply

      I just wanted to step in and say that I’m excited! I’ve actually been excited about this proposal for a very long time.

      Keep up the awesome work!

    • Stanko Metodiev 8:37 pm on July 18, 2015 Permalink | Log in to Reply

      That’s nice!

    • ThemeGrill 8:41 am on September 22, 2015 Permalink | Log in to Reply

      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.

      • Samuel Sidler 1:24 pm on September 29, 2015 Permalink | Log in to Reply

        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.

  • Tammie 7:18 pm on June 23, 2015 Permalink |  

    Theme review team weekly meeting notes

    The logs are here:

    Points from meeting:

    1. Directory survey: https://make.wordpress.org/themes/2015/06/22/survey-results-directory/

    • 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.

    2. Review survey: https://make.wordpress.org/themes/2015/06/22/survey-results-review/

    • Documentation is an issue. Could this be a language issue?
    • We talked about setting expectations for review time. This could be added to the uploader intro we are going to think about adding licenses to.
    • Would partial reviews be a solution, or do they cause more issues and create a bad experience?
    • Auto approving updates can speed up queues.
    • More we automate the better our queues.

    Actionables: @grappleulrich is moving the button to help with abandoned. v2 of the workflow will be put as make.blog post before our planning meeting on July 7th.

    3. Using WordPress.org themes survey: https://make.wordpress.org/themes/2015/06/22/survey-results-using-themes-from-wordpress-org/

    • We should consider in our roadmap the preview.
    • @otto42 is working on the preview and we should support what he is doing. This will bring the customizer to the front end securely. The user can then change things.
  • Tammie 10:45 pm on June 16, 2015 Permalink |  

    Theme review team weekly meeting notes

    The logs are here:

    Points from meeting:

    • Recent duplicate theme issue was talked about as raised by @otto42.
    • Proposed change: props @poena: Upload becomes ‘Add your theme’
    • Force theme uri field to be unique. Disallow same uri from being uploaded again
    • @karmatosed will make a meta ticket.
    • There will be no meeting this Thursday.
    • The doing_it_wrong theme and theme unit test are not our focus currently. Github is a good place to still add tickets though.
    • @grapplerulrich a link in the admin bar so long as not spammy we decided is valid.
    • The first meeting in July we will be a planning one.
compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc