Tammie Lister 8:42 pm on October 30, 2014

Team meeting: Guidelines chat

Again to make sure it’s understood. Any term everyone or we is used in the context of the meeting. These are the notes and to get them out fast so everyone is updated they are very notelike. We are sharing all notes from every meeting so keep that in mind when you comment on these. Please respect again no names are attached and these are in note format.

Thoughts:
We should control our documentation
We have to be careful when linking to other resources.
We all have different work flows.
Recommendations are a chance for education.
Our guidelines have language that is hard and not clear.
It’s really hard as a new reviewer.
Things are easily open to interpretation which is bad.

In light of this, we went through every guideline and have grouped them into required, recommended. We also have refined and clarified some guidelines. This was a very long process as you can imagine, but worthwhile. We methodically went through to create this new proposed list.

REQUIRED proposed are:

[ New guideline ] 1 Unique slug – text domain. Before this wasn’t just 1.
[ New guideline ] Files: Index.php and style.css is all that a theme needs. This removes comments.php from that list.
[ New guideline ] Theme names must not use: WordPress, Theme. This has everything else removed as a must.
Themes are to use WordPress functionality and features and first. [ wording needs refinement ] [ Link to make themes handbook on how to make a theme ]
No analytics or tracking
No hard coding of scripts, styles and favicons
Themes are required to save options in a single array
Themes are required to use sane defaults and must not write default setting values to the database [ wording needs refinement ]
Everything must be sanitised. [ link to what that means ]
Themes are required to be 100% GPLGPL GPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. This means that derivative work can only be distributed under the same license terms. This is in distinction to permissive free software licenses, of which the BSD license and the MIT License are widely used examples. licensed or use a GPL compatible license. [ link to expanded information – entire section about license, copyright ]
If the theme adds a footer credit link, it can only have one singular use.
If you are a themeshop you should be selling under GPL to be in the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ repo.
No theme should have a pay wall restricting any WordPress feature.
Screenshot.png should be a real image not a logo or mockup.

REQUIRED that can be automated will be – automation through theme check pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party:

No shortcodes, no custom post types and no custom taxonomies [automated]
No removing or modifying non-presentational hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. [ rewording ] [automated]
Disabling the admin tool bar [ automated ]
Don’t mention in guidelines but automate to not have Timthumb [automated]
Theme settings page under appearance [ automated]
Themes required to use edit theme options [ automated ] – coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functionality correctly.
Themes are required to declare their license explicitly using the license and license uri headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. slugs to style.css [automated]

— The above guidelines are the only required now.

RECOMMEND:

Backwards compatibility
Theme documentation
AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)
Documentation put all in recommended and have it’s own page
Each recommended will have it’s own page and be expanded on there. Language needs to be simplified too.

SUGGESTED GUIDELINES TO REMOVE:

Run through theme check
Front facing in English
Presentation versus functionality: plugin territory
WP generated CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. files
Licensing, theme name and upsell
Obsolesce
Themes must have a screenshot.png
Remove comments.php as a requirement
Content sharing buttons and links
No compression of scripts or files

CASE BY CASE – the case by case review will become more important as we reduce the guidelines:

Theme name
Presentation versus functionality: plugin territory
Security and privacy
Licensing, theme name and upsell
Custom widgets
Theme credit links have to be appropriate – SEO, spam

WORKFLOW PAGE – new addition:

Theme unit test
Theme check plugin

Being a good theme citizen page – new addition:

A section that has about support and dos and donts

Here are the actionables:

Remove the use of guidelines and use the term review. When you land the first page is required then recommended will be linked in sections.
After feedback here the documentation will be adjusted to reflect what is outlined.
Create all the extra pages and refine the language of the other pages.

Julie Kuehl 8:49 pm on October 30, 2014

This is fantastic. Excellent work team!
Ulrich 9:11 pm on October 30, 2014
Everything looks goods. I do not fully agree with these four points. I have added my comments behind the points.

