Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure out a solution for storing image source files #1678

Closed
chrisdavidmills opened this issue Nov 9, 2020 · 13 comments
Closed

Figure out a solution for storing image source files #1678

chrisdavidmills opened this issue Nov 9, 2020 · 13 comments

Comments

@chrisdavidmills
Copy link
Contributor

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
Copy link
Contributor

peterbe commented Nov 9, 2020

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
Copy link
Contributor

peterbe commented Nov 9, 2020

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

@peterbe peterbe transferred this issue from mdn/content Nov 9, 2020
@Ryuno-Ki
Copy link

Ryuno-Ki commented Nov 9, 2020

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
Copy link
Contributor Author

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
Copy link
Contributor

peterbe commented Nov 10, 2020

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
Copy link
Contributor

@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.

@github-actions github-actions bot added the 🐌 idle Issues and PRs without recent activity. Flagged for maintainer follow-up. label Nov 25, 2021
@schalkneethling
Copy link
Contributor

@fiji-flo Is this still an issue?

@github-actions github-actions bot removed the 🐌 idle Issues and PRs without recent activity. Flagged for maintainer follow-up. label Apr 15, 2022
@hamishwillee
Copy link
Contributor

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

@teoli2003
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

Content :-)

@schalkneethling
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants