[wp-meta] [Making WordPress.org] #8161: Wrong path used when determining project translation status.
Making WordPress.org
noreply at wordpress.org
Wed Jan 28 15:31:45 UTC 2026
#8161: Wrong path used when determining project translation status.
--------------------------------------+-----------------------
Reporter: sdnunca | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone:
Component: Translate Site & Plugins | Keywords: has-patch
--------------------------------------+-----------------------
` https://translate.wordpress.org/projects/wp-plugins/<plugin>` accepts
case insensitive slugs, e.g.
both https://translate.wordpress.org/projects/wp-plugins/akismet/ and
https://translate.wordpress.org/projects/wp-plugins/AkisMet/ return 200.
However, https://translate.wordpress.org/projects/wp-plugins/AkisMet/
reports:
```
This plugin is not properly prepared for localization.
```
and returns no translation status data.
When determining if a project exists, we use `$project_path` e.g. `wp-
plugins/AkisMet`. Because of the case insensitive collation, this matches
the project with the actual path of `wp-plugins/akismet`.
To determine if a plugin is prepared for localization, we look at its
subprojects and detemine if it has either a `dev` or a `stable`
subproject.
To determine the subproject names we use:
```
$sub_project = str_replace( "$project_path/", '', $set->path );
```
This patch updates the replace logic to use `$project->path` instead of
the case insensitive `$project_path`, making sure the subproject name is
determined correctly.
--
Ticket URL: <https://meta.trac.wordpress.org/ticket/8161>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org
More information about the wp-meta
mailing list