somePaulo

Hi @tegonikos,
Did you find solution for this by any chance?
Having exactly the same problem…

• This reply was modified 9 years, 7 months ago by somePaulo.

I can confirm that.
I guess Polylang uses term relationships to relate translations to originals. It affects everything – posts, pages, taxonomies, terms, slugs, options, you name it.
Is there any way to make Sweep aware of Polylang insertions?
Maybe a check for Polylang presence, or even a more generic check for metas and relationships registered by other plugins?

Activation straight after install returns this error, but activating after this from the installed plugins page does work.

Thanks for the amazing work, Chouby!

I can confirm that this solution works perfectly with the latest versions of all the involved plugins and WordPress.

Here’s a small wpml-config.xml to put in wp-content/poylang in order to get the shop archive page title and meta description translated in Polylang strings:

<wpml-config>
    <admin-texts>
        <key name="wpseo_titles">
            <key name="title-ptarchive-product" />
            <key name="metadesc-ptarchive-product" />
        </key>
    </admin-texts>
</wpml-config>

These titles and descriptions override whatever I set in the Yoast SEO metabox in the pages for the shop archives.
Moreover, in the translated version, the original structure prevails and Facebook shows ‘Products Archive’ for title and no meta description at all.

When trying to debug the link through the Facebook Devs service it shows a 404 for the translated page’s permalink, but does show the input from the strings translation if I change the slug to the main language one, but keep the translated language in the URL. Like so:

wonderwhite.ru/butik (main language, ru) – works as expected
wonderwhite.ru/en/boutique shows ‘Products Archive’ and no meta when sharing on FB, and throws a 404 in FB Devs
wonderwhite.ru/en/butik shows original version when sharing on FB, and shows translated version in FB Devs

Could be a Polylang or Yoast SEO thing.

I would appreciate it if you had any hints on a possible solution for this strange behaviour.

Cheers!

If anyone stumbles across this and finds this useful, here’s a css snippet to use FontAwesome icons instead of image ones. Just choose none in the Header Icons option and this snippet to your theme’s custom CSS (This example assumes you already have FontAwesome enqueued):

.hm-swe-collapsed:after {
  font-family: FontAwesome;
  font-size: 16px;
  float: right;
  content: "";}
.hm-swe-expanded:after {
  font-family: FontAwesome;
  font-size: 16px;
  float: right;
  content: "";}

If you want to use ASCII instead of unicode characters, you can find the respective codes on the FontAwesome icon page for your chosen icon and use it with a backslash like so (as above, but in ASCII):

.hm-swe-collapsed:after {
  font-family: FontAwesome;
  font-size: 16px;
  float: right;
  content: "\f196";}
.hm-swe-expanded:after {
  font-family: FontAwesome;
  font-size: 16px;
  float: right;
  content: "\f147";}

Enjoy!