We've talked about this quite a bit in the context of DevHub where User Contributed Notes are occasionally used as a feedback mechanism. Basically, we need a way for docs consumers to report problems or suggest edits of published documentation on .org.

The initial proposal would be to build or use something akin to ​Post Forking on the front-end of handbooks and eventually other places like DevHub or HelpHub.

Personally I don't think an MVP has to be a complete solution, it mostly needs to cover the rift drawn between moving away from the Codex where any user could edit anything to the now largely closed systems on .org.

I think starting with the handbooks would be the way to go.

Plugin and theme authors currently have the power to mark threads as resolved within their own support forum, which is great.

Problem description However, some of the larger plugin/theme shops have a support team to help out on their own support forums. I think it would be useful to be able to recognize those people in the support forums, like we’re able to recognize authors.

Proposal So what I would like to propose is adding a new role: Plugin/Theme Support. Everyone with this role should have rights to mark topics within their own support forum as resolved, and should not be affected by posting speed limitations for their own support forum. This role should also show in the forums as ‘Support’, similar to author.

The reason why I propose a new role, instead of adding the capability to the contributor role is because, in my opinion, they serve a different purpose. Let me explain.

A contributor is someone who helped your open source project forward. This can be by providing feedback, writing code, creating images, doing marketing or being a friend of the project, for example.

Someone working on support does contribute his/her (paid) time to your project and is in that way a contributor. However, I think there are more than enough valid use cases where you don’t want someone who contributed code (for example) once to be able to close support request on behalf of the author.

That’s why I think having a separate support role would be viable. It would show the community that this person is vetted and answering on behalf of the plugin/theme author.

Related ticket This proposal is related to ticket #2598.

Managing support role Of course, it should be possible for plugin authors to manage the list of support people. I see two reasonable ways to do so, which should be mutually exclusive.

One way is by adding the usernames to the readme.txt file, the same way contributors are currently added. The other way would be to add users the same way committers are currently added, on the Advanced View of the plugin.

Showing support staff To be transparent about this, we’d probably also need a place to list people in the support role. This could be the Advanced View page, or even the plugin page itself.

Replace the contents of ​https://ps.w.org/robots.txt with:

User-agent: * Disallow: /

When you leave a review for a plugin, it generates a page, like this one: ​https://wordpress.org/support/topic/really-excellent-great-awesome/.

Many of these are VERY thin (e.g., "Good plugin"). We should add meta robots noindex, follow directive when:

• There is <= 100 characters of body content, and;
• There are no replies

Profile badges don't seem to automatically appear for all areas. My core and plugins badges appeared on my profile on their own (as far as I can tell), but my Speaker badge had to be added manually with some difficulty, and my Meta badge hasn't appeared at all after getting first props a few weeks ago (see [2016]).

Hello,

While I was working on these tickets: #2100 and #2907

I've noticed that my error log was getting grumpy and I saw this error:

[22-Jul-2017 11:26:20 UTC] PHP Notice: Undefined index: consumer_key in tggr-source-twitter.php on line 152

For some reason when you view the results page on the front end the twitter module bugs out randomly ( not all times ) and after that php error all the settings are getting reset so you are losing all login information etc.

I haven't been able to find out why.

@dipeshkakadiya is on it for a solution so we can implement it on gwtd3 new website as well.

Pointers for devs: Grab the /trunk of Tagregator through svn, apply the extra patches to have the latest as they have not been implemented yet and then work on this ticket.

Hi guy's,

This is the first time I write a ticket here. Do not hesitate to give me advice if it is not the usual way to fill a ticket.

I would like to bring to your attention that there are problems about the layout on the website ​https://central.wordcamp.org/ for Opera users on Android.

Here is an example on this screenshot, but there are probably others :

I posted this info on slack yesterday and @coreymckrill recommended me filling a ticket here.

Regards, Jason

To save time and avoid typos, it would be great to support a means of that prefilling the coupon field.

For example: city.wordcamp.org/tickets?coupon=2017volunteer

Volunteers, sponsors, speakers, organizers, scholarship recipients, and others rely on coupon codes, and this would enable organizers to ensure they get the coupon code right on the first try.

