Sphinx Application Documentation - Image duplication

[L. E. Segovia]

Hey,

It seems images are duplicated by Wolthera's Sphinx configuration [1],
and that the build job creates each site separately [2].

Godot had found a similar issue that needed monkeypatching [3]. Would we
have to do this to stop the duplication?

amyspark

[1]:
https://invent.kde.org/documentation/docs-krita-org/-/blob/master/conf.py#L377
[2]:
https://invent.kde.org/sysadmin/binary-factory-tooling/-/blob/master/staticweb/pipeline-templates/sphinx-app-docs.pipeline#L23-43
[3]: https://github.com/sphinx-doc/sphinx/issues/7768

On 15/01/2023 06:12, Halla Rempt wrote:
> Let's discuss this on Monday during the meeting.
> 
> On zondag 15 januari 2023 07:45:58 CET Ben Cooksley wrote:
>> Hi all,
>>
>> For some time now it has been known to me that the system for generating
>> application documentation websites using Sphinx with l10n support has had
>> issues with duplicating data - particularly images.
>>
>> That leads to the following outcome, where aside from sites that we expect
>> to be quite large (like www.kde.org and api.kde.org) all of the application
>> documentation sites are quite big as well:
>>
>> root at nicoda /srv/www # du -h --max-depth=1 ./generated/ | grep G
>> 2.3G    ./generated/cutehmi.kde.org
>> 3.7G    ./generated/docs.digikam.org
>> 2.4G    ./generated/api.kde.org
>> 2.3G    ./generated/docs.krita.org
>> 1.4G    ./generated/www.kde.org
>> 7.9G    ./generated/docs.kdenlive.org
>> 29G     ./generated/
>>
>> This stands in comparison to the Docbook documentation site for all other
>> KDE applications:
>>
>> root at nicoda /srv/www # du -h --max-depth=1 . | grep G
>> 29G     ./generated
>> 16G     ./api.kde.org-legacy
>> 6.0G    ./docs.kde.org
>> 51G     .
>>
>> It would be nice if we could please look into some fixes for this, as it
>> looks like Sphinx is duplicating the images - once for every language -
>> when that isn't necessary.
>> I could understand if the screenshots were updated as part of the
>> translation, but it looks like they're not in the majority of cases - below
>> being just a sample:
>>
>> root at nicoda /srv/www/generated/docs.krita.org # sha256sum
>> zh_CN/_images/Krita_cpb_mixing.gif
>> 12eb4cbad29a5a6486d3438dabb888a0aa0b9579e55b3be2f3c1d6e1d76fc1d7
>>  zh_CN/_images/Krita_cpb_mixing.gif
>> root at nicoda /srv/www/generated/docs.krita.org # sha256sum
>> en/_images/Krita_cpb_mixing.gif
>> 12eb4cbad29a5a6486d3438dabb888a0aa0b9579e55b3be2f3c1d6e1d76fc1d7
>>  en/_images/Krita_cpb_mixing.gif
>>
>> While this isn't a massive issue right now, it is a future scalability
>> issue as for Krita at least each language costs 178MB or so, while for
>> Digikam that sits at 415MB per language and Kdenlive is 392MB.
>>
>> Many thanks,
>> Ben
>>
> 
> 
> 
> 

-- 
amyspark 🌸 https://www.amyspark.me