Documentation repository might grow due to new image library

[ann0see]

The new way of adding images results in all versions of images being saved by git. As time goes, the repo will get larger and larger (since the old images are still there.)

After thinking a bit more, I now remember why I created the assets repo: "assets" should contain all the binary data which might make a repo bigger and bigger.

I‘d suggest moving the pictures over to the assets repo.

Once in my past with another git repo this issue resulted in gigabytes needed to be cloned.

[gilgongo]

Seems a fairly simople change. Although it would still mean that clones of that assets repo may still get huge, but at least it doesn't affect everyone.

Would an alternative be to host them from sourceforge on https://images.jamulus.io in some way? Maybe that would be inconvenient in other ways.

We could go back to the old "userimages" method, but I think I'm right in saying we lose some formatting control that way, and if the same image is used multiple times (or even if it doesn't), it gets a unique URL so it's a pain to update...

[ann0see]

but I think I'm right in saying we lose some formatting control that way, and if the same image is used multiple times (or even if it doesn't), it gets a unique URL so it's a pain to update...

not necessarily: if we use a variable instead of a direct URL we can just drop the link in there and use this variable as Link for the src attribute. —> workflow would be comparable.

[gilgongo]

OK so that may be the better way if we have a bunch of variables with URLs like https://user-images.githubusercontent.com/4561747/124347037-0e0cb780-dbda-11eb-898b-1xxxxxx.png

Would mean quite a lot of variables though as they are for each language in many cases. Would replacing the image files with include files containing the userimage URLs be any easier for translators I wonder?

[ann0see]

Tagging @jujudusud and @ignotus666 for

Would replacing the image files with include files containing the userimage URLs be any easier for translators I wonder?

[ann0see]

I’d go for the variables in a separate .yaml file (which might even be translated. This allows might even allow us to include the images in the translation process.

The images could be similar to the navigation: https://github.com/jamulussoftware/jamuluswebsite/blob/release/_data/fr/navigation.yml

[gilgongo]

OK that sounds good then.

[ann0see]

Todo:

• Add an images.yml file to _data folder
• Update all occurrences from the old picture links on the whole website
• Remove all images from the website and upload it to GH userimages
• Update the README.md file to reflect the changes

Feel free to add more

[jujudusud]

Would replacing the image files with include files containing the userimage URLs be any easier for translators I wonder?

I don't really understand what is going on here. :-)
Please keep it simple as we just done with language directories and same images names...

[ann0see]

Unfortunately we can’t. The repo will get bigger and bigger with the current approach.

If you have any other ideas on image hosting feel free to suggest another approach.

[gilgongo]

I think "upload it to GH userimages" is:

1. Open Issue or PR on GH web.
2. Upload images to it.
3. Copy URLs generated.
4. Discard Issue/PR.
5. Paste URLs into images.yml

Is that right? Some room for mistakes there, but no much we can do :-)

[ann0see]

Yes. I think so?

[ignotus666]

Could this be of any use?

[ann0see]

Yes. This looks interesting and not too difficult to set up.

[ann0see]

@ignotus666 #556 just some basic tests with LFS. I added .po files for now since they change often. We'll probably need to change the GH actions scripts (checkout step) to ensure that the page gets deployed correctly.