On Core and Plugins Trac, UTF-8 text is displayed correctly: ​https://core.trac.wordpress.org/browser/tags/4.4.2/tests/phpunit/tests/pomo/po.php#L115 ​https://plugins.trac.wordpress.org/browser/edit-parent-comment-id/tags/0.3/edit-parent-comment-id-ru_RU.po#L24

On Themes Trac that's not the case, looks like ISO-8859-1 is the default encoding there: ​https://themes.trac.wordpress.org/browser/zalive/1.3.4/languages/ru_RU.po#L20

The description for ​Theme Check plugin appears to be parsed incorrectly (see the screenshot).

The first code sample lacks the code formatting. In the readme.txt both samples are formatted the same way:

Examples:
`define( 'TC_PRE', 'Theme Review:[[br]]
- Themes should be reviewed using "define(\'WP_DEBUG\', true);" in wp-config.php[[br]]
- Themes should be reviewed using the test data from the Theme Checklists (TC)
-----
' );`

`define( 'TC_POST', 'Feel free to make use of the contact details below if you have any questions,
comments, or feedback:[[br]]
[[br]]
* Leave a comment on this ticket[[br]]
* Send an email to the Theme Review email list[[br]]
* Use the #wordpress-themes IRC channel on Freenode.' );`

There are a couple problems with our current data set. They're not strictly related to each other, but I'm creating a single ticket for this because I'm guessing that the solution to both will be the same: switch from our current data source to a better one.

• Problem #1: Incorrect IPv4 results. No data source will be perfect, but [several online database had correct results for instances where ours weren't ​https://make.wordpress.org/core/2017/04/14/nearby-wordpress-events/#comment-32448].
• Problem #2: No IPv6 support. Without this, the results will quickly lose effectiveness. As of May 2017, ​IPv6 adoption is at 18% globally and rising relatively fast. Some countries are as high as 32%.

It looks like our database was updated recently (March 2017), but I can't find any info on where the original data comes from. @dd32, @tellyworth, do either of you know? Do you have any thoughts on other potential sources?

Implement programmatic or settings changes that can be made to /plugins/ and /themes/ to allow for individual theme or plugin pages to conform to the SEO Standards. Examples of this format will be:

(1) /themes/

• Title - ? (For example, $Theme_Name, Free $Main_Theme_Category Theme - WordPress)
• H1 - ?
• Meta Description
• ? (of note, we can not do all of the standards, we must start with the most important)

(2) /plugins/

• Title - ? - $Plugin_Name, $Main_Plugin_Category Plugin - WordPress
• H1 - ?
• Meta Description
• ?

More information on this can be found here: ​https://docs.google.com/document/d/13YxtyPNIz8798EpZT-AXh1SW2QNLGm9PBhtDJo7O16o/edit?usp=sharing

The last 8 months or so I have been working on a new WP-CLI ​18n-command that makes it easier for WordPress projects to generate POT files.

