• Resolved tobiaswinter

    (@tobiaswinter)


    Hi,
    I’d like to use this glossary plugin, if it only was compatible with Translatepress.
    Currently, it looks like the terms are not detected and styled with link/popup on translated pages (the term itself not translated of course). Only for the main language everything works as expected.

    To reproduce:
    – Install Translatepress (free)
    – Install Glossary and add a term
    – Go to a page in origin language, glossary popup and link working as expected
    – Switch Language with the Languageswitcher Translatepress added to the page. Even if there is no tranlation jet, term is not recognized any more

    I hope it could be fixed, because deactivating Translatepress is no option for me.
    Thanks!

Viewing 7 replies - 1 through 7 (of 7 total)
  • Hi Tobias, we don’t support translatepress.

    As I can see in the plugin readme:
    Translate all your website content directly from the front-end, in a friendly user interface (translations are displayed in real-time).

    As we are processing the text server side and that plugin in the frontend with javascript our plugin can’t work with this solution.

    Thread Starter tobiaswinter

    (@tobiaswinter)

    Hi Daniele,
    thanks for your fast reply.

    I think you might be misunderstanding what Translatepress refers to in this sentence. This only affects the translation input which happens on the frontend.
    The output of (translated) text later on happens server side.

    Do I don‘t think this is s showstopper of a Translatepress compatibility.
    Also, all other plugins that I‘ve tested do work (more or less) with Translatepress, like Tooltips by Tomas, CM Tooltip Glossary, and a third one I can‘t remember any more.

    I hope you can take a look at Translatepress again and tell if a compatibility is possible.

    Thanks!

    Hi Tobias,
    our plugin use the native WordPress stuff with the_content filter so if the content is printed without that filter our plugin is not executed or if the content is put inside various tags.

    CM Tooltip uses shortcode to inject the tooltips so is a manual task, we offer a shortcode in the premium version that let’s to wrap the content and execute it inside the tooltip injector https://docs.codeat.co/glossary/shortcodes/#parse-content-premium

    Thread Starter tobiaswinter

    (@tobiaswinter)

    Hi Daniele,
    thanks for the explanation.
    I’ll take a look into the code and figure out why it doesn’t work. I’ll report back in a few days.

    Thread Starter tobiaswinter

    (@tobiaswinter)

    Hi Daniele,
    as promised, I’ve looked into the code to find the problem.

    In the function do_wp_query() (Terms_List.php, line 139) you create a Query to get all the glossary posts. The term is retrieved by \get_the_title(); inside the loop of that query (line 150).

    With Translatepress enabled and being on a tranlated page, Translatepress filters the title via its wrap_with_post_id function (class-translation-render.php) where it adds some additional tags. So the post title “my-Term” gets filtered to “<trp-post-container data-trp-post-id=’1617′>my-Term</trp-post-container>”. Then, you build a regex with this value to find this term on the current page, but of course that is never found.

    There are several possibilities to fix this:

    • Check “Disable post container tags for post title” in Translatepress’ Advanced settings tab. This removes the filter globally. Currently I don’t know what sideeffects this has since it affects all post titles, not only glossary terms. However, with this option checked, Glossary perfectly works together with Translatepress. All Terms, term content and so on can be translated, even translated terms will be matched correctly.
    • Translatepress tries its best to avoid this situation. For example, it checks if the query is the main query or if the post id matches the global $post id. Unfortunately, Translatepress can only check the global $wp_query if that’s the main query, and it is, because you use a secondary query. The other way around is true for $post id, since the global $post gets overwritten with the glossary term post, the ids do match. You can see those checks in the wrap_with_post_id function. I don’t know wordpress good enough to judge if there is anything that should be fixed in your code that will make one of those Translatepress checks work.
    • Ask Translatepress to implement another check or compatibility functions. I’ll reference this post in their forum.
    • I can use your glossary_terms_results filter to remove all the Tags Translatepress added before. However, I would also need to fix the regex. Performance-wise removing what was added earlier seems not to be a good idea.
    • I can add another filter to the_title which removes the Translatepress modifications if it’s a glossary post type. That would need to be checked in every call of the_title. Not ideal.
    • I can use your glossary_custom_terms filter to implement my own Query without using the_title hook at all (or at least remove and readd the Translatepress filter before and after). Performance-wise this should be the best option, when the first point on this list fails.

    Do you have any other ideas?

    Thanks for the investigation.
    Looking on how WPML or Polylang doesn’t have that issue, get_title should return the pure title with no other stuff as this can breaks integrations with other plugin like in this case.
    As example if you need to do a wp_query and print all the title of a post somewhere else everything won’t work.
    My guess is that code is used on the browser to localize the string but doesn’t make sense in this context.
    The title should be return in the right language as does those other plugins but let’s see what they says.
    My suggestions is to disable that feature as their faq https://translatepress.com/docs/troubleshooting/ simply report that is required to localize the text, but if they have an alternative solution to get the title already localized server side I can integrate in the plugin.

    Thread Starter tobiaswinter

    (@tobiaswinter)

    WPML or Polylang do have different concepts for translation and they often have limitations what can’t be translated. For example, Polylang does not allow to translate non-global product attributes in WooCommerce. This is the reason why I use Translatepress. It just tries to translate everything.

    As example if you need to do a wp_query and print all the title of a post somewhere else everything won’t work.

    Not quite right, because if you print that out on the webpage, Translatepress will take care of those <trp-post-container data-trp-post-id=’1617′> tags later on, filter them out and use the information it has put in there before to find the right translation in the translation database.
    The only issue is when it’s not printed on the webpage but used in the code (of Glossary in this example) to match possible terms in a text with it.

    I think we agree here that it’s not the fault of Glossary or Glossary doing anything wrong, it’s just the fact that it’s not working out of the box right now and the Translatepress authors should find the right place to fix that. May be you can help and add a filter or something (for example a filter so one can replace the_title with a custom function to deliver the title of a given post instance), so in the end customers are happy, but first let’s see what they say, my post is here:
    Translatepress Support Forum

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Not compatible with Translatepress’ is closed to new replies.