Make WordPress Core

Opened 20 months ago

Last modified 14 months ago

#26746 new enhancement

Avoid translating several times post type and taxonomy default labels

Reported by: Chouby Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0
Component: Posts, Post Types Keywords: has-patch
Focuses: performance Cc:


get_taxonomy_labels and get_post_type_labels translate default labels each time register_post_type and register_taxonomy are called. This is useless and is a rather expensive process resulting in a performance loss.

Attachments (3)

26746.patch (5.6 KB) - added by Chouby 20 months ago.
26746.2.patch (5.9 KB) - added by Chouby 18 months ago.
26746.3.patch (6.9 KB) - added by SergeyBiryukov 16 months ago.

Download all attachments as: .zip

Change History (11)

@Chouby20 months ago

comment:1 @Chouby20 months ago

  • Keywords has-patch added

comment:2 @nacin20 months ago

  • Component changed from Performance to Post Types
  • Focuses performance added
  • Milestone changed from Awaiting Review to 3.9

comment:3 @nacin18 months ago

  • Keywords needs-patch added; has-patch removed
  • Milestone changed from 3.9 to Future Release

I'm all for performance improvements here but, as written, this will break translations. Right now core post types and taxonomies are loaded twice, and the first time is before translations are loaded. These would thus always be in English.

A lesser concern could be someone switching between languages (such as each language being a post type), but they're likely going to have their own strings/labels, so it's not as big of a deal and probably an edge case.

@Chouby18 months ago

comment:4 @Chouby18 months ago

Yes you are right. It breaks translations. So we can't do that before the default textdomain is loaded. In the second patch, I propose to wait for the 'init' action. The benefit would not be so high for a default WordPress install, but could still be interesting for an install with lot of custom post types and taxonomies (provided that they are registered in an init action as recommended).

@SergeyBiryukov16 months ago

comment:5 @SergeyBiryukov16 months ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from Future Release to 4.0

26746.2.patch works as expected for me. Refreshed, moving for 4.0 consideration.

comment:6 @Rarst16 months ago

I think this can be pushed further. The current state without patch is regenerating labels on every call. The current patch will regenerate labels on every call until did_action('init') state change.

Then why don't we generate labels once before and once after state change?

Also timing-wise locale is available tad earlier than init at after_setup_theme, makes sense to check for that one instead in case CPTs are already getting registered in third party code.

comment:7 @ircbot14 months ago

This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.

comment:8 @SergeyBiryukov14 months ago

  • Milestone changed from 4.0 to Future Release
Note: See TracTickets for help on using tickets.