We have a situation where we’re retrieving an article content type with a richtext body field that has embedded entries. We have Content Renderers in place in order to render our custom entry appropriately. When retrieving the localized version of the article, we would expect the localized version of the embedded entry to come along and get passed to our Content Renderer, but it doesn’t. We always receive the en-US version. We have verified that we do in fact have the embedded entry marked for localization, along with its fields (es in this case). So, we’re having to query contentful in order to retrieve the localized version of the embedded entry we’re renderering. This seems wrong. Is this a bug or by design?
I’m running into this as well - anyone have any ideas?
I have the
EmbeddedAssetBlock stuff working, but it only gets the default locale for the embedded item. All the rest of the content is translated properly, but the returned embedded entry is always the
en version… why!? I don’t see a way of even specifying the locale for an
EmbeddedAssetBlock in the php tools…
I am having the same problem.
I have localized richtext fields with embedded assets (images). The images are also localized.
The Contentful app show the correct localized image when entering or editing the content (in the richtext field). However, when accessing the data via the content delivery API and using rich-text.php content renderer, we only have access to the default locale of the embedded asset.
Any help would be appreciated…