REQUIRED proposed are:
- [ New guideline ] 1 Unique slug – text domain. // There are PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. libraries where it makes sense for them to have their own translations e.g. Hybrid CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. I would rather require the text domain be the theme slug
- No hard coding of scripts, styles and favicons // We should not forget the exception of scripts that should only load in IE.
SUGGESTED GUIDELINES TO REMOVE:
- Front facing in English // What is the reasoning behind this?
- No compression of scripts or files // We should change to guideline to require a non minified version.
- Frank Klein 9:41 pm on October 30, 2014
  
  The problem with having minified versions is that you cannot really be sure that the non minified version corresponds to the minified one.
  
  I think that the performance benefits of minified scripts is hugely overrated. If you value speed, then you are on hosting that takes care of concatenating and minifying all scripts and styles, often combined with delivery through a CDN. If you just want to host on the cheap, then the supposed speed loss from serving unminified stylesheets and JavascriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. is the last of your problems.
  
  I consider that security is paramount. Minified scripts are very difficult to review, so we should not allow them.
  - Justin Tadlock 9:45 pm on October 30, 2014
    
    Note that compression != minification. We had this discussion already: https://lists.wordpress.org/pipermail/theme-reviewers/2013-June/013571.html
    - Frank Klein 9:50 pm on October 30, 2014
      
      I think that the guideline relates to keeping scripts and styles in a human readable format. With minification, you remove all the things that make code easier for humans to read.
      - Justin Tadlock 9:53 pm on October 30, 2014
        
        Minification is human-readable format. It’s just hard to read. We’ve already had the discussion on the matter though, as per the link above. I just wanted to clarify that the guideline about “compression” does not apply to minified files.
  - Ulrich 10:37 pm on October 30, 2014
    
    @frank-klein I was commenting to the post where it was a suggested guideline to remove. I was not recommending to remove it even though I think it should be allowed. We should not have the theme review guidelines so strict and then let plugins do nearly everything.
    - Frank Klein 11:58 am on October 31, 2014
      
      I agree that this guideline shouldn’t be removed, but I actually wanted to express that I think that this guideline does not go far enough.
      
      JavascriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. files should be in their original format, no minification or compression. Allowing Javascript files that are different to the development version (as in the code that developers use to work on it) is yesterday’s thinking.
      
      Javascript is no longer an after thought or something to add bells and whistles. When I review a theme, I go through Javascript files the same way I review PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. files. I look for malicious code, unprefixed variables and functions living in the global namespace, incorrect usage of jQuery’s $ and so on.
      
      You cannot do this with code that’s less than optimal to read. Bundling unminified files along with the minified files does not solve the problem. It would require the reviewer to check whether both versions are the same and good luck with reviewing diffs for a minified file.
      
      So to sum up:
      
      For users minified or compressed files have little benefit.
      
      For reviewers minified or compressed files make it a lot harder to make sure this is good code.
      
      For developers it doesn’t really matter what version of a file you ship.
      
      So unless I’m missing something here, disallowing minification and compression seems like a no brainer.
      - Ulrich 3:01 pm on November 7, 2014
        
        I look for malicious code, unprefixed variables and functions living in the global namespace, incorrect usage of jQuery’s $ and so on.
        
        Do you have any recommended resources I read up on?
      - wpweaver 12:13 am on November 11, 2014
        
        Whether or not minifying makes a site measurably faster or not, there is a HUGE perception by people with WP sites that it is critical to have CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site. and script files minimized. So this leads to two problems:
        1. Users demand that files be minimized.
        2. There are plugins that will minimize on the fly. Not always correctly!
        
        So I think it is essential to allow minified files to be used by the theme at runtime to meet these two very real issues. Make the customer happy and be sure some pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party doesn’t break the theme with bad minimization.
        
        If there is a real concern about someone trying to sneak in a minimized script that is different than the full version, it could be a requirement that to include minimized files that a common minimizer be required – then it is easy to check the .min version is really from the provided full size source.
      - Justin Tadlock 6:14 pm on November 11, 2014
        
        @wpweaver – We’ve decided to allow minifying as long as you include the dev copy. Many of us had some of the same concerns as you.
