Figure out a solution for storing image source files

[chrisdavidmills]

One of our contributors mentioned that it'd be really good to have a place to store image source files, e.g. the raw SVG or draw.io source version of the final image shown on an article, so that if it needs to be edited later on, the source version can be easily found.

Could we just start including an img-source folder in the Yari article folders? Would be good to discuss this at some point.

[peterbe]

There's nothing stopping you from putting those into the folder next to the index.html file. Unless... they're too large.
Git and GitHub has solutions: https://git-lfs.github.com/

I don't think we need to worry too much about a naming convention just yet. What might be confusing is that you might not quickly be able to see if img-source is a "special" folder or if it's just yet another sub-page like any other folder.

In terms of naming, we haven't been perfect, but we try to use the _ prefix for files that are a special. E.g. _redirects.txt.
They're basically. So if anything I would recommend that if you need upload a bunch of files that all relate to the same document. Note, the _ prefix actually doesn't do anything magical. It's just as nudge to remind you that this isn't related to a slug.

[peterbe]

By the way, I think we should transfer this issue to mdn/yari since it's not actually about the written content :)

[Ryuno-Ki]

From personal experience I can tell, that once a git repo approaches the ~4 GiB limit, you'll run into troubles.
Sure, that would be an option to look into Git LFS.
But perhaps, content like that could be put somewhere else (like Cloudinary?).

[chrisdavidmills]

Note, the _ prefix actually doesn't do anything magical. It's just as nudge to remind you that this isn't related to a slug.

So maybe we could use a directory called _img-source?

From personal experience I can tell, that once a git repo approaches the ~4 GiB limit, you'll run into troubles.

Hrm, I wonder how quickly we'd start to run into such problems! Maybe a better solution would be to store the source files in a different repo...

[peterbe]

Maybe a better solution would be to store the source files in a different repo...

And we can do lo-fi solutions like creating a file called _SOURCES which just talks about the name of the git repo where you can go to get the sources.

You're also free to use HTML comments within the text itself. Like:

<p>Lorem ipsum...<p>
<!-- Sources generating these PNGs are in https://github.com/mdn/chart-diagrams-draw.io -->
<img src="diagram.png" alt="Chart diagram">

[hamishwillee]

@peterbe @Ryuno-Ki Continuing discuss from #3652 (comment)

Peter, yes, compressing files is highly desirable, and my justification for not compressing the SVG was flawed as I can still edit the SVG very nicely in inkscape even following it's compression.

Note however that the compressed SVG is bigger than the equivalent file as a PNG, which is in turn bigger than a compressed JPG. Some might argue that we should therefore always save the file as a jpg. To me the convenience of having the source editable as SVG is well worth it. I think this should at least be considered as part of our "solution" to the problem.

The other "solution" is to store sources elsewhere and have an easy way to locate and manage them. That might be a simple as HTML comment alongside the image (which is what I normally do), a searchable database, or a github repo that duplicates the structure and filename so you can easily locate the source. The benefit of SVG over all of these is that things is that you don't have to separately manage your files - e.g. manage who has access, or keeping structures up to date.

[schalkneethling]

@fiji-flo Is this still an issue?

[hamishwillee]

Mostly it is a "question". It hasn't been fixed or discussed so IMO is still relevant.

[teoli2003]

Reading the comments, my question is: if I add an "original" file (like a Photoshop one) next to the index.md, will it be accessible from https://developer.mozilla.org ? (I hope not).

If not, we should just store them along. (and update the meta-docs hinting at clear names like original-picture.xyz.

[hamishwillee]

Yeah, that could work. Or you could argue that we should use SVG by default or some online editor or "whatever". I'm good with whatever as long as we have thought about it and agreed a general pattern.

[schalkneethling]

Yeah, that could work. Or you could argue that we should use SVG by default or some online editor or "whatever". I'm good with whatever as long as we have thought about it and agreed a general pattern.

This sounds like a discussion to me :) Which of the categories here do you think would be most appropriate? Content, platform?

[hamishwillee]

Content :-)

[schalkneethling]

Closing in favor of the following discussion: mdn/mdn-community#94 - Please add your suggestions and recommendation in the new discussion. Thank you, everyone!