Pecola1 wrote:
trinary wrote:
BLU_Spy wrote:
I do not support.
It‘s a good idea, but won‘t work at all.
Imagine Scratch as a bad word. They could say:
Scraatch
Scrach
5CR4TCH
SSSSSSScraaaaaaaaaatch
hctarcs
$cr@tch
And many, many, MANY others.
Sorry, but this idea is pretty useless. x(Exactly.
There are far too many possibilities and combinations which could escape the filter.Then how about they remove the filter for the comments of projects?
What would that do?
EVERY little things help. The can get around it, but those who say it wont care about getting banned, otherwise they would just not say it.
I support, it's just that the filter is not perfect.
Offline
Support This!
Offline
trinary wrote:
BLU_Spy wrote:
I do not support.
It‘s a good idea, but won‘t work at all.
Imagine Scratch as a bad word. They could say:
Scraatch
Scrach
5CR4TCH
SSSSSSScraaaaaaaaaatch
hctarcs
$cr@tch
And many, many, MANY others.
Sorry, but this idea is pretty useless. x(Exactly.
There are far too many possibilities and combinations which could escape the filter.
s--------------cratch
sc...ratch
scrαtch
s©ratch
scⱤatch
etc.
Offline
Perhaps just warn the viewer that there are cloud variables. All that has been posted before me bring up really good points, so maybe they should just be warned.
Offline
trinary wrote:
BLU_Spy wrote:
I do not support.
It‘s a good idea, but won‘t work at all.
Imagine Scratch as a bad word. They could say:
Scraatch
Scrach
5CR4TCH
SSSSSSScraaaaaaaaaatch
hctarcs
$cr@tch
And many, many, MANY others.
Sorry, but this idea is pretty useless. x(Exactly.
There are far too many possibilities and combinations which could escape the filter.
Someone on the forums (again, Scratch is a bad word) could say
SCRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATCH
sc r at ch
and all listed above.
That's like saying "Why have forum censoring"?
Offline
ManaUser wrote:
I don't like the idea of auto-censoring all cloud variables at all.
For one thing, they may not be intended as readable text. For example I'm working on a project with a level editor, eventually I want to make a version where you can publish those levels online. But the levels are stored using ASCII characters including letters. So what if a level level data just happened to contain letters that spell something rude? Should that be censored?
A related problem is exactly how this censorship should work. It would need to happen in a way that doesn't break the project. The simplest would be to completely ignore commands that would add a bad word to the cloud. But this would cause huge trouble. Suppose you had two lists:Code:
Bob How's it going? Lisa Nice day to today. Tony Not here, it's raining. :( Bob I like turtles. Tony I prefer gophers. Jamie Turtles scare me.But what if Lisa had said something bad and it got deleted?
Then it would turn into:Code:
Bob How's it going? Lisa Not here, it's raining. :( Tony I like turtles. Bob I prefer gophers. Tony Turtles scare me. JamieWhich makes no sense. A slightly better option would be to make it blank, rather than delete it, but an unexpected empty variable could still mess up a project. Replacing only the offensive word itself with asterisks would be the least likely to break things, but it woulds still cause very serious problems if the variable actually contained save data or something.
For all those reasons, I think providing blocks for detecting and/or censoring offensive words is a much option than trying to do it totally automatically.
Actually, Lisa's post would never appear so nobody would say "Not here, it's raining." unless they were very random...
Offline
ImagineIt wrote:
ManaUser wrote:
I don't like the idea of auto-censoring all cloud variables at all.
For one thing, they may not be intended as readable text. For example I'm working on a project with a level editor, eventually I want to make a version where you can publish those levels online. But the levels are stored using ASCII characters including letters. So what if a level level data just happened to contain letters that spell something rude? Should that be censored?
A related problem is exactly how this censorship should work. It would need to happen in a way that doesn't break the project. The simplest would be to completely ignore commands that would add a bad word to the cloud. But this would cause huge trouble. Suppose you had two lists:Code:
Bob How's it going? Lisa Nice day to today. Tony Not here, it's raining. :( Bob I like turtles. Tony I prefer gophers. Jamie Turtles scare me.But what if Lisa had said something bad and it got deleted?
Then it would turn into:Code:
Bob How's it going? Lisa Not here, it's raining. :( Tony I like turtles. Bob I prefer gophers. Tony Turtles scare me. JamieWhich makes no sense. A slightly better option would be to make it blank, rather than delete it, but an unexpected empty variable could still mess up a project. Replacing only the offensive word itself with asterisks would be the least likely to break things, but it woulds still cause very serious problems if the variable actually contained save data or something.
For all those reasons, I think providing blocks for detecting and/or censoring offensive words is a much option than trying to do it totally automatically.Actually, Lisa's post would never appear so nobody would say "Not here, it's raining." unless they were very random...
Nobody would randomly say "I like turtles" when the conversation is about weather, either.
Anyways, I think all of the problems could be solved if a moderator of the chat just hit a ban button, not using a script.
Offline