there is XKCD for everything
kinda is...
It isn't, but [spacer told me to censor this] is. It's just a webcomic
don't mention that website on a PG-13 forum.
Well, whether or not it counts; I’m currently reading the PNG spec so I guess you win. 
Looks like we could fairly easily embed arbitrary text into a PNG image as metadata; you’d just have to come up with an appropriate key (Snap! Source or whatever).
It doesn’t look like JS supports reading or writing the metadata, but one could fairly easily write a minimal PNG parser that just supported (1) adding the text chunk to a PNG exported from canvas (or however you generate script pics) and (2) reading out the text chunk. Would that do you?
edit: Actually I think you want a “private ancillary chunk” rather than a “text” chunk, since this isn’t human-readable data. But same idea.
PNG? Isn’t this about scratch blocks
????? huh
I guess so... Ideally the code in Snap! that imports a project/library/block/script from XML would be able to extract the XML from a script picture, translate it to the current language as it does everything else in a project, display the result (or, for bulk translation, just display it virtually), and then re-export the picture with the same embedded XML but the block text in the picture would be in the chosen human language.
Thanks! 
I generalized the discussion a little, from scratchblocks™ the forum feature to the broad question of how to manage the display of code in a block-based language.
In the forum itself, I reiterate my opinion that using the "script pic" feature of Snap! (which I don't think exists in Scratch, or at least didn't when Tim invented scratchblocks) is much easier than hand-coding the Snap! code into this different language.
But there are a lot of contexts besides the forum in which one wants to display block code. One in particular, that we're actually working on now, is translating help screens to different languages. Most of this has been implemented by djdolphin, so that instead of representing help screens as PNGs as we've done historically, we have a help screen description language, so that instead of this picture:
we have this:
<help-screen version="1">
<blocks>
<block-definition s="map %'function' over %'data'" type="reporter" category="lists">
<header></header>
<code></code>
<translations></translations>
<inputs>
<input type="%repRing"></input>
<input type="%l"></input>
</inputs>
<script>
<block s="doIf">
<block s="reportListIsEmpty">
<block var="data"/>
</block>
<script>
<block s="doReport">
<block s="reportNewList">
<list/>
</block>
</block>
</script>
</block>
<block s="doReport">
<block s="reportCONS">
<block s="evaluate" highlight="true" annotation="1">
<block var="function"/>
<list>
<block s="reportListItem">
<l>1</l>
<block var="data"/>
</block>
</list>
</block>
<block s="reportMap">
<block var="function"/>
<block s="reportCDR">
<block var="data"/>
</block>
</block>
</block>
</block>
</script>
</block-definition>
</blocks>
<thumbnail>
<column>
<script>
<block s="evaluate">
<block s="reifyReporter">
<script/>
<list/>
</block>
<list/>
</block>
</script>
<script>
<block s="evaluate">
<block s="reifyReporter">
<script/>
<list/>
</block>
<list>
<l/>
</list>
</block>
</script>
</column>
</thumbnail>
<box color="gray">
<column>
<p>Call a reporter or predicate block.</p>
<diagram>
<block-definition s="map %repRing over %l" scale="0.9"/>
<annotations>
<small-p>
The input variable function has the reporter to call.
</small-p>
</annotations>
</diagram>
<diagram>
<script>
<block s="reportMap">
<block s="reifyReporter">
<autolambda>
<block s="reportSum">
<l/>
<l>3</l>
</block>
</autolambda>
<list/>
</block>
<block s="reportNewList">
<list>
<l>7</l>
<l>8</l>
<l>1</l>
</list>
</block>
</block>
</script>
<bubbles>
<img src="evaluate_list.png" width="80" height="70"/>
</bubbles>
</diagram>
</column>
</box>
<box color="blue">
<column>
<p>
The CALL block has a ring for its first input slot because it
expects a reporter or predicate as its input. Almost always,
though, you'll use a variable to provide the input value, as
in the example above. When you put a variable in a ringed
input slot, the ring disappears because it's the value of the
variable that gives the function to call. If you drag
anything but a variable into the ring, the ring remains
around the input:
</p>
<diagram>
<script>
<block s="evaluate" bubble="1">
<block s="reifyReporter">
<autolambda>
<block s="reportSum">
<l/>
<l>3</l>
</block>
</autolambda>
<list/>
</block>
<list>
<l>3</l>
</list>
</block>
</script>
<bubbles>
<text>8</text>
</bubbles>
</diagram>
</column>
</box>
</help-screen>
But instead of having to write all that XML by hand, or copy-paste it from a serialized script, it'd be a lot more convenient if we could just put the URL of the script pic, as generated by Snap!, unchanged, in the help-screen definition.
So, to make that work, the script pic has to include the actual script, not as pixels but as readable (by programs) text, namely the XML serialization of the script.
To be fair, I didn’t invent scratchblocks; JSO did! I just rewrote it, keeping the same language.
An interesting thing that occurred to me recently is that even if Scratch did have “script pic”, you can’t easily upload screenshots to their forum anyway.
edit: Oh and Brian, a fun thing about embedding XML into PNGs: you could set things up such that dragging a script pic PNG into the script pane in Snap! places the blocks! 
@bh heads up: you might need to revisit #1191 before you'll be able to get something like this into Snap! itself. Manipulating PNG files is probably gonna be easier with modern browser APIs like Blob and ArrayBuffer.
You don't still target IE, do you...?
No indeed not.
@bh Do you still want me to write you a proposal on embedding XML into PNGs? I don’t think I can write the code for you, but I could lay out how to do it for someone else to pick up 
Yeah, you're too late. Lucky you! :~)
how did you do that
dont necro 
[scratchblocks]
A hat and a (hat and a (hat and a (hat and a :: grey hat):: grey hat) :: grey hat) :: grey hat
Cap and a (hat and a (hat and a (hat and one last (hat :: grey hat) :: grey hat) :: grey hat) :: grey hat) :: cap
[/scratchblocks]