It might be that this is a bug introduced in V17, but this might also be my own doing, so here goes:
I have a document type that lists a number of properties for SEO, and one property for the document itself; that is a BlockList. A BlockList is allowed to have a collection of custom text segments (optional header property, paragraph of text property) and/or custom image segments (select media image, set optional label property, set html img alt property. Yes, both text and image section types allow culture variation)
I can save the documents to the local SQLite, no problem; the issues arrive during publishing, where I publish the documents to a JSON format for storage using custom .NET code (ElasticSearch for documents, MinIO for media. Those parts all works fine by the way, that’s not the issue).
The English localization will aways have the ‘'content’’ BlockList blocks available; other languages pretend nothing is there - not even ‘copies of English or empty clones’. During debugging, I tried putting ‘‘all cultures the same’ on to see what would happen, and in those cases the blocks would be populated with the default English version; otherwise, the custom texts/image segments would be non-existent. However; reminder that you can still see them in Umbraco itself or load them in later. It is only during publishing that it goes wrong. And the regular SEO properties (mostly textstrings) all get localized properly, unless of course the property is set to shared between cultures in which case it’s all the same.
C# Code:
// IPublishedContent content, string culture
var blocks = content.Value<BlockListModel>("content", culture);
(if culture is ‘en‘, I see the contents; for ‘de‘, or‘fr‘ for example, I only get an empty array returned of 0 items, but not null. )
This code is invoked during publishing, which is hooked in program.cs with the line
builder.Services.AddScoped<INotificationHandler<ContentPublishedNotification>, PublishToMinIoHandler>();
I’ve tried to replace it with a ContentCacheRefresherNotification, but that didn’t solve the issue either, so it appears to be this issue is a bug in the library itself.