Problems with Workbench, Language panel, Visual Composer Raw HTML blocks etc

1. This is something we have been able to reproduce. We are investigating this issue but until we get it resolved you can access the Workbench by using a WordPress User that has the same email as the one you used to sign up for Lingotek.

2. We hide the Polylang language box because when you upload your content to Lingotek we take control of those translations and track them ourselves. Essentially, while we use and rely on Polylang’s multilingual framework, we ultimately are in control of those translations instead of Polylang. If you would like to manage a translation or link an existing page as a translation, you can disable translation of that language in your Lingotek Translation Profiles. These are found in the following location: Translation -> Manage -> Translation Profiles. You can then add a new profile and disable whatever target languages you would like.

3. Our default behavior is to link together all the content that is managed by Lingotek. This allows you to easily delete all content both on WordPress and on Lingotek. If you want to unlink that content you can “Disassociate from Lingotek” and that will let you delete translations without deleting the original page. It also shouldn’t be deleting anything that hasn’t been translated using Lingotek. Could you give us specific examples of how this is not working as expected?

4. We have filters in place to protect shortcodes from being translated. Do you have some examples of the shortcodes you are having issues with?

5. Could you also provide examples of what this content looks like so we can reproduce the issue?

6. This is due to tags getting applied automatically to machine translated content. If you follow the steps above to get the Workbench working (using the same email) then you will be able to post-edit and manually place those tags.

If it would be helpful for you, we can do a call so we can be on the same page with these items.

We also are aware of the Polylang compatibility changes and will be releasing an update soon to get rid of those PHP warnings.

Hi erichie – thanks for your prompt reply; I wonder why we still haven’t received a reply to multiple support tickets via the Lingotek website? Perhaps you can track our tickets down (29/7 + 11/8, e-mail: [ redacted, support is not offered via email, Skype, IM etc. only in the forums ]), as they included screenshots and detailed examples?

1. Workbench – Good to hear you’re working on the Workbench issue. Sounds like you’re saying it’s because of an e-mail address mismatch – obviously it’s not poss for every WP admin to have the same e-mail.
2. Hiding the Language panel seems to us a usability flaw – no way to jump to translated versions when editing a page, and more importantly no way to link together existing pages as translations. I appreciate the workaround is to use ‘Disassociate’ -but I can’t see why it has to be either-or, given the relationship is managed fine by Polylang and you can presumably hook into new translation relationships created via this method.
3. Linked page deletion – say I have an English page, upload to Lingotek, request German and French translations which causes these pages to be created. I then decide to delete the French page and am shocked to later realise the English original and all other translations have been deleted too. This is simply poor usability and needs fixing. Deleting the original I could just about understand affecting translations, but not the other way around.
4. Shortcode base64 corruption – The filters aren’t working unfortunately – I’ve given multiple specific examples in my support tickets, I can forward by e-mail if you get in touch at the e-mail above?
5. Shortcode over-filtering – Ditto
6. Misplaced formatting – OK – we can try once Workbench link working, but this wouldn’t change that there’s a bug causing unnecessary manual fix-ups to be necessary? Sounds like there’s some internal character position tracker / calculation that’s off?

Fine with arranging a call to talk through if this is useful – I look forward to you hopefully finding a resolution for the shortcode corruption issue #4 above, which is the show stopper for us at present. Thanks – have a good weekend.

neogic,

By default, the Lingotek plugin protects attributes within shortcodes (e.g., [vc_row type=”do_not_translate”]) from being translated as they often contain code within them. Also, by default, the Lingotek plugin translates content the within shortcode tags (e.g., [vc_column_text]This text should be translated.[/vc_column_text]) as it is often text that requires translation. The issue that you describe can be resolved by using a Custom Filter. We allow customers to create an unlimited number of Custom Filters to be used to do more complex filtering. (Contact [email protected] for more information.)

The behavior you are experiencing in #2 and #3 is to be expected, so at least for now, you will need to use the workarounds that I have provided above.

We think the features you mention have some merit, yet, unfortunately, we are not sure when we will be able to get to them. Would you be interested in contributing code to the Lingotek plugin to help develop the specific features that you want? We would love to collaborate with you to help get some of your ideas into the plugin.

Hi Edward – disappointing to hear no interest in fixing #3 (linked page deletion) – this is a major usability flaw that will generate complaints I’m sure. Our client ran into it within 30 minutes of testing, as did we. I can look at a fix if necessary, if you’d be happy to incorporate? #2 is subjective I guess – though it would be trivial to stop hiding the Languages box (filters-post.php -> remove add_meta_boxes() override).

#5 and #6 are outright bugs in need of fixing. #4 you just need to add a rule to protect the content of vc_raw_html and vc_raw_js shortcodes. Per my e-mail, Visual Composer is an *extremely* popular WP editor replacement, both as a standalone plugin and because it’s embedded into hundreds of popular themes from leading vendors (e.g., ThemeNectar / Salient).

Oh, one further issue we spotted: the translated page doesn’t preserve Custom CSS defined for the page (‘_wpb_post_custom_css’ meta field), which I believe is a standard WP feature. This means CSS has to be manually copied across to translated pages, spoiling the seamless experience.