I was working on a project which included a typewriter as well as the translate feature.
I translated “hello” to Spanish, and my typewriter appeared with the character I have chosen to show when a character is not supported then “ola” (“⍰ola”). I took out the translator function and noticed it changed “hello” to “Hola” and not “hola”.
My project uses lowercase letters as names but shows uppercase letters (which doesn't matter).
So, I suggest that Scratch should have a case sensitivity option. Above the scripts and below the stage (where sprite options are placed), there should be a “Case sensitive?” check box that when turned on makes all lists or names (especially in booleans) case sensitive when checked, and, of course, not when not checked. For example:

<(item (1 v) of [my list v] :: list) = [apple]>

Say that item one was “Apple”, not “apple”. If the case sensitive box was checked, then the result would be “false”. If it weren't the result would be “true”.
Do you see what I mean?
TL;DR: Scratch should add a Case Sensitivity option that allows you to change a sprite's decision based on whether a letter is capital or not.
Thanks for viewing and considering!
(If you didn't figure it out, case sensitivity is like when something matters if you didn't capitalize, e.g. Scratch usernames when entered aren't case sensitive but passwords are. Case being like upper- and lowercase.)
An alternative:

_nix wrote:

I'd {like to} see an extension which adds case-sensitive blocks, such as “case sensitive (A) = (B)”, alongside that “to (case)” block for use when you explicitly don't want case to matter (like in switch costume).

Hmm… personally, I think your issue is a really specific use-case. The problem is that switching between costumes is case sensitive, right? So in this case, I think you'd be better off with a more simple “to (lowercase/uppercase)” block. That way, in your typewriter project, when you do “switch costume to..”, you can just attach a “to (lowercase)” (or uppercase) block to “(letter (N) of (string)”.

A global toggle (well, per sprite, but still effectively limiting whether ALL scripts are or are not case sensitive) just doesn't seem very useful to me. I'd personally rather see an extension which adds case-sensitive blocks, such as “case sensitive (A) = (B)”, alongside that “to (case)” block for use when you explicitly don't want case to matter (like in switch costume).

Support!

This would be convenient for a lot of projects which include variables and operators. You could make more precise inputs, outputs, and statements, which would be really useful

_nix wrote:

Hmm… personally, I think your issue is a really specific use-case. The problem is that switching between costumes is case sensitive, right? So in this case, I think you'd be better off with a more simple “to (lowercase/uppercase)” block. That way, in your typewriter project, when you do “switch costume to..”, you can just attach a “to (lowercase)” (or uppercase) block to “(letter (N) of (string)”.

A global toggle (well, per sprite, but still effectively limiting whether ALL scripts are or are not case sensitive) just doesn't seem very useful to me. I'd personally rather see an extension which adds case-sensitive blocks, such as “case sensitive (A) = (B)”, alongside that “to (case)” block for use when you explicitly don't want case to matter (like in switch costume).

Thanks for the feedback However, I wasn't asking for help on my specific project, and it was actually more toward the list case sensitivity than the costumes I suppose. The block ideas are also cool, I'll update my original post to include that (with credit to you, of course)!

EIephant_Lover wrote:

Thanks for the feedback However, I wasn't asking for help on my specific project, and it was actually more toward the list case sensitivity than the costumes I suppose.

Oh, gotcha – yeah, an extension would need to have a “case sensitive item # of (x) in (list)” block, but…ew, y'know? That's super verbose. I can see why your idea would at least make that code look cleaner - it'd just be the ordinary “item # of (x) in (list)” block… however, they say explicit is better than implicit. When you see that block, you don't know how whether it is going to act case-sensitive or not, until you also see the state of the toggle for “is this sprite case sensitive?”. And I wonder if that could cause confusion to people reading the code.

(PS: What if for some reason you initially decide you don't want a sprite to be case sensitive, but then later you decide you do want it to be – and by that point, you'd forgotten the reason you wanted it to not be case sensitive, or even that you made that decision at all! So then the older scripts, which relied on it being not case sensitive, would suddenly be broken, which could be difficult to debug. Just an interesting situation to consider.)

-snip-

_nix wrote:

(PS: What if for some reason you initially decide you don't want a sprite to be case sensitive, but then later you decide you do want it to be – and by that point, you'd forgotten the reason you wanted it to not be case sensitive, or even that you made that decision at all! So then the older scripts, which relied on it being not case sensitive, would suddenly be broken, which could be difficult to debug. Just an interesting situation to consider.)

That's true. This, I suppose could be very confusing to younger Scratchers. Perhaps we could simply include the “case sensitive” blocks you were talking about, maybe as an extension, so you can do different things to different scripts.
Or maybe we could just do it on lists and variables, and have a “Case sensitive?” checkbox when making the list in the first place (as the cloud variable checkbox is).

So, this is what it would be like. The first blocks shows that item one of the list is indeed “Apple” rather than “apple”.

<(item (1 v) of [list v] :: list) = [Apple]> 

Output is true.

<case sensitive<(item (1 v) of [list v] :: list) = [apple]> ::operators>

Output is false.

<not <case sensitive <(item (1 v) of [list v] :: list) = [apple]> ::operators>>

Output is true.

EIephant_Lover wrote:

So, this is what it would be like. The first blocks shows that item one of the list is indeed “Apple” rather than “apple”.

<(item (1 v) of [list v] :: list) = [Apple]> 

Output is true.

<case sensitive<(item (1 v) of [list v] :: list) = [apple]> ::operators>

Output is false.

<not <case sensitive <(item (1 v) of [list v] :: list) = [apple]> ::operators>>

Output is true.

Ooh, this is something I was thinking about! I think it would be better to have a block like this:

<case [sensitive v] ​<(item (1) of [list v]) = [Apple]> :: operators booleans>
<case [insensitive v] ​<(item (1) of [list v]) = [Apple]> :: operators booleans>

That way we aren't messing with logic blocks.

That said, I'm sort of clueless on how one would actually implement this – obviously Scratch has never had any blocks like it. It would be, “first set a flag that the contained blocks should be executed case-sensitively (or not), then execute the contained blocks”; but as far as I can tell, Scratch block inputs are always executed before they're passed to the containing block. So I don't know if this would be possible with Scratch's code. But I think it would be pretty neat!

Oh yeah, one minor issue with it – suppose you want to stick “item #” into it? Then you'd get this (for example)..

say <case [sensitive v] ​(item # of [Apple] in [list v] :: list) :: operators booleans>

We'd probably need two blocks – one for round-shape reporters, the other for boolean reporters. And that feels a little like a kludge to me, since they'd have exactly the same behavior, just different shapes.

_nix wrote:

EIephant_Lover wrote:

So, this is what it would be like. The first blocks shows that item one of the list is indeed “Apple” rather than “apple”.

<(item (1 v) of [list v] :: list) = [Apple]> 

Output is true.

<case sensitive<(item (1 v) of [list v] :: list) = [apple]> ::operators>

Output is false.

<not <case sensitive <(item (1 v) of [list v] :: list) = [apple]> ::operators>>

Output is true.

Ooh, this is something I was thinking about! I think it would be better to have a block like this:

<case [sensitive v] ​<(item (1) of [list v]) = [Apple]> :: operators booleans>
<case [insensitive v] ​<(item (1) of [list v]) = [Apple]> :: operators booleans>

That way we aren't messing with logic blocks.

That said, I'm sort of clueless on how one would actually implement this – obviously Scratch has never had any blocks like it. It would be, “first set a flag that the contained blocks should be executed case-sensitively (or not), then execute the contained blocks”; but as far as I can tell, Scratch block inputs are always executed before they're passed to the containing block. So I don't know if this would be possible with Scratch's code. But I think it would be pretty neat!

Oh yeah, one minor issue with it – suppose you want to stick “item #” into it? Then you'd get this (for example)..

say <case [sensitive v] ​(item # of [Apple] in [list v] :: list) :: operators booleans>

We'd probably need two blocks – one for round-shape reporters, the other for boolean reporters. And that feels a little like a kludge to me, since they'd have exactly the same behavior, just different shapes.

Possible blocks:

Case sensitive {
Predicate <[] case sensitive ‹ [] :: operators>
Predicate <[] case sensitive = [] :: operators>
Predicate <[] case sensitive › [] :: operators>
Predicate <case sensitive Does text [] contain [] :: operators>
Reporter (case sensitive item  # of [] in [list v] :: list)
Predicate <case sensitive [ v] contains [thing] ? :: list>
}

Case insensitive {
Predicate <[] < []>
Predicate <[] = []>
Predicate <[] > []>
Predicate <Does text [] contain [] :: operators>
Predicate <[ v] contains [thing] ?>
Reporter (item  # of [] in [list v] :: list)

I don't know why but I feel like I'm confusing myself here… X3

Anyway, I look through this thread, and I also support, but with this in mind:

((string) to case [options v]::operators)

(with “options” being, primordially, UPPER, lower, or Title Case, among others)

I'm thinking Scratch should be case-sensitive by default with this block implemented, too.

When Windows crashes::hat events
if <<(desperate) > [50]> and <(Windows) < [0]>> then
go to [Testingsoftware 2.0 v]
say [This is the all-new, next generation Scratch OS]
end
stop [using Windows v]

_nix wrote:

-snip-

I don't think there's a need for a dropdown, as <not<case sensitive <>> would do just fine.

Monniasza_spzoo wrote:

-snip-

I don't see any need for this many blocks.

Testingscratcher wrote:

I don't know why but I feel like I'm confusing myself here… X3

Anyway, I look through this thread, and I also support, but with this in mind:

((string) to case [options v]::operators)

(with “options” being, primordially, UPPER, lower, or Title Case, among others)

I'm thinking Scratch should be case-sensitive by default with this block implemented, too.

I think this would be especially confusing, as I haven't heard case sensitivity for being other than the exact same casing, or casing doesn't matter. How would your block even work? If it was set to title, would Apple = ApPLE? Because they both have the first one done? Or, if it has to be the same title case, then there's no need for options as a “case sensitive <>” would work, as all it varies is whether or not the casing is exactly the same or not.

I feel really dumb.

I just realized I've made another thread like this.

Although the other is technically the dupe, I'm going to link it and close this as it makes more sense than this one.

https://scratch.mit.edu/discuss/topic/357768/

Thanks