I don't know if you accept ones with different languages so here's a Chinese one: https://scratch.mit.edu/discuss/topic/832470/

ScratchUser139 wrote:

I don't know if you accept ones with different languages so here's a Chinese one: https://scratch.mit.edu/discuss/topic/832470/

This is awesome, and I would be happy to link to localizations from the top of the guide! However, I want to just make sure that some basic quality stuff is met:

• Do you speak Chinese? Is this translated by hand (i.e. by yourself), or reviewed by a human (i.e. yourself)? I feel that representing an informational resource as “localized” when it was not first reviewed by a human is irresponsible, so this is important to me.
  
  
• Most of the [scratchblocks] are pretty much broken, which unfortunately renders the guide more or less useless. I don't know if the forums generally support multiple languages of localizations, but you can use ::operators, ::control, etc, on each block, to make it the appropriate category. (Please also make sure that the words on the blocks are the same as in the Scratch editor.)
  

_nix wrote:

ScratchUser139 wrote:

I don't know if you accept ones with different languages so here's a Chinese one: https://scratch.mit.edu/discuss/topic/832470/

This is awesome, and I would be happy to link to localizations from the top of the guide! However, I want to just make sure that some basic quality stuff is met:

• Do you speak Chinese? Is this translated by hand (i.e. by yourself), or reviewed by a human (i.e. yourself)? I feel that representing an informational resource as “localized” when it was not first reviewed by a human is irresponsible, so this is important to me.
  
  
• Most of the [scratchblocks] are pretty much broken, which unfortunately renders the guide more or less useless. I don't know if the forums generally support multiple languages of localizations, but you can use ::operators, ::control, etc, on each block, to make it the appropriate category. (Please also make sure that the words on the blocks are the same as in the Scratch editor.)
  

they change the localization pretty frequently, so code is usually out of date after a couple of years

ispretty wrote:

_nix wrote:

ScratchUser139 wrote:

I don't know if you accept ones with different languages so here's a Chinese one: https://scratch.mit.edu/discuss/topic/832470/

This is awesome, and I would be happy to link to localizations from the top of the guide! However, I want to just make sure that some basic quality stuff is met:
~snip~

they change the localization pretty frequently, so code is usually out of date after a couple of years

we can tell you used a translator. here are some other things that made me believe that:

• your topic’s text is also awfully close to google translate’s output if you feed nix’s post. getting such a high match rate is not as common as one might think.
  
  
• there’s a random o in the post at Google’s Translate character limit
  
  
• the tags that resemble words in english are translated, whereas the one-letter tags are not.
  
  
• text surrounded in quotes are not translated.
  
  
• the titles of topics in the “Where are the previous stickied Scratch workaround threads?” section are translated.
  

please do not use translators. the translations need to be correct, and translating with google translate or others causes innacuracies in the blocks.

_nix wrote:

Thank you for all the congrats, everyone! I'm very grateful

yavuz61035 wrote:

