[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