This week’s agenda is going to be firming…

This week’s agenda is going to be firming up some requirements and recommendations.

We’ll meet at 18:00 UTC Tuesday in #themereview on Slack. Find out more about joining Slack here:

Both of these requirements are not a matter of bringing new things in, it’s a matter of tidying up our language and being clear with what we mean. We should be looking to do this for any area that is ambiguous or has assumptions that reviewers know things.

  • Languages.

We currently have the following language requirements regarding wrapping and text:

All front-facing strings should be translatable.
Must use a single unique theme slug – as the theme slug appears in style.css. If it uses a framework then no more than 2 unique slugs.
Can use any language for front facing text. However, they should only use the same one for all text.

These are a little ambiguous and need moulding into one solid statement. They also raise a few issues:
1. What is front-facing and what is a better definition as it’s not a common phrase?
2. Do we only apply this to the theme and not admin panel unless translation-ready tag?
3. If it’s all what implication does the translation-ready tag have? Is it no longer valid?
4. If we agree that allowing different languages is important, why not include any text no matter where it’s output?
Lets get a firm sentence we can all stand by for all themes.

  • ABSPATH and linking to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. files.

If we agree that ABSPATH shouldn’t be used. How do we deal with linking to core files and checking plugins? For example:
Should this be the only exception and clearly documented? is one example of someone using it.
How do themes load things just for plugins? Should they only rely on add_theme_support? What about cases that don’t have this.
Lets get a firm sentence we can all stand by for all themes.

If you’ve got anything else you want added to agenda let us know in the comments.