Please make sure to update to WPML 4.3.6 and check our list of Known Issues before reporting

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.


This topic contains 2 replies, has 3 voices.

Last updated by Kevin 10 months ago.

Assigned support staff: Diego Pereira.

Author Posts
March 24, 2019 at 3:47 am #3447761


Is there a way to use WP-CLI to set one post ID as a translation of another? Is there information somewhere about WPML's support for WP-CLI?

March 25, 2019 at 12:57 pm #3453669

Diego Pereira

Languages: English (English ) Spanish (Español ) Portuguese (Brazil) (Português )

Timezone: America/Sao_Paulo (GMT-03:00)

Hello @miked-5, welcome to the WPML support Forum!

Unfortunately we currently do not have specific features of WP-CLI for WPML. You can make a request for new features through this page:

If you need more help just let me know.

All the best,

July 31, 2019 at 2:06 am #4310923


You'd have to write your own wp-cli commands.

Another approach is using the wp-rest api, such as exposing a custom endpoint that's open to authorized users only.

I've come up with solutions in the past that programmatically link translations. Here's a few snippets of the "meat" of a working approach (which was implemented as a custom endpoint) so you and whomever else can save time hunting around.

The idea is the custom command (or REST API call) is given the WPML post type / object type, primary object (e.g. post) ID, secondary object (e.g. post) ID, and the language of the secondary object (e.g. post) ID.

First, WPML's get_element_trid() function is called to get the primary object's WPML translation ID aka "trid".

Next, WPML's set_element_language_details() function is called to associate the secondary object with the trid and the language that it corresponds to.

Start by accessing the global $sitepress and collecting your inputs:

      global $sitepress;
      $objectType = 'post_' . $params['post_type'];
      $secondaryLanguage = trim($params['lang']);

Next, you'll probably want to add error handling to the following, e.g. place in a try block and catch/handle potential errors:

        $trid = $sitepress->get_element_trid( $params['primary'], $objectType );
        $sitepress->set_element_language_details( $params['secondary'], $objectType, $trid, $secondaryLanguage );
        return rest_ensure_response( [ 'SUCCESS' => true, 'params' => $params, 'trid' => $trid ] );

Be careful to use the WPML objectTypes as they are ever so slightly different than WordPress native types. You can find them in the docs. You can see in the above code how it assembles the WPML type e.g. 'post_post' and 'post_page' if passed 'post' or 'page' respectively. The above snippet is from a past project where these were the only relevant options, but you may have different requirements.