• Resolved Michel Jongbloed



    I’m a developer of the WooCommerce Google Feed Manager plugin (https://wordpress.org/plugins/wp-product-feed-manager/) and I’m having an issue with making our plugin compatible with yours. I thought we had this working, but after a user contacted us reporting that our plugin fails to translate products in our feed, I tested it on my own test server and it indeed does not seem to work (anymore).

    I’m using your trp_translate function to translate product information like title (post_title), description (post_content) and post_excerpt. On my test server I’ve set up TranslatePress with English (United States) as the Default language and Dutch as a second language. I translated several products in the shop to Dutch and in the shop this works great, I can switch between both languages.

    But when I try to generate a feed with these translated products, the trp_translate function keeps returning the product details in English, even though I input the language as “nl_NL”.

    When I take a deeper dive in the code I noticed that in the trp_translate function the global variable $TRP_LANGUAGE keeps the “us_US” value, even though it is set tot “nl_NL” in row 718. I even tried to force the $TRP_LANGUAGE variable to “nl_NL” just before the translate_page function is called (row 721), but even then my debugger reports that $TRP_LANGUAGE is stil “us_US”.

    Any ideas what I’m doing wrong here?

Viewing 9 replies - 1 through 9 (of 9 total)
  • Plugin Support Anca


    Hello Michel,

    Thank you for reaching out to us!

    The only thing that we can think of is that you didn’t serve the language in which you want to have the text translated. It’s the second parameter.

    Can you send us the exact code you use when you translate the title or the content?

    Kind Regards,


    Thread Starter Michel Jongbloed


    Hi Anca,

    Thanks for your reply.

    I’m certain I entered the language code as second parameter to the function. But I also think I know what is going wrong.

    I think the $TRP_LANGUAGE variable gets set by the language code it gets from the active url. When using the trp_translate function on a webpage, that works fine. But I’m not using this function on a page. In my case I use the trp_translate function in a background process. I’m using this function to generate an xml product feed and that process runs in a background mode, so without a specific webpage or url.

    But in the mean time I also found the trp_switch_language and trp_restore_language functions and that seems to work now, although not all the time. I now use the following code:

    public function get_translated_product( $product, $language ) {
       global $TRP_LANGUAGE;
       if ( $language === $TRP_LANGUAGE ) {
          return $product;
       trp_switch_language( $language );
       $title = trp_translate( $product->post_title, $language, false );
       $description = trp_translate( $product->post_content, $language, false );
       $excerpt = isset( $product->post_excerpt ) ? trp_translate( $product->post_excerpt, $language, false ) : '';
       if ( $title ) {
          $translated_product = new stdClass();
          $translated_product->ID = $product->ID;
          $translated_product->post_title = $title;
          $translated_product->post_content = $description;
          $translated_product->post_excerpt = $excerpt;
          return $translated_product;
       } else {
          return $product;

    One of our users reported issues with our plugin while using TranslatePress and using the function above he gets correct translations for his products most of the time, but not always. His main TP language is English and he uses Polish as a second language. Using the function above with the Polish language selected, returns the correct title and most of the time the correct description, but some descriptions are still in English.

    I’m still trying to find out what differentiates the products that can’t translate the descriptions. I’ll keep you updated. If you have any thoughts that would be great.

    Best regards,


    Plugin Author Cristian Antohe


    Hi Michael, yes, that would make sense.

    Since the title is translated all the time (at least that’s what I understood) it’s possible the description in the xml is different then the description rendered by the theme. Meaning we don’t have a translation for that xml description.

    Usually this happens with excerpts, where the_content is translated, but the excerpt is not, since it cuts around 250 characters, making that excerpt string a different string, without a translation as far as TranslatePress is concerned.

    If the differences are small between the description in the front-end and the ones in the xml, the client can activate automatic translation memory from TranslatePress -> Settings -> Advanced -> Miscelanious -> Automatic Translation Memory

    It will serve the same translation for different strings, if those two original strings are close enough in similarity. Works well for typos and very small changes (2-3 characters for example)

    Thread Starter Michel Jongbloed


    Hi @sareiodata,

    The user is still complaining that some of his products are not translating to Polish in the feed, whilst they do show the Polish translations on his website.

    Is there any other function besides trp_translate that I can use to translate an existing text to a specified language without having access to a specific url?

    Or do you know of any setting in TranslatePress that could prevent the trp_translate function to translate the text?

    Thread Starter Michel Jongbloed


    Hi @sareiodata,

    Further investigation and testing showed is something remarkable.

    If I put the description/excerpt text in a paragraph element (<p></p>), then the text gets translated. (btw, the user used the excerpt text for the feed, not the description)

    The user had for several products used the paragraph element in the text and for other product nothing. So the products with the paragraph element in the excerpt text got translated and the other products not.

    He even had some products with only a part of the text in a paragraph element. And there the same happened, the part in between <p></p> got translated, the rest not.

    Is there a work-around for this? Can I use the trp_translate function in a way that it translates all the text even when it is not in a paragraph element?

    Plugin Author Cristian Antohe


    Hi Michael,

    There is only a restriction where we search for HTML and that is if you serve a JSON file to that function. Only then we check to see if there is some HTML in it.

    As mentioned before, your excerpt or description is not one on one with the front-end one. A simple dot will invalidate it.

    To solve this:
    * you can try to enable Translation Memory inside TranslatePress -> Settings -> Advanced -> Miscelanious Options -> Automatic Translation Memory
    * manually add an excerpt to the WordPress post although that only works for the Classical Editor: https://wordpress.org/documentation/article/what-is-an-excerpt-classic-editor/
    * enable Automatic Translation. It will pick up those strings and translate them.

    I know this is not ideal, it’s one of the limitations we are struggling with TranslatePress and the way we’re doing translations.

    Thread Starter Michel Jongbloed


    Thanks for your reply Cristian. We will try that out, but for now I think we will have to live with it as it is.

    In itself it works now using the trp_translate() function. It’s just a bit weird that the <p> code is needed to get an translated response from this function.

    But for now we’ll leave it at this then, thanks for your help.

    Thread Starter Michel Jongbloed



    Further investigation showed that there are still products from which the short description is not being translated. Sometimes the complete description, sometimes part of the description (usually the end part).

    I took the liberty to further dive into the code of your plugin and it seems that the problem lies in how the description is stored in the database and how it’s queried by the code of your plugin. The issue lies in the special characters.

    If the original text contains a ” character, this character is converted to “ and ” in the string that is stored in the database. In the get_existing_translations() function of your plugin, the $prepared_query searches for the (correct) original text, but than with a /” for the ” character.

    E.g. the description string

    “The so-called “Lattimo” is a special glass processing”

    is stored in the database as

    “The so-called “Lattimo#8221; is a special glass processing”

    but the $prepared_query searches for

    “The so-called \”Lattimo\” is a special glass processing”

    That’s why it can’t find the translated string. I tried these as a SQL query directly on the database and indeed, it can’t find the translations using \”, but it can when using “ in the search string.

    But the thing is that for a product page, it does seem to find the correct translations. When I open the page of the specific product, I can correctly switch between the languages.

    Is there anything you can think of, that I could try.

    Plugin Author Razvan Mocanu



    TranslatePress stores the post content in the database the way it finds it after being outputted by WP.
    By default the content is being filtered by WP through wptexturize() function which, among other things, changes special characters like the one you showed. A single quote ‘ becomes &#8217 ; for example.
    This is how the original text looks like when found by TP, TP doesn’t change it when storing it in the translation table.

    If you want to use the same translation as the one generated (automatically or manually) in the front-end when displaying posts then you would have to query the exact original text.
    To do this, you can run the post content through ‘the_content’ filter before passing it to trp_translate() function.
    apply_filters( 'the_content', $product->post_content );

    This is the best way of getting the_content, because wptexturize and many more functions are hooked by default to the_content but can also be turned off by themes and plugins.

Viewing 9 replies - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.