Reduce size of capabilities response with translations enabled

[fancycode]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

If translations are enabled, the capabilities of Talk contain a huge amount of entries in the translations key. Here it was about 500 Kbytes of JSON. Most of the data in there is redundant (fromLabel / toLabel), so a smaller representation would be rather easy. Also if multiple apps will need the same data in the future, the capabilities will grow a lot again.

Compressing the response of course is easy (in my example the 500 Kbytes go down to ~24 KBytes), but services caching the capabilities of multiple servers (like the HPB or the SIP bridge) will require a lot of memory to do so.

It would be great if the size of the capabilities could be reduced for the case where translations are enabled. Maybe the list of possible translation sources / targets could be moved to a separate endpoint, so it's only transmitted if necessary.

[fancycode]

Example response payload: large-capabilities-private.json.gz

[SystemKeeper]

See nextcloud/talk-android#3099 for details.
Do you have OpenAI integration enabled maybe? Some apps add a lot of possible translations...

[fancycode]

See nextcloud/talk-android#3099 for details. Do you have OpenAI integration enabled maybe? Some apps add a lot of possible translations...

I don't have access to the instance, just saw the large response in one of our logs on the HPB service / SIP bridge clusters. But reading the referenced issue, this could be the reason. Still would be nice to reduce the size.

[nickvergessen]

Idea:

• If more than ~50 translations exist, we return a boolean capability (different name, or same, both work for me) and the clients/UIs then have to consult: https://github.com/nextcloud/server/blob/1be836273ddba6e0ddb3509a1d898535df9fd169/core/Controller/TranslationApiController.php#L49-L61

This way the "basic" case with the useful translate app would still work, while the "I will translate anything into everything" approach from the AI app won't break the capability?

[fancycode]

I would rather not have any translations in the capabilities, only a boolean flag:

• clients that need translations know they can fetch them separately
• there is a single code path for clients: if flag is set, fetch translations, not check if translations or flag in capabilities and then maybe still fetch.
• clients not interested in translations can reduce their traffic / memory requirements

But I can live with a few translations in the capabilities and in the end it's up to you to decide what the solution should be ;-)

[nickvergessen]

clients not interested in translations can reduce their traffic / memory requirements

The current translate app has 15 entries: https://github.com/nextcloud/translate/blob/main/lib/Service/DownloadModelsService.php#L20-L35 that should be "okay" as capabilities.
The problem comes from the openai integration app which loops over all available languages (100 at the moment) and creates a n*(n-1) = 9900 sets:
https://github.com/nextcloud/integration_openai/blob/615e1f6446789fce8104f4d3e9df525263fa6b5c/lib/Translation/TranslationProvider.php#L67-L78

clients that need translations know they can fetch them separately

Well it would break updated servers if people don't run the latest mobile app/desktop client, that is why I would like to "keep it" if it isn't broken yet. We can schedule removal of the capability for Nextcloud 28 and until then go with both ways.