Forum Replies Created

Viewing 15 replies - 1 through 15 (of 119 total)
  • Plugin Author Razvan Mocanu

    (@razvanmo-1)

    Hi,

    We fixed this issue in the 2.7.8 version we just released. Thank you again for reporting it.

    Best regards,

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    Hi,

    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.

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    Hello,

    Thank you for reporting this issue. We will fix this in the next update.
    Can you confirm that you don’t have Divi installed on this website?

    Best regards,

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    Hi,

    Thank you for reporting this bug.

    Can you provide more details as to where the <span data-no-translation> appeared? Is it the WP Dashboard -> WooCommerce -> Orders, when displaying the individual order details? If not, please point out the exact place.

    Also, it would be helpful if you could list any WooCommerce add-ons that you might have.

    We are trying to fix the reported issue in the next update so any extra input from your side is appreciated.

    Best regards

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    Hi,

    Are you are looking towards implementing your own way to replace the original strings with the translation? Do you just need our help to show those strings in TP Translation Editor and later use a server-side TP function to retrieve them?
    If so, I can assist you.

    Like @sdenis said, live detection in the front-end is just not possible for now if you are using React to output them. But if you want to translate your strings on server-side and prepare the translations to be used in front-end, then there is a workaround.

    I assume you need translation for user-inputted strings, not for localized (gettext) strings.

    /* This code is used to register a string that will be visible in the TP Translation Editor sidebar in the dropdown.
       Can be placed anywhere inside the <body> tag, such as on the wp_footer hook. 
       Automatic translation will pick them up too, but only if Translation Editor was opened as least once so that these 
       strings got a chance to be registered. */
    if ( isset( $_GET['trp-edit-translation'] ) && $_GET['trp-edit-translation'] == 'preview' ){
        //$custom_content_1, $custom_content_2 are strings containing just text, no html
        echo '<span style="display:none">' . $custom_content_1 .'</span>';
        echo '<span style="display:none">' . $custom_content_2 .'</span>';
    }
    
    /* ------------------------------------- */
    
    /* This code needs to be executed on the server-side, when preparing the content to be displayed to the user on the front-end. */
    $trp = TRP_Translate_Press::get_trp_instance();
    $trp_render = $trp->get_component( 'translation_render' );
    
    // retrieves the translation of any original text in the currently displayed language.
    $translated_custom_content_1 = $trp_render->translate_page( $custom_content_1 );
    $translated_custom_content_2 = $trp_render->translate_page( $custom_content_2 );

    I hope this code can get you started on creating a solution. If you have further questions, perhaps it would be better to write us an email.

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    Hi,

    I added an action at the time of manually changing translation of user-driven content text (not plugins/theme text) in the Translation Editor. The two parameters are the array of strings that are being updated and the TP settings.

    do_action('trp_save_editor_translations_regular_strings', $update_strings, $this->settings);

    I hope this will be useful for your use case.

    Best regards,

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    Hi,

    The latest TranslatePress version contains a compatibility fix that solves this issue. Google Site Kit’s dashboard no longer disconnects.

    Thank you for your debugging effort!

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    Hi,

    I’m really sorry for causing you this trouble.

    I accidentally introduced a bug while integrating a feature to improve the automatic translation.

    It only happened for certain edge cases where detecting the supported languages by the selected translation engine failed.

    We just launched an update to fix that bug.

    Thank you for reporting this issue.

    Let me know if you still have trouble getting your multilingual site up and running with the new TranslatePress version.

    Kind regards,

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    Hi,

    We use wpdb->get_charset_collate() function to determine the collation of the database. In your case there is a mismatch. Judging by the error you received, the expected return is latin1, but instead it returns something else.

    Try checking and changing DB_COLLATE to latin1 in wp-config.php. Same with DB_CHARSET if already set.

    Before taking any actions I recommend backing up database and files to safely restore in case something goes wrong.

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    I have documented the case and we will try to replicate it and fix it.
    We don’t have a timeframe for this bug, but if our developers will find a solution for it, we’ll make it available in one of the next versions of our plugin. I will also notify you on this thread.

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    Hi,

    The problem is due to an issue of escaping of the admin-ajax response on the translated pages.
    I could not replicate it because it requires premium version of ARMember.
    I see you have removed TranslatePress so closing this for now.

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    Hi,

    It seems that TranslatePress is detecting too many times a string added using JavaScript on your site. To fix this try the following:

    1. Create an empty plugin like this
    2. Add the following code to the end of it:
      add_filter('trp_duplicate_detections_allowed', 'trpc_duplicate_detections_allowed');
      function trpc_duplicate_detections_allowed(){
          return 10;
      }
    3. Install this plugin via FTP (copy it inside wp-content/plugins) or create a zip archive with it and install it via the WordPress plugin upload functionality

    Let me know if the error still appears.

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    This problem occurs most likely due to passing an internationalized gettext string through a function that retrieves the time and date.

    Can you browse your theme (or the plugin) files where the reviews are outputted? Try searching for css class keyword “reviews-comments-item-date” and paste here the code fragment that generates the date.

    I will then be able to solve the issue.

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    Hello,

    This bug should be fixed in TranslatePress version 1.7.1.
    Please update to the latest version.

    Plugin Author Razvan Mocanu

    (@razvanmo-1)

    Are you still seeing the error you mentioned earlier in the browser console? Try a hard reload, to ensure there is no caching of the JS running while the Translation Editor is open.
    Did you try the conflict test, the one were you disable all plugins and switch to the default theme, that my colleague Cristian suggested earlier?

Viewing 15 replies - 1 through 15 (of 119 total)