Translate: Meta project pages do not link to their per-locale contributor pages

[motylanogha]

The per-locale contributor pages already exist for Meta projects and render correctly. Nothing links to them, so they are effectively unreachable.

What works today

​https://translate.wordpress.org/locale/pl/default/meta/wordcamp/ returns 200 and renders the full locale-project-contributors block: 54 contributors with per-project totals (iworks 424, motylanogha 277, erykosky 156, ...), plus the Translation Editors section. Identical markup to the plugin equivalent, e.g. ​https://translate.wordpress.org/locale/pl/default/wp-plugins/codepress-admin-columns/

What is missing

The project page never links there. Measured on the rendered HTML:

Page	links to /locale/...
/projects/wp-plugins/codepress-admin-columns/	410
/projects/meta/wordcamp/	0

Cause

wporg-gp-routes/inc/class-plugin.php registers wporg project pages for two families only:

GP::$router->prepend( "/projects/wp-plugins/$project", ... Routes\WP_Plugins::get_plugin_projects );
GP::$router->prepend( "/projects/wp-themes/$project",  ... Routes\WP_Themes::get_theme_projects );

Those render wporg-gp-customizations/templates/projects-wp-plugins.php, whose locale rows link to gp_url_join( 'locale', $locale, $set_slug, $project->path ) -- the contributor page.

With no equivalent route for Meta, /projects/meta/<slug>/ falls through to GlotPress core's gp-templates/project.php, whose translation-set table links each locale to gp_url_project( $project, $set->locale . '/' . $set->slug ) instead, i.e. straight into the editor. Core has no filter around that link (only gp_project_description and gp_sub_project_description exist in that template), and wporg does not override project.php.

One structural note before anyone reuses the plugin code

WP_Plugins::get_plugin_projects() is not directly reusable here. It builds its table from WHERE p.parent_project_id = $project->id, which suits wp-plugins/<slug> because that is a container over dev/stable/dev-readme/stable-readme. Meta projects are leaves: /projects/meta/wordcamp/ has 0 sub-projects and 179 locale rows of its own, 140 of them with non-zero counts. A copy of that query would return nothing.

So the data core already renders is correct; only the destination of the locale link differs.

Suggested fix

Add a Meta route plus a projects-meta.php template that renders the project's own translation sets and links each locale to locale/<locale>/<set>/<project path>, mirroring what the plugin template does. Self-contained in wporg, no change to GlotPress core, and it does not touch the wp-plugins or wp-themes pages.

Two things worth a maintainer decision:

1. Whether the locale name should link to the contributor page (matching wp-plugins) or keep linking to the editor with a separate Contributors link added. The plugin pages set the precedent for the former, but translators reaching Meta projects from /projects/ may expect the editor.
2. Whether this should instead be solved upstream, by adding a hook to GlotPress's gp-templates/project.php so any install can append per-locale links. That is the more general fix but needs a GlotPress release.

Happy to send a patch for whichever shape is preferred; I have the route and template drafted against current trunk.

[motylanogha]

Patch sent as a pull request against the mirror: ​https://github.com/WordPress/wordpress.org/pull/784

It adds Routes\Meta plus a projects-meta template rendering the same translation-set table, with the locale name linking to its contributor page. The per-status counts keep linking into the editor, so the route a translator actually uses does not change.

As noted above it deliberately does not reuse WP_Plugins::get_plugin_projects(), because that builds its table from child projects and Meta projects are leaves; a copy of that query returns an empty table.

php -l is clean on all three files and PHPCS against phpcs.xml.dist reports 0 issues on both new files. CI on the PR is green.

Not verified against a running instance: I have no translate.wordpress.org sandbox, so it is verified by reading the routing, the autoloader resolution and the core route it mirrors, rather than by loading the page. Worth someone opening /projects/meta/wordcamp/ on sandbox before it goes near production.

The two decisions from the description are still open, and both are easy to switch: contributor link vs. a separate Contributors link per row, and wporg-side route vs. an upstream GlotPress hook. Happy to redo it either way.

[ocean90]

Hello there! Could you please rephrase your request, as it's not clear what you mean?

At least ​https://translate.wordpress.org/locale/pl/default/meta/ and ​https://translate.wordpress.org/stats/ are linking to ​https://translate.wordpress.org/locale/pl/default/meta/wordcamp/.

[motylanogha]

You are right, and my summary was wrong. Sorry for the noise.

I checked both of your examples before replying:

• /locale/pl/default/meta/ links to /locale/pl/default/meta/wordcamp/ (3 occurrences, 43 links to locale meta projects on that page)
• /stats/ carries 1144 links to /locale/<locale>/default/meta/... pages

So "nothing links to them" and "effectively unreachable" are both false, and I should not have written them. What I actually measured was one page, /projects/meta/wordcamp/, and I generalised from it without checking the locale-first navigation at all. That is my mistake, not a subtlety.

What is left, stated narrowly this time

The only thing I can still show is an inconsistency between the two project-page families:

Page	links to /locale/...
/projects/wp-plugins/codepress-admin-columns/	410
/projects/meta/wordcamp/	0

A visitor coming from /projects/ can reach the contributors view for a plugin but not for a Meta project; they have to know to start from /locale/ instead. Whether that is worth any code at all is your call, and it is a much smaller claim than the one I opened with.

Given that, I am happy to close this and ​https://github.com/WordPress/wordpress.org/pull/784 as invalid, and I would rather do that than have an open ticket resting on a wrong premise. Say the word and I will close both.

If you do think the /projects/ inconsistency is worth addressing, then the shape worth discussing is probably not my patch: a hook in GlotPress's gp-templates/project.php would let any install add per-locale links, instead of wporg carrying a near-copy of that template just for Meta.

Ticket #8397 is unrelated to this one and stands on its own measurements.

[ocean90]

Thank you for the additional information, and don't worry. I'm going to close this as 'won't fix', since it's not worth changing something just for '/projects', which isn't an expected starting point for translation.