Sphinx Application Documentation - Image duplication

Eugen Mohr eugen.mohr at gmx.net
Sun Jan 22 19:45:47 GMT 2023


Hi Julius

Maybe we should do the opposite of this:
https://github.com/sphinx-doc/sphinx/issues/9758 and this:
https://stackoverflow.com/questions/39008064/how-to-customize-sphinx-doc-images-folder

The language-specific figures/images are set here:
https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-figure_language_filename
-> can we switch this off / do the opposite?

Eugen

Am 22.01.2023 um 20:23 schrieb Julius Künzel:
> Hi Ben,
>
> yes, that seems to be the most proper solution for me, and I think
> this should work
>
> Cheers,
> Julius
>
> 22. Januar 2023 um 20:02, "Ben Cooksley" <bcooksley at kde.org
> <mailto:bcooksley at kde.org?to=%22Ben%20Cooksley%22%20%3Cbcooksley%40kde.org%3E>>
> schrieb:
>
>     On Mon, Jan 23, 2023 at 7:51 AM Julius Künzel
>     <jk.kdedev at smartlab.uber.space> wrote:
>
>         Hi Ben, hi all,
>
>
>     Hi Julius,
>
>
>         I did a little research about this recently and unfortunately
>         it seems to me as if there is not really a solution on the
>         Sphinx side. One need to have separate build dirs for every
>         language and it copies all static files (css, js, images,..)
>         to every build dir. That's just how it works :-/ (Correct me
>         in case anyone knows I am wrong).
>         However we can of course try to solve this on our and and make
>         our deploy tools smart in a way that they keep only one
>         version of each image file and replace the others with symlinks.
>         It should be more or less easy to detect images that are
>         translated since they follow the pattern |filename.de.png
>         where "de" is the language code, so this image would be
>         special for German, while for all other languages filename.png
>         is used.|
>
>
>     I had a very strong feeling that would be the case (very much
>     seems that Sphinx actually doesn't have proper i18n/l10n support
>     and it's been hacked in / bolted on later).
>
>     My initial thinking on a quick and (somewhat) dirty solution to
>     this had been to merge all of the image files into a single folder
>     at top level and then symlink that from each language.
>     Knowing that translated images actually have a separate filename
>     convention indicates that this might just be crazy enough to work.
>
>     Thoughts?
>
>
>         I hope that helps so far. I might be able to look into this,
>         but probably not very soon so if anybody else can work on this
>         I am more than happy.
>
>         Cheers,
>         Julius
>
>
>     Regards,
>     Ben
>
>
>         ||
>
>         15. Januar 2023 um 07:45, "Ben Cooksley" <bcooksley at kde.org
>         <mailto:bcooksley at kde.org?to=%22Ben%20Cooksley%22%20%3Cbcooksley%40kde.org%3E>>
>         schrieb:
>
>             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
>             <http://www.kde.org/> and api.kde.org
>             <http://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 <http://cutehmi.kde.org/>
>             3.7G    ./generated/docs.digikam.org
>             <http://docs.digikam.org/>
>             2.4G    ./generated/api.kde.org <http://api.kde.org/>
>             2.3G    ./generated/docs.krita.org <http://docs.krita.org/>
>             1.4G    ./generated/www.kde.org <http://www.kde.org/>
>             7.9G    ./generated/docs.kdenlive.org
>             <http://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 <http://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
>             <http://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
>             <http://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
>
>
>
>         Julius Künzel
>         Volunteer KDE Developer, mainly hacking Kdenlive
>         KDE GitLab: https://my.kde.org/user/jlskuz/
>         Matrix: @jlskuz:kde.org <http://kde.org/>
>
>
>
> Julius Künzel
> Volunteer KDE Developer, mainly hacking Kdenlive
> KDE GitLab: https://my.kde.org/user/jlskuz/
> Matrix: @jlskuz:kde.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20230122/b99b5611/attachment-0001.htm>


More information about the kimageshop mailing list