how deal with translated LocalBusiness JSON-LD markup?

Question

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?

Answer 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.

Answer 2

(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.