Re: Sphinx Application Documentation - Image duplication
Eugen Mohr <[email protected]> Sun, 22 Jan 2023 20:45:47 +0100
| Newsgroups | gmane.comp.kde.www,gmane.comp.kde.digikam.devel,gmane.comp.kde.devel.krita |
|---|---|
| Message-ID | <[email protected]> |
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" <[email protected] > <mailto:[email protected]?to=%22Ben%20Cooksley%22%20%3Cbcooksley%40kde.org%3E>> > schrieb: > > On Mon, Jan 23, 2023 at 7:51 AM Julius Künzel > <jk.kdedev-6p/pCUi/[email protected]> 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" <[email protected] > <mailto:[email protected]?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@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@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@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@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 >