I investigated this a bit further trying to find some potential solutions.

In T280774#7158117, @Sarai-WMDE wrote:

a broader underlying problem: the lack of semantic standards for the translation of data in Wikidata's user interface

Can you see requests from Wikidocumentaries to MCS? They should have Api-User-Agent starting with the string "wikidocumentaries" (at the beginning of the contact email address).

@Vedant_pandey2003 I created a new task T331229, where we can discuss that.

In T330179#8651510, @Zexi_Gong wrote:

There is a Wikipedia API that could provide all image info. It will be easy to do 2 & 3 with this API. Currently there is no such implementation at our backend. Would you like to add the API query function to our backend or our frontend?

Now that @Zexi_Gong has a nice pull request, this got me thinking (perhaps for future tickets):

Is there an existing webpage that uses the existing ImageViewer so I can play around with that?

@Andrew This has turned into quite a different migration operation than I'd been able to imagine - let's have a post-mortem off-Phabricator?

I think you shouldn't need to change the parsing logic in the backend. If needed, you can add any additional parsing logic to the frontend. I'm not sure how much work this would be, but I agree it would be interesting with future improvements in mind.

@Susannaanas I'm wondering if it wouldn't be even nicer to use our existing image viewer component? This way in the future, people could improve the tags of the article images as well.

I opened a new task specifically regarding the image viewer: T330179

I have started to work on this migration. Who could restart the old instances? (step 2 above)

No step should take long if the order is correct. Something like this: (?)

Looking at the current nginx configuration, this might be a change as small as changing
(sparql.*) to (sparql.*|ldf.*) at https://github.com/wbstack/deploy/blob/4f6acaf/k8s/helm/platform-nginx/nginx.conf#L81-L117

Ok, the following settings for each service in the docker-compose.yml file may have fixed this:

logging:
    driver: json-file
    options:
        max-size: 10m
        max-file: "20"
        compress: "true"

Most of the space was taken by docker logs of the running containers. Easiest solution was to recreate the containers that had long logs, which cleared the logs.

The first version of this service was implemented at the Wikimania 2019 Hackathon. Video recording of the showcase presentation: https://youtu.be/SomTEzaoROQ?t=446

Thanks for helping!