- Justin Tadlock 9:49 pm on October 30, 2014
  
  [ New guideline ] 1 Unique slug – text domain. // There are PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. libraries where it makes sense for them to have their own translations e.g. Hybrid CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. I would rather require the text domain be the theme slug
  
  This is the third time we’ve brought this up. This is a blocker for any PHP library with its own textdomain.
  - Frank Klein 9:56 pm on October 30, 2014
    
    Which can be problematic if the library does not correctly handle this. This then requires reviewers to go into that library and review the code to see whether it does this correctly or not. Which I consider goes beyond the scope of a theme review, because it requires more in depth knowledge.
    
    But I think it touches on a more general issue of whether we consider libraries to be part of the theme or not. In my opinion, when you bundle it, its part of the theme. So the same rules apply.
    - Justin Tadlock 10:09 pm on October 30, 2014
      
      It’s not that hard to take a look at it. It’s much easier than going through the 1,000s of lines of crap theme options page code that we routinely go through. I’ll even volunteer myself for doing this with every library we come across if needed.
      
      There’s not much point in using a library if a theme author must alter the library code. If we need to vet some libraries for handling textdomains, I’m OK with that. Let’s talk solutions.
      
      I don’t think there’s an issue with whether we consider libraries to be part of a theme. It seems pretty straightforward to me. They’re within the theme folder. Therefore, they are a part of the theme. That shouldn’t even be a question. We currently and have always in the past reviewed themes as a whole. There’s no need to change that.
      - daveshine (David Decker) 10:20 pm on October 30, 2014
        
        Let’s talk solutions.
        
        Absolutely, that’s the whole point here! You have already an awesome solution in place in “Hybrid CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.”. This should be the base, imho.
    - daveshine (David Decker) 10:18 pm on October 30, 2014
      
      “Hybrid CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.” for example already has done all the hard work to ensure only one textdomain is needed for translation in the end. There should be an exception of the general rule for this library, please.
      
      Otherwise, I am all in for 1 unique textdomain which is the theme’s slug – and I proposed this everywhere.
    - Ulrich 10:29 pm on October 30, 2014
      
      I am happy to review any php library for correct internationalization. Simply pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
  - daveshine (David Decker) 10:15 pm on October 30, 2014
    
    Absolutely, there needs to be at least the exception for “Hybrid CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.”! You did so many awesome work over the years, it would be very sad to see such a blocker take this away!
  - Samuel Wood (Otto) 10:45 pm on October 30, 2014
    
    This is the third time we’ve brought this up. This is a blocker for any PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. library with its own textdomain.
    
    It keeps coming up because we’ve been trying to warn you about it for years. I spoke on this at WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe in 2013. I wrote about it on my blog two years ago. This should not be a surprise or news to you.
    
    This is very soon going to be a blocker with themes and plugins getting translation support from the main system at translate.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/.
    
    A theme or a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party in our directory needs to a) use one text domain and b) have that text domain be identical to the slug of the theme/plugin.
    
    This is not a negotiable item. If we want to truly support translation and internationalization for all users, and all the code that we’re hosting, then this is a requirement.
    
    You have two options. Don’t put text domains in libraries, or search/replace them. Themes need to be held to a standard. One theme, one text domain. Same for plugins.
    
    If you use a separate text-domain for the library, then you will get to the interesting result where none of the library code gets translated properly because the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. cannot automatically download the translations for it.
    - Ulrich 10:52 pm on October 30, 2014
      
      The PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. library can shipped with the translations and for that reason there is no need for translators to have to translate all of the same strings for all of themes where it comes across.
      
      Why can’t we have modular code and translation?
      
      If a theme developer is managing their translations then why force them to use the main system?
      - Samuel Wood (Otto) 10:58 pm on October 30, 2014
        
        Nobody is being forced to use the new system… If you include and load your own translations, more power to you. They will still work.
        
        But the new system will be used for all code in the directory regardless of what else it includes. If you don’t include a translation for a particular language, then it will check the api to see if somebody has one and it will use that if it finds it. All code will be available to translate. I expect that within a couple years, we’ll want to start eliminating code that doesn’t handle translation correctly.
        
        And this doesn’t lead to duplicated work. A library used by many people will share all the same phrases, those phrases only need to be translated once, not many times. Saves on effort all around.
        
        Like it or not, the next space for WordPress to expand into is global, and we need better language support all around. This is going to happen, one way or another.
      - Ulrich 3:21 pm on October 31, 2014
        
        @otto – We can add this as recommended at the moment and discuss making it required once everything is in place and Glotpress has a way to automatically automatically translate strings based off previous translations.
        
        It would be good to allow the theme developers some play-room if they are managing their own translations not to have to use a single text domain.
    - Justin Tadlock 11:01 pm on October 30, 2014
      
      This is the first time we’ve actually gotten any replies on this specific subject when we bring it up.
      
      I’ve been preaching internationalization for years myself. Over half of my theme users for the past several years have been non-English speakers. I’m well aware of how awesome translation support is. I’ve been supporting it a lot longer than most other theme authors.
      
      All I and others are asking for is to sit down and discuss this. We’re trying to work within the system.
      - Samuel Wood (Otto) 11:06 pm on October 30, 2014
        
        Happy to discuss it. I’m on a plane right now, but I’ll be back at home tomorrow and on the SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. as well.
        
        The technical details are not complicated, really. The code to do this has been in the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. quite a while. It’s been building towards it for almost 2 years. It’s finally happening, and frankly it’s about time.
        
        But “the system” still requires some base level functionality. It is not unreasonable for a theme to use a single text domain, so that the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. can find the translations based on that text domain, and load that text domain from a file which is named the same as that text domain… see where I’m at here? What you propose is a much more complex problem, leading to a free-for-all.
        
        It’s great that your themes and libraries are translated. I’d like to translate *everything*, not just those by authors who put in a whole lot of effort. I’d like translations to happen for those people who also put in minimal to no effort.
      - Justin Tadlock 1:07 am on October 31, 2014
        
        Okay. When you get a moment, here’s a few of my thoughts. I can explain things in more detail if needed.
        
        The subject is whether we should allow libraries (frameworks, scripts, whatever you want to call them) to use a custom textdomain while being packaged within a theme. I can’t speak about other libraries because I don’t know what they’re doing. This is going to be strictly from the perspective of using mine (Hybrid CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.).
        
        From a code perspective, I’ve found two ways to handle a library with a custom textdomain:
        
        1) Merge the library’s textdomain with the theme’s textdomain when the MO file is loaded (can’t remember the hook offhand). This is the method that I use. It allows themes to load a single MO file like normal. This method also works with the WP makepot.php tool. Creating a POT file with this works fine. I’ve been doing it quite a while.
        
        2) Have the library load its own MO file using the load_textdomain() function. I haven’t tried this, but I don’t believe that this will play nicely with the WP makepot.php tool. It can’t distinguish between the different textdomains within the theme and would add all strings to the theme’s POT. I imagine this would be problematic with automated tools.
        
        This is an issue I and others have spent a considerable amount of time working out because I wanted to make translating as simple as possible while providing a library for theme authors to work with. In fact, it’s assumed out of the box that any theme using my library will be fully internationalized. That’s how passionate I am about translating.
        
        As much as I’ve tried, it’s not realistic to remove all the text strings from the library. Some are just necessary. Having theme authors do a search/replace on all the textdomains kind of defeats the purpose of using the library. They shouldn’t have to worry if it meets WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ standards; I consider that my job.
        
        I’m wide open to suggestions for improving my current method. It’s the best that I could do given my current skillset.
      - Samuel Wood (Otto) 4:53 am on October 31, 2014
        
        Okay Justin, I’ll give you my quick perspective and explain a bit about how the new system will work. You may already know some of this.
        
        First, we’re treating themes/plugins as single units. So from the .org perspective, it’s a single “package”.
        
        Now, if you have examined the changes in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., you’ll notice two functions: load_plugin_textdomain and load_theme_textdomain. Both of these will load from wherever you include your language files, but they have a fallback to loading from the /wp-content/langs/(plugins|themes) directory. This is where the automation comes in.
        
        Examine some of the core plugins already over on translate.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. I know, GlotPress isn’t pretty. But the way it works is that a POT file is built using the core tools, the POT is loaded in there, and then translators can translate. All the translations are stored in the DB.
        
        Now, the POT file contains all the strings in the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme. It does not care about textdomain. We’re pulling all the strings, loading them up, translating them, and then, at the end, we will take those translations and build po/mo’s.
        
        Again, nowhere in this process is text-domain.
        
        So, to get those mo files to users in an automated fashion, core checks the api, and when an updated translation is available for plugin/theme-slug and the language the user uses, then it downloads the new mo file and sticks it in that /langs/(plugins|themes) directory.
        
        Thus, that fallback in load_plugin_textdomain and load_theme_textdomain will find it, load it, use it.
        
        So, the text-domain not only has to match the slug, because that’s what we’re using for an identifier and the naming scheme to keep things sane and separate, but it also has to cover the whole package and everything in it. We’re working with whole packages here, not partial ones. If you use a different text-domain in part of your code, then it won’t match the slug, and the translations in that mo file won’t be used.
        
        By using any text-domain other than the plugin/theme slug, for any reason, you break the whole process. We can’t send translations anymore. You can certainly continue to manage translations yourself, and include them with the theme. But you won’t get the translations from people on translate.wordpress.org, and you won’t get automated updates when translations get corrected.
        
        The goal here is to let the community handle the translations without the plugin/theme author having to either worry about it and without them having to do explicit updates just to get new translations to their users. With this system, translations (mo files) can be completely separated from the package in question. They can be updated and corrected without updating the package. They live in their own folders. People can eventually see the admin dashboard in their language, and if some plugin isn’t in their language, then they can submit the translations to a central location and, after suitable moderation, have those sent to all that plugin’s users who are also using that language. Crowdsource the translations, basically.
        
        You could possibly do some munging with how the mo files are loaded in your library and fiddling around with the text-domain that way. Might work. My suggestion is search/replace. Maybe it might be better to move all your strings into a central file to make changing the text-domain via a simple search/replace operation much easier for theme authors.
      - Justin Tadlock 2:09 pm on October 31, 2014
        
        Otto, it really sounds like we’re on the same page to me.
        
        Now, the POT file contains all the strings in the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party/theme. It does not care about textdomain. We’re pulling all the strings, loading them up, translating them, and then, at the end, we will take those translations and build po/mo’s.
        
        Again, nowhere in this process is text-domain…
        
        That’s exactly how I thought it works. Textdomain doesn’t matter with automation. The textdomain matters when the theme is up and running. All the strings are loaded up regardless of the textdomain. That’s good.
        
        If you use a different text-domain in part of your code, then it won’t match the slug, and the translations in that mo file won’t be used…You could possibly do some munging with how the mo files are loaded in your library and fiddling around with the text-domain that way. Might work.
        
        Doing it that way definitely works. That’s the specific situation I’m trying to make a case for. I’d even be happy to volunteer one of my themes for testing if it helps.
      - Samuel Wood (Otto) 3:04 pm on October 31, 2014
        
        Doing it that way definitely works. That’s the specific situation I’m trying to make a case for. I’d even be happy to volunteer one of my themes for testing if it helps.
        
        Yes, I understand that there is probably some way to do it in code. It’s very likely not future proof and prone to breakage at some point down the line (years), but it can be done.
        
        On the other hand, you can load up a good text editor, and take a few seconds to search/replace ‘library-textdomain’ with ‘theme-name-textdomain’ and you’re done.
        
        Why are you so opposed to having the theme just have a single domain defined in it? I understand if you really the library to go unmodified for some reason, but it’s pretty easy to just put all the strings in your library into a single file and then that single file can be the only modified one.
        
        Making a code-based solution seems error prone to me. I’m sure it can work, but I’m not sure that it’s the correct approach.
      - Justin Tadlock 3:32 pm on October 31, 2014
        
        Why are you so opposed to having the theme just have a single domain defined in it? I understand if you really the library to go unmodified for some reason, but it’s pretty easy to just put all the strings in your library into a single file and then that single file can be the only modified one.
        
        I’m not opposed to themes having a single domain defined. Generally speaking, I think it’s a great idea.
        
        It just makes it hard for theme authors who are managing multiple themes with a single library. More often than not, they’re pulling in the library as something like a GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. sub-module or using Composer to manage dependencies. Every time they pull in an update, they have to alter the files.
        
        That’ll be me telling them, “Oh, by the way, any time you want to add a theme to WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, you are required to alter the library’s code.” I already have hard enough time convincing some of them to submit their work to WordPress.org. This is the one thing I’ve always prided myself on: my stuff passes the WordPress.org theme review guidelines out of the box.
        
        Making a code-based solution seems error prone to me. I’m sure it can work, but I’m not sure that it’s the correct approach.
        
        Can you just trust that I’ll make sure it continues working without errors? All I’m really asking for here is to consider an exception to the proposed guideline: “1 Unique slug – text domain. Before this wasn’t just 1.” I’m not asking for anything to change on WordPress.org, in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. WP, or for anyone else to have to do any extra work. I’ll make sure the themes using my library work within the system.
