Closed MayaGans closed 4 years ago
Yes - what we really need is a runnable script that creates one block of each type and saves the SVG. I was never able to get this working on the command line - Blockly wants a browser with DOM in order to create a block - but it would help documentation efforts a lot. @just-singh or @MayaGans can you think of a way to do it? That way we could regenerate all the "screenshots" automatically whenever we update styles or translations.
What about just having a button on the actual page that (1) deletes all blocks from the workspace, (2) loops over each block adding it, saving the svg, and then deleting it, (3) spits out a file with everything. We'd hide it in some 'developer mode' later so users don't see it.
At first glance it looks like we can do the block manipulation stuff (adding/deleting) with code, and maybe use https://www.npmjs.com/package/adm-zip to bundle all the SVG files without saving to disk. Would need to test to confirm though.
I can try it out tomorrow if that makes sense.
So uh.... I deleted the front matter in the index.mds because it was annoyingly rendering on the page.... so now I use full paths for each svg (this was super fun to manually update 🤦♀️ )
<img class="block" src="{{ 'en/data/user_data.svg' | relative_url }}" alt="user data block"/>
So maaaybe once @DarkMetroid applies some dark magic batch SVGing we can add those all to an img folder en/img
es/img
etc etc that contains ALL the SVGs per language once we have this magical script? Then I can change all the paths to
<img class="block" src="{{ 'en/img/user_data.svg' | relative_url }}" alt="user data block"/>
Rather than having the svgs divided into subgroups? (one big en/img
rather than en/data/*
en/transform/*
etc etc)
I do love the idea of automating this process....
Just checked out @gvwilson's PR that changes the folder names (which I did not consider when making all those manual paths above 😬 ) so I think I like this img
folder idea even more now since i had to change:
<img class="block" src="{{ 'en/data/colors.svg' | relative_url }}" alt="color block"/>
<img class="block" src="{{ 'es/data/colors.svg' | relative_url }}" alt="color block"/>
Which given that PR I'd need to go in and change data
to datos
etc
So we'd just need to do a search and replace for the language if we change to
<img class="block" src="{{ 'es/img/colors.svg' | relative_url }}" alt="color block"/>
Happy to do the grunt work and change X
in es/X/blah.svg
to img
if we want to go this route
Keeping them together makes sense to me, will keep that in mind.
I was wondering if we want to replace all the block svgs in the es directory with the Spanish blocks since the images no longer reflect the blocks?
[ie this should be a crear block, not create]