also, there is another method for (# of costumes)

... snip ... :: grey
switch costume to ((0) + (0))
repeat (2)
next costume
end
repeat until <(costume [number v] :: looks) = [1]>
next costume
change [count v] by (1)
end
... snip ... :: grey

This is a clever idea (so thanks to 1080GBA for suggesting it in the earlier thread too!)—I like how the “repeat until” loop only needs one conditional. It reminds me that I could have used my own “do…while” workaround to calculate the list of costumes:

delete all of [costume names v] :: list
switch costume to ((0) + (1))
set [condition v] to [false]
repeat until <(condition) = [true]>
  add (costume [name v] :: looks) to [costume names v]
  next costume
  set [condition v] to <(costume [number v] :: looks) = [1]>
end

This requires an extra variable, though

When I'm adding a workaround, I try to think of the simplest way to do it—the one which requires the least previous understanding of other topics. So like, these are great ways to use loops to calculate how many costumes there are (or to make a list of costume names), but a Scratcher reading it does need to understand how to use loops for stuff besides animation for the workaround to make sense.

That doesn't mean I don't want to teach new concepts with workarounds—that's actually the main point of this thread! But, I'm careful to pick and choose which new ideas I want to focus on. In the Control section, for example, talking about loops (and unique ways of using them) is really natural, because the person who is reading is already learning about control structures and different kinds of loops. But complex ways of using loops don't fit the Looks section quite as well, because there, the reader is probably way more interested in animating their sprites with handy blocks than anything to do with customized control structures.

That's why in the Looks section, I try to place a focus on unique behavior of Scratch looks blocks: I combine “switch to final costume” (switch costume to 0 + 0) with “costume number” because it's pretty intuitive when you think about it, and it shows a creative way to get more useful behavior from another workaround. I think it's an interesting solution to the problem which focuses on Looks behavior, teaching relevant new concepts and showing a different way of solving the problem than you might've thought of, hopefully helping spark new ideas and solutions to more involved problems later on

BTW, this is why a bunch of workarounds have more than one method, especially in the Control section where what you're doing is more abstract—if I can't decide between two approaches and they both show educational, focused ways to tackle the problem, I include ‘em both! So when the reader compares, they aren’t just choosing which one they like better…I'm also sneakily tricking them into noticing the differences and learning how they might choose between two solutions to their own unique coding challenges :D

Just do this to get rid of that extra variable

delete all of [costume names v]
switch costume to (round (0))
repeat (costume [number v])
next costume
add (costume [number v]) to [costume names v]
end

jmdzti_0-0 wrote:

we can tell you used a translator. the blocks’ text can’t have possibly changed since Yesterday 11:09:02 (which is definitely “not a couple of years”). here are some other things that made me believe that:

• your topic’s text is also awfully close to google translate’s output if you feed nix’s post. getting such a high match rate is not as common as one might think.
  
  
• there’s a random o in the post at Google’s Translate character limit
  
  
• the tags that resemble words in english are translated, whereas the one-letter tags are not.
  
  
• text surrounded in quotes are not translated.
  
  
• the titles of topics in the “Where are the previous stickied Scratch workaround threads?” section are translated.
  
  
• your scratch profile says you are from the us. i didn’t think much about this, since people can learn languages, but i thought it’s worth putting it in the list
  

please do not use translators. the translations need to be correct, and translating with google translate or others causes innacuracies in the blocks.

You quoted a different person I just noticed

jmdzti_0-0 wrote:

ispretty wrote:

_nix wrote:

ScratchUser139 wrote:

I don't know if you accept ones with different languages so here's a Chinese one: https://scratch.mit.edu/discuss/topic/832470/

This is awesome, and I would be happy to link to localizations from the top of the guide! However, I want to just make sure that some basic quality stuff is met:
~snip~

they change the localization pretty frequently, so code is usually out of date after a couple of years

we can tell you used a translator. the blocks’ text can’t have possibly changed since Yesterday 11:09:02 (which is definitely “not a couple of years”). here are some other things that made me believe that:

• your topic’s text is also awfully close to google translate’s output if you feed nix’s post. getting such a high match rate is not as common as one might think.
  
  
• there’s a random o in the post at Google’s Translate character limit
  
  
• the tags that resemble words in english are translated, whereas the one-letter tags are not.
  
  
• text surrounded in quotes are not translated.
  
  
• the titles of topics in the “Where are the previous stickied Scratch workaround threads?” section are translated.
  
  
• your scratch profile says you are from the us. i didn’t think much about this, since people can learn languages, but i thought it’s worth putting it in the list
  

please do not use translators. the translations need to be correct, and translating with google translate or others causes innacuracies in the blocks.

Oh that’s possible, I didn’t realize the post was made recently

ispretty wrote:

jmdzti_0-0 wrote:

ispretty wrote:

_nix wrote:

ScratchUser139 wrote:

I don't know if you accept ones with different languages so here's a Chinese one: https://scratch.mit.edu/discuss/topic/832470/

This is awesome, and I would be happy to link to localizations from the top of the guide! However, I want to just make sure that some basic quality stuff is met:
~snip~

they change the localization pretty frequently, so code is usually out of date after a couple of years

we can tell you used a translator. [snip] please do not use translators. the translations need to be correct, and translating with google translate or others causes innacuracies in the blocks.

Oh that’s possible, I didn’t realize the post was made recently

Ah, and I didn't realize it was someone else who'd made the post, not you, since both your account and theirs have no user profile picture. I think jmdzti_0-0 made the same mistake. Sorry for the confusion. Of course, I'm still interested in linking to localized versions of the guide, but I'll leave that to whoever would like to make those, now that we've laid out our basic expectations. Thank you for sharing the link as you found it, in any case!

We may need a block for pausing sounds.

Pause all sounds::sound

_nix wrote:

Ah, and I didn't realize it was someone else who'd made the post, not you, since both your account and theirs have no user profile picture. I think jmdzti_0-0 made the same mistake. Sorry for the confusion. Of course, I'm still interested in linking to localized versions of the guide, but I'll leave that to whoever would like to make those, now that we've laid out our basic expectations. Thank you for sharing the link as you found it, in any case!

I did the same thing LOLL

how have I never realized, what's the point in having

switch backdrop to ( previous backdrop v)

when we can:

switch backdrop to  ((backdrop [number v]::looks) - [1]) 

CodeComet6161 wrote:

how have I never realized, what's the point in having

switch backdrop to ( previous backdrop v)

when we can:

switch backdrop to  ((backdrop [number v]::looks) - [1]) 

Yeah, but think about the logic: if the backdrop number is 1 and we substract 1 too it will give 0, but scratch gives out the max backdrop.

Imtwentytenth wrote:

CodeComet6161 wrote:

how have I never realized, what's the point in having

switch backdrop to ( previous backdrop v)

when we can:

switch backdrop to  ((backdrop [number v]::looks) - [1]) 

Yeah, but think about the logic: if the backdrop number is 1 and we substract 1 too it will give 0, but scratch gives out the max backdrop.

the max backdrop and 0 are the same thing

ispretty wrote:

Imtwentytenth wrote:

CodeComet6161 wrote:

how have I never realized, what's the point in having

switch backdrop to ( previous backdrop v)

when we can:

switch backdrop to  ((backdrop [number v]::looks) - [1]) 

Yeah, but think about the logic: if the backdrop number is 1 and we substract 1 too it will give 0, but scratch gives out the max backdrop.

the max backdrop and 0 are the same thing

I honestly thought that's what the post meant, but now I don't know

Here is another one but it's probably too simple:
Floor division (which is different from floor ())

((num1) - ((num1) / (num2)))

or some combination… idk
Also, this thing hasn't been updated since the big 2025, either someone else should take over, or you can update it with every workaround that deserved to be added.

CodeComet6161 wrote:

Here is another one but it's probably too simple:
Floor division (which is different from floor ())

((num1) - ((num1) / (num2)))

or some combination… idk
Also, this thing hasn't been updated since the big 2025, either someone else should take over, or you can update it with every workaround that deserved to be added.

Uh.. that doesn't work. I think this is a good workaround:

([floor v] of ((a) / (b))::operators)

I requested a new operator for “mapping” values from one range to another, and @The_Cool_Scratch_Guy (The guy that posted above me) already had this. Here's his code to add to the workarounds:

define map (input) (startmin) (startmax) (endmin) (endmax)
set [startrange v] to ((startmax) - (startmin))
set [endrange v] to ((endmax) - (endmin))
set [output v] to ((input) - (startmin))
set [output v] to ((output) * ((endrange) / (startrange)))
set [output v] to ((output) + (endmin))

Cat2437 wrote:

I requested a new operator for “mapping” values from one range to another, and @The_Cool_Scratch_Guy (The guy that posted above me) already had this. Here's his code to add to the workarounds:

define map (input) (startmin) (startmax) (endmin) (endmax)
set [startrange v] to ((startmax) - (startmin))
set [endrange v] to ((endmax) - (endmin))
set [output v] to ((input) - (startmin))
set [output v] to ((output) * ((endrange) / (startrange)))
set [output v] to ((output) + (endmin))

Can you link us to the post or project where @The_Cool_Scratch_Guy shared this workaround? Also, how does this look for the workaround's adapted code and text, in the guide?

✽ map / scale from one range to another

For example, the number 50 is halfway between the range 25–75, so mapping it to 0–10 will give you 5, or mapping it to 30–150 will give you 90. This workaround might be easiest to visualize in your head (or on paper!) by drawing number lines: it's like matching a point on one number line to a point on another number line, only the number lines can be different length, and they might start at different numbers, instead of zero.

define map (number) from range: (min1) to (max1) to range: (min2) to (max2)
set [scale factor v] to (((max2) - (min2)) / ((max1) - (min1)))
set [rounded v] to ((((number) - (min1)) * (scale factor)) + (min2))

I tried writing a more detailed explanation, but it got super math-y, and I think the number line analogy does enough to explain basically what's going on.

_nix wrote:

Cat2437 wrote:

I requested a new operator for “mapping” values from one range to another, and @The_Cool_Scratch_Guy (The guy that posted above me) already had this. Here's his code to add to the workarounds:

define map (input) (startmin) (startmax) (endmin) (endmax)
set [startrange v] to ((startmax) - (startmin))
set [endrange v] to ((endmax) - (endmin))
set [output v] to ((input) - (startmin))
set [output v] to ((output) * ((endrange) / (startrange)))
set [output v] to ((output) + (endmin))

Can you link us to the post or project where @The_Cool_Scratch_Guy shared this workaround? Also, how does this look for the workaround's adapted code and text, in the guide?

✽ map / scale from one range to another

For example, the number 50 is halfway between the range 25–75, so mapping it to 0–10 will give you 5, or mapping it to 30–150 will give you 90. This workaround might be easiest to visualize in your head (or on paper!) by drawing number lines: it's like matching a point on one number line to a point on another number line, only the number lines can be different length, and they might start at different numbers, instead of zero.

define map (number) from range: (min1) to (max1) to range: (min2) to (max2)
set [scale factor v] to (((max2) - (min2)) / ((max1) - (min1)))
set [rounded v] to ((((number) - (min1)) * (scale factor)) + (min2))

I tried writing a more detailed explanation, but it got super math-y, and I think the number line analogy does enough to explain basically what's going on.

https://scratch.mit.edu/discuss/post/8730447/ Here's the original post

After reading the table of contents, I realized that there isn't a Workaround for the sounds category blocks, which is surprising since every other category has been covered. So I figured I would give my suggestion (note, this trick has been widely known & used. However I suggested it to make the list feel more complete and for people who do not know it) This is for the

pause sound:: sound

and

unpause sound:: sound

——————————————————————-
(I'l be setting u & p for the unpause and pause keys respectively but you can set the keys to anything you'd like or you can start the scripts with a broadcast or any other trigger)
You could just do

when [p v] key pressed
set volume to (0) %

and

when [u v] key pressed
set volume to (100) %

for the pause and unpause blocks respectively, but if you want the sound to start where it was stopped, you can do

when [p v] key pressed
set [pitch v] effect to ((-1) / (0))
set volume to (0) %

and

when [u v] key pressed
set [pitch v] effect to (100)
set volume to (100) % 

The

((-1) / (0)) 

block gives you -Infinity and “pitch” doesn't just lower the pitch but the lowers the speed of the sound so when the earlier equation is used for the pitch, it makes the sound s u p e r s l o w and the set volume to (0) % block hides the slowed down sound and finally the latter script reverses the effect of the former script.