Before that, I have been using makepot.php for years, but the tool is not intuitive and really flexible. Also, with JavaScript internationalization (​#wp20491) and Gutenberg being a thing, it was clear that makepot.php wasn't the right tool for the job anymore.

Then there's also issues like #3601 and ​#wp42747 that make it harder for WordPress projects to really use makepot.php. Even for WordPress core I discovered two cases where strings were not extracted at all:

• <strong>ERROR</strong>: "Table Prefix" can only contain numbers, letters, and underscores. (source: wp-admin/setup-config.php:262)
• <strong>ERROR</strong>: "Table Prefix" must not be empty. (source: wp-admin/setup-config.php:258)

The WP-CLI command on the other hand does not have these issues.

That's why I propose switching to this new WP-CLI command for string extraction on WordPress.org infrastructure.

Some of the features:

• Automatically detects plugins and themes and extracts file headers.
• Allows extraction of only a specific text domain.
• Supports JavaScript string extraction, even for JSX and ESNext.
• Allows merging the resulting POT file with an existing one, e.g. one created by Babel.
• Powerful rules to include/exclude specific directories (minified JS files, vendor, .git folder, etc.)
• Supports extracting strings from WordPress core the same way it's done today with 4 different projects. See ​https://github.com/wp-cli/i18n-command/pull/69 for examples.
• Can warn about strings with wrong placeholders, as well as misleading or missing translator comments. This could be very useful for core but also plugin/developers to improve polyglots UX.

Also, the command is extensively tested with Behat (with PHPUnit tests for some parts planned) and is already used in ​third-party projects.

With WP-CLI being an official WordPress project and this new command being superior to makepot.php in many ways, I think we have an opportunity to consolidate lots of things here, reduce the maintenance burden, and to make it easier for people to use WordPress I18N tools and to contribute to them.

It goes without saying that I'd love to help making this a reality, even if it means adding some new features to the command or fixing nasty bugs.

I'd suggest giving this command a go locally with some plugin, theme, or core to get a feeling for it.

Since we built it with WP-CLI 2.0 in mind, which should be released tomorrow, you might need to run the following commands to install it locally:

wp cli update --nightly
wp package install wp-cli/i18n-command

Alternatively, you can check out the ​GitHub repository and run it from within its directory (still requiring WP-CLI 2.0 though).

"Skip links" are one of the most simple and better known ways to improve accessibility for keyboard users and assistive technologies users. They allow to bypass blocks of content that are repeated on multiple pages, typically: navigation menus.

They're implemented since years in WordPress core and the bundled themes. They're also part of the WCAG recommendation:

Success Criterion 2.4.1 Bypass Blocks ​https://www.w3.org/TR/WCAG21/#bypass-blocks

In order to be effective, a skip link used to bypass the top navigation needs to:

• be the first focusable element in a page
• be revealed on focus
• point to the main content in the page

Far from pretending to be a complete analysis of all the .org network pages, I've gone through the main pages linked in the main navigation menus. To recap:

• Home: no skip link
• Showcase: no skip link
• Themes: no skip link
• Plugins: skip link is not the first focusable element
• Mobile: no skip link
• Support: skip link is not the first focusable element
• Get involved (Make): no skip link
• About: skip link is not the first focusable element and it doesn't appear on focus (conflicts with clip-path: inset(50%); inherited by social-icons.css)
• Blog: no skip link
• Hosting: no skip link

I realize the .org network is made of different templates coming from different sources and I guess it's a complicated setup. However, it would be great to make sure the skip to content link is actually present in all pages and works properly.

On some locales (like Catalan), most of the translations are done by 3-4 people (with 2 of them being GTE), even if according to ​https://translate.wordpress.org/locale/ca there are 10 GTE, and almost a 100 contributors.

This is a problem not only because it simply doesn't scale (with the amount of strings that themes & plugins have, 3-4 people are not enough), but also because is extremely hard for GTEs to identify "active" contributors to help and guide them so they become one day GTE, and for contributors to find active GTE so their strings get approved and don't stay forever as pending.

Ideally, there should be a way of "filtering" the teams page (​https://make.wordpress.org/polyglots/teams/?locale=ca) with some kind of "active" filter, with active being a rule such as "has translated/reviewed more than X strings (could be 0) in the last 3-4 months".

That could help to really asses the health of a team, as you could quickly identify how many people is actively contributing to the project.

Also, if that filter included some kind of aggregated cross-project stats (similar to the ones you get "per-project" in translate.wp.org), pointing to the projects they contributed, it would be easier to "measure" the amount of contributions people is doing: I, as a GTE, am more in validating strings translated by someone who contributes regularly than strings from someone who only translated 1 string two months ago. Computing such a huge amount of stats won't be light in terms of resources, but in order to be useful, these stats don't need to be "live": a weekly update would be more than enough to get a sense of the current state.

This would also give extra visibility to the health of the team, on top of the "activeness" filter: knowing there are 100 people active when 99 of them only have translated one string isn't a sign of healthy at all.

To provide debugging information some users post their full logs in a reply. These can be up to 10k lines which makes reading the page really annoying because you have to scroll like 5 minutes.

Examples:

• ​https://wordpress.org/support/topic/qtranslate-x-compatibility-2/#post-8250157
• ​https://wordpress.org/support/topic/no-confirmation-email-received-2/#post-8235539

I suggest to prevent posting replies which have more than X chars/words/lines and to recommend using a service like Pastebin or GitHub gists.