Sphinx Application Documentation - Image duplication

Ben Cooksley bcooksley at kde.org
Sun Jan 22 20:42:07 GMT 2023


On Mon, Jan 23, 2023 at 8:59 AM L. E. Segovia <amy at amyspark.me> wrote:

> Hi all,
>

Hi Amy,


>
> If I understand correctly, by doing what you said you would instead have
> a copy of each image per supported language-- only that squashed into a
> massive monolithic folder. Did you instead mean to symlink the
> "localized" image files to the source copies?
>

>From what Julius has found, all translated images have the language code
injected into the filename - with untranslated images being left unchanged.

Therefore, as pseudo-code:
- mv $root/en/_images/* $root/_images/
- mv $root/it/_images/* $root/_images/
- mv $root/fr/_images/* $root/_images/

Should achieve the objective of de-duplicating all of the images, as the
untranslated English screenshots should all overwrite each other - leaving
just a single copy of the English screenshots and all the translated ones
behind.


>
> Another idea I have is to preserve the localization step as is, but
> ignore the generated image folder, and in a postbuild step replace the
> <img src="localized image path"> with the path to the source folder. (I
> do something like this with a HTMLPipeline filter for my blog's emojis.)
>
> Cheers,
>
> amyspark
>

Cheers,
Ben


>
>
> PS: I've trimmed the CC as I wasn't sure if I should mail four lists at
> once. Feel free to forward the email if necessary.
>
> On 22/01/2023 16:02, Ben Cooksley wrote:
> > On Mon, Jan 23, 2023 at 7:51 AM Julius Künzel
> > <jk.kdedev at smartlab.uber.space <mailto: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/
> >     <https://my.kde.org/user/jlskuz/>
> >     Matrix: @jlskuz:kde.org <http://kde.org>
> >
>
> --
> amyspark 🌸 https://www.amyspark.me
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20230123/2ba722cf/attachment-0001.htm>


More information about the kimageshop mailing list