WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 3 years ago

#40298 new defect (bug)

Translated custom post type archive slug is in user language, not site language

Reported by: docflo Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.7.3
Component: I18N Keywords:
Focuses: template Cc:
PR Number:

Description

Tried to do a search, got "OperationalError: (1040, 'Too many connections')" so: sorry if this is a dupe.

I have a custom post type "event". In my register_post_type call I have

       'slug' => _x( 'events', 'events slug', 'domain' ),

In my Dutch translation file I translate 'events' as 'agenda'.
My user has the interface language set to English.

When I change the site language from English to Dutch and flush the permalinks my single events all have the correct slug ("/agenda/single-post-slug").
However the custom post type archive remains available under the old slug "/events/". The new slug "/agenda/" results in a 404.

The "solution" is to change the user account's interface language to Dutch and flush the permalinks. Now the custom post type archive is available under the slug "/agenda/".

This seems wrong and could lead to inadvertent changes of the URL for a cpt-archive. I would expect the cpt-archive to follow the site language, just like the single posts do.

Change History (1)

#1 @Chouby
3 years ago

IMHO, you must not internationalize CPT slugs bases. WordPress has no slug base for CPT but it has for taxonomies (categories, tags and post formats), and you'll see that they are not internationalized. See https://github.com/WordPress/WordPress/blob/4.7.3/wp-includes/taxonomy.php#L38-L53

The reason is exactly the kind of issue you are running in. A CPT slug base must never change on your site. If you are writing a plugin, the translations may not be available first. So the slug base will be 'events'. Then at some point, the translations will become available and the slug base will become 'translated_events' changing all the corresponding urls.

If you want to allow the customization of your custom post type slug base, the best is to do as done by WordPress for categories and tags and provide an option. If this is for a unique project, you can just hardcode it in your language.

Last edited 3 years ago by Chouby (previous) (diff)
Note: See TracTickets for help on using tickets.