- Samuel Wood (Otto) 11:16 pm on October 30, 2014
  
  We should not forget the exception of scripts that should only load in IE.
  
  Agreed, there are specific cases where direct scripts in headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. are still necessary, unless coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. finally adds JS conditional support.
  
  Front facing in English // What is the reasoning behind this?
  
  Wider inclusion. Requiring people to write in English and then translate it to other languages makes little sense when it’s just as easy to write it in other languages and translate it back to English. No language is special, translate all the things.
  
  No compression of scripts or files // We should change to guideline to require a non minified version.
  
  Minification is fairly pointless. I’d be okay with just disallowing it except for cases where the upstream library actually is pre-minified.
  - Ulrich 3:13 pm on October 31, 2014
    
    It nice to see a change in view of allowing the themes to be in other languages. It should be possible to create an English translation using the new system that is coming in the future?
    
    Perhaps we could still recommend that the front facing text is in English as it is most likely easier for people to translate from English then another language.
    - Samuel Wood (Otto) 8:03 pm on October 31, 2014
      
      A lot of the proposed system is still up in the air. Nacin’s talk mentioned that we’d be putting like 25 or so of the major plugins into translate before the end of the year, to shake out the bugs. Sometime in the coming year, everything gets put over there. In GlotPress, English is just “en_US” or “en_CA” or “en_GB” or what have you. It’s not special, as such. So there’s no technical reason that a theme can’t be in, say, German and then have an en_US language pack for it which gets downloaded.
      
      Now, it’s true that a lot of the system is assuming English as the default currently, so there’s probably more changes to be made on that score. So yes, recommended is still English by default. But not all developers know English and they really shouldn’t have to. Part of the overall idea is to have listings of plugins/themes on their own sites. So a theme that has been translated to German would be shown in the listings on de.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/.
      
      Some of the code has been written to handle this. If you visit https://wordpress.org/themes/twentyfourteen you’ll notice a “Languages” list at the bottom of the description. That’s not in the theme, that’s generated by .org due to the translate system. We will know what languages a package is available in and be able to display things most appropriate to the viewer based on it. That’s the overall goal.
Sandy 1:23 pm on October 31, 2014

Thanks for full guide almost cover everything.
Frank Klein 8:25 pm on November 3, 2014

I got another proposition for a guidelines:

Themes should use either the Settings APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. or the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. for implementing theme options.
Themes are recommended to use the Customizer to implement theme options.
Themes should not directly access the file system (via WP_Filesystem or any other means).
codeinwp 3:51 pm on November 4, 2014

Improving documentation and processes for new reviewers is a long-term solution and is a good one, however for the next months we will still have 4 months queues in case you got your ticket re-opened or 2 months if not, which is quite hard to handle.

A short-term solution that I see is the same that worked for months here, to motivate theme reviewers. A solution can be that every reviewer with 2+ reviews in a month can vote a theme ( can be his own ) which can be randomly selected as a featured theme, in this way we can motivate new people to try to be a reviewer .

Other idea is to change featured themes weekly, thing that will allow more people to benefit on this.

I think that somehow people need to be motivated and the motivation to be clear, otherwise people will try other things to gain advantage like : review their themes with other accounts or form partnerships with other reviewers to quicker review each other themes or automattic will end up paying people to be reviewers etc etc

Welcome to the Themes team!

Handbooks and review requirements

Coding standards and plugins

Code Packages

Communication