Opened 3 years ago

Last modified 3 weeks ago

#1274 reopened defect

sharing adblockplus.org in social networks always use english metadata

Reported by: saroyanm Assignee:
Priority: P2 Milestone:
Module: Websites Keywords:
Cc: sebastian, greiner, matze Blocked By: #5447, #5683
Blocking: Platform: Unknown
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by juliandoucette)

Environment

Linux, Ubuntu 12.04
Chrome v 37.0.2062.9

How to reproduce

  1. Open social network that uses metadata to show post description ex. facebook.com
  2. Paste https://adblockplus.org/de/chrome into the "update status" field.
  3. Wait for facebook to get metadata from the page.

Observed behaviour

facebook uses English text in description and title of the link:
Adblock Plus - Surf the web without annoying ads!
Adblock Plus is the most popular adblocker available for Firefox, Chrome, Opera, Safari, Android and Internet Explorer. Block all annoying ads all over the ...

Expected behaviour

Facebook should get metadata from German version of the website:
Adblock Plus - Für ein Web ohne nervige Werbung
Adblock Plus ist der beliebteste Adblocker für Firefox, Chrome, Opera, Safari, Android und Internet Explorer. Blocken Sie jede nervige Werbung im Internet...

What to change

Add og:locale and og:locale:alternates to default.tmpl.

Note: This solution may change based on the implementation of #5392.

Change History (32)

comment:1 Changed 3 years ago by saroyanm

  • Ready set

comment:2 Changed 3 years ago by saroyanm

  • Blocking 1198 added

comment:3 Changed 3 years ago by sebastian

  • Priority changed from Unknown to P3

comment:4 Changed 3 years ago by greiner

I'm not sure whether the behavior described in this issue can be reproduced which is why I base my comment on the original issue report in #1198:

This happens because we're including <link rel="canonical" href="https://adblockplus.org/" /> on the homepage to avoid having duplicate content in search results. Facebook's crawler follows that link to only fetch data from the canonical page which is in english. The german title is provided by the extension.

We could change the canonical link to include the language as we did with the <html> element in global.tpl.php. Keep in mind that the canonical link only applies to the homepage so adding it to global.tpl.php is not a solution.

comment:5 Changed 3 years ago by greiner

  • Cc greiner added

comment:6 Changed 2 years ago by matze

  • Cc matze added
  • Tester set to Unknown

Can you still reproduce this now that we use the custom CMS?

comment:7 Changed 2 years ago by greiner

Yes, this issue still exists.

comment:8 Changed 2 years ago by matze

Very well, then can we fix this now in similar manner to the one you suggested before?

comment:9 Changed 2 years ago by greiner

The suggested solution should still work, yes. Not really related to the Infrastructure module, however, rather Websites and/or Sitescripts, since the suggested solution only requires changes to the HTML code.

I'll do a bit of investigation to find out what exactly needs to be changed and update the description accordingly.

comment:10 Changed 2 years ago by greiner

  • Component changed from Infrastructure to Websites
  • Description modified (diff)
  • Ready unset

comment:11 Changed 21 months ago by juliandoucette

Both the canonical url and the og:url are hard coded to https://adblockplus.org/. As a result, Facebook will always query the og:url and get English results.

See: https://developers.facebook.com/tools/debug/og/object?q=https%3A%2F%2Fadblockplus.org%2Fde%2Fchrome

As a side note: It looks like the German og:description has not been translated yet.

I think this should be "ready" and a higher priority.

Thoughts saroyanm?

comment:12 Changed 21 months ago by sebastian

We added <link rel="canonical"> specifically, to remove the language prefix (e.g. from Google search result lists). Otherwise, we could simply omit that tag as well. But I'd rather keep it like that, in favor of cleaner URLs on Goolge, etc.

Wouldn't it be sufficient to just change og:url?

comment:13 Changed 11 months ago by juliandoucette

  • Priority changed from P3 to Unknown

comment:14 Changed 6 months ago by juliandoucette

  • Priority changed from Unknown to P2
  • Ready set

comment:15 Changed 5 months ago by juliandoucette

  • Owner set to juliandoucette

comment:16 Changed 4 months ago by juliandoucette

  • Owner juliandoucette deleted

comment:17 Changed 3 months ago by juliandoucette

Wouldn't it be sufficient to just change og:url?

Maybe. But this is not what og:url is meant for. If we provide the proper og:locale:alternates and a canonical og:url then our server configuration should be able to determine and serve the correct locale.

comment:18 Changed 3 months ago by juliandoucette

  • Owner set to juliandoucette

I'm going to test this.

comment:19 Changed 3 months ago by juliandoucette

  • Blocked By 5402 added
  • Ready unset

See #5402: I think this should be done on the backend.

comment:20 Changed 3 months ago by juliandoucette

  • Owner juliandoucette deleted

comment:21 follow-up: Changed 3 months ago by matze

That comment (17) makes no sense:

"Maybe. But this is not what og:url is meant for."

What is "this"? In context it would be "og:url", and "it's not meant to be changed". But in the next sentence a "canonical og:url" is proposed.

Last edited 3 months ago by matze (previous) (diff)

comment:22 Changed 3 months ago by juliandoucette

  • Blocked By 5392 added

comment:23 in reply to: ↑ 21 Changed 3 months ago by juliandoucette

Replying to matze:

What is "this"? In context it would be "og:url", and "it's not meant to be changed". But in the next sentence a "canonical og:url" is proposed.

Sorry matze :/

I was:

Replying to sebastian:

Wouldn't it be sufficient to just change og:url?

In this context, "this" is how sebastian is proposing we change og:url.

I think that subastian was proposing that we change og:url to include locale instead of the canonical url as described in what to change. This would resolve the issue described. But it would separate our like and share counts per page by language. That is why I proposed we add og:locale and og:locale:alternate(s) and resolve locale based on fb_locale instead of adding locale to og:url to resolve this issue.

comment:24 Changed 3 months ago by juliandoucette

  • Description modified (diff)

Updated what to change based on the solution that I proposed.

comment:25 Changed 3 months ago by juliandoucette

  • Blocked By 5447 added

Note: Only the changes proposed to og:url in #5447 are relevant to this issue.

comment:26 Changed 2 months ago by juliandoucette

  • Blocked By 5392, 5402 removed

This bug should be fixed by #5447.

comment:27 Changed 2 months ago by juliandoucette

  • Blocking 1198 removed

comment:28 Changed 2 months ago by juliandoucette

  • Owner set to juliandoucette

comment:29 Changed 2 months ago by juliandoucette

I thought that my solution to #5447 would resolve this issue. However it is not resolved yet. I will need help from operations to find out why.

comment:30 Changed 5 weeks ago by juliandoucette

  • Resolution set to fixed
  • Status changed from new to closed

Fixed by:

---

Facebook will scrape all available locales and display them according to your Facebook account locale. Unfortunately there is a bug in Facebook preview that causes all share previews to display in English. But the final share will display in the appropriate Facebook account locale.

comment:31 Changed 5 weeks ago by juliandoucette

  • Blocked By 5683 added
  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:32 Changed 3 weeks ago by juliandoucette

  • Owner juliandoucette deleted

Note: I'm waiting on the results of testing #5683 before I proceed.

Note: See TracTickets for help on using tickets.