2

I have a JSON-LD markup (according to the Google's guidelines) for:

  • Website with Logo
  • LocalBusiness with AggregateRating and Reviews
  • Breadcrumbs

Suddenly I realized that every schema has a translated copy for every language the website is translated into. It's OK with Breadcrumbs, but not so with, say, LocalBusiness as now it has duplicates with duplicate ratings.

I found no much official documentation from Google on how to deal with markup in multiple languages (all I found was related to the page and content, not about markup; using hreflang and sitemaps to tell Google about translated pages is not the same as making a LocalBusiness json-ld, they are processed differently).

What would be the best strategy for translated schemas?

  1. Keep one LocalBusiness schema in one language and remove translated copies?
  2. Keep translated LocalBusiness schemas with @SameAs pointing to the original schema? If so, can Google understand that they're translations?
  3. Keep multiple schemas in different languages with the same @id and let Google pick one or distinguish translated copies?
  4. Make them unique? Create different @id for each translated LocalBusiness?
  • Which parts of the LocalBusiness are translated? I would guess that most content is the same in all languages (name, address, telephone number, etc.). – unor Jul 6 '17 at 13:29
  • @unor except for phone numbers and emails everything is translated: name, alternate name, description; the site is in 3 languages and I have 3 copies of every schema – Alex V Jul 6 '17 at 16:25
  • i've seen only implementations, where value language of structured data properties with expected/required value data type "text" has matched the language of the html document's content, where structured data was implemented. In all of these cases, where the website's language wasn't english, there was a discrepancy: structured data values, which are predefined by Schema vocabulary are in english, other structured data values, which should be text, are in the website's language. – Evgeniy Jul 6 '17 at 22:47
1

i would keep LocalBusiness in one language everywhere, but on different language versions of your site i would add language definition, like this:

<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "LocalBusiness",
"mainEntityOfPage": {
"@type": "WebPage",
"url": "http://example.com/de/",
"inLanguage": "de"
}
}
</script>

Use as url the one you use in hreflang attribute, so there will be no discrepancy.

  • so, it's option 2: use the same @id for every copy of the, i.e. LocalBusiness and add inLanguage; is there any real life example of the same markup in multiple languages? – Alex V Jul 6 '17 at 16:38
  • What does support this idea? Is this just your imagination? Any acceptable references? – Pmpr May 30 '18 at 9:23
0

(As far as I’m aware, Google Search doesn’t publish guidelines for such a case.)

I don’t think it would be useful to remove the structured data from the translated pages.

Consumers (whether humans or bots) that are interested in structured data don’t necessarily also crawl the page in other languages. These consumers wouldn’t even notice that you provide structured data.

A search engine that decides to display a rich result for your page might be interested in displaying it for your translated pages, too. And if it does this, and if the rich result includes author-provided text, the search engine will likely only display the rich result on translated pages if the data is in the page’s language, too.

JSON-LD’s @id

As it’s the same organization, the @id should be the same, too.

That is one of the main purposes of @id, to convey that different nodes (possibly on different sites/pages, in different languages etc.) are about the same entity.

JSON-LD’s @language

JSON-LD allows you to specify the language of string values with @language. (This would also allow you to have one node that contains the data in all languages.)

But at least Google’s SDTT doesn’t seem to support @language. It’s not clear if that’s the case for Google Search itself, too. Assuming that Google Search doesn’t support @language, it should be fine to provide such language annotations anyway, as they will probably be ignored.

Schema.org’s inLanguage

As Evgeniy notes, Schema.org defines the inLanguage property, which allows you to specify the language of creative works (not of the LocalBusiness itself).

You could provide this property on every WebPage and/or on each language’s WebSite item.

Schema.org’s workTranslation/translationOfWork

To convey that your WebPage (and possibly also WebSite) items are/have translations, you could use the workTranslation/translationOfWork property from Schema.org’s bib extension.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.