Skip to main content
Topic: Word censor: should be thoroughly tested, yes? (Read 10687 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Word censor: should be thoroughly tested, yes?

Reply #15

Looks to be working as expected from what I can tell ....

The option was removed as a Theme option, so that old setting under Configuration -> Theme Settings -> Theme Options and Preferences has been removed  ....  meaning word censoring is no longer a per theme setting, but a general user setting.  Not sure why its still shown in the theme section, but from what I can see in the code, it does nothing.  Maybe @emanuele remembers.

The setting was also moved to be permission based, of which right now you don't have permission to change its setting so you don't get to see it (or change it).

Re: Word censor: should be thoroughly tested, yes?

Reply #16

Ok. So it's now set in permissons profiles then. I can see the logic of that, but I can also see that it's more likely to lead to confusion.

Although it would be silly having it as a per theme option, it seems to me that requiring it to be set for each permission profile is more trouble than it's worth. I can see that leading to hiccups with multiple membergroups, especially if some are added later.

If it's (the user option) just set globally on the censor page itself, it'll be easy for admins to deal with. Realistically I can't see that finer-grained control will ever be necessary.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Word censor: should be thoroughly tested, yes?

Reply #17

Quote from: Spuds – The setting was also moved to be permission based, of which right now you don't have permission to change its setting so you don't get to see it (or change it).
Thing is, you said that you had changed it in my profile, but that doesn't work either since the posts in this thread are still Bowdlerised in my browser. That means the permission profile is overriding direct action by an admin, which is a bit weird in itself.

ETA: And anyway, to see if it's all working as expected I'd still have to have the option enabled for at least one of my membergroups.
Last Edit: March 29, 2014, 07:12:10 pm by Antechinus
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Word censor: should be thoroughly tested, yes?

Reply #18

It seems like a poor idea to make word censor enabling a permissions option. Despite agreeing with Ant's OP, there are still going to be some people who freak out over profane words. Having the word censor off by default, and removing someone's ability to enable it, is going to cause more problems than it solves.

My suggestion is for the word censor to be a special permission. Everyone should have the ability to turn it on, if it isn't on globally. Disabling, however, can still be a permissions-based option.

So, for example, if I join a forum with the word censor turned on globally, and I do not have permission to disable it, I see nothing and posts are censored.

If I join a forum with the word censor turned on globally, and I have permission to disable it, I see an option to disable the word censor and posts can be uncensored.

If I join a forum with the word censor turned off globally, I see an option to turn on the word censor and posts can be censored.

Re: Word censor: should be thoroughly tested, yes?

Reply #19

mmm.... I have no idea... lol

Looking at git history, it was done when code was still in SVN, then not touched that much. If the option is still present in the themes settings page of the admin panel looks like a bug.

I'd say (and I'm scared by myself) I tend to agree with Ant: theme setting is silly, permission (and any kind of combination and special case) seems overkill.
Bugs creator.
Features destroyer.
Template killer.

Re: Word censor: should be thoroughly tested, yes?

Reply #20

@ET: That would be best, yes. SMF always had the first two, but not the third.

Easiest way out of it: the censoring interface page sets all of this in one place.

For best performance, censoring is disabled by default on installation.

If censoring is set for the whole site, admin can also choose to allow anyone (regardless of membergroup or permissions) to disable censoring in their browser.

The third option would be nice in theory, but frankly admins who don't care about censoring will probably not care about providing this option either. Keeping up with who is offended by what is a PITA, and there will always be new cases. At some point the answer is probably going to be along the lines of "gently caress off, princess".

ETA: Third option is also a performance hit, which is another reason admins may not bother.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Word censor: should be thoroughly tested, yes?

Reply #21

Come to think of it, why is the admin option allowed to override the user's choice of censoring anyway? Presumably censoring is provided for people who don't want to see profanity. There's no obvious need for an admin to decide that people who want posts uncensored shouldn't be able to have it that way, and like I said before this is actually better for performance.

So, having an admin option to disallow users choosing uncensored posts makes no sense whatsoever, either from the perspective of preventing conniption fits or from the perspective of performance. It's pure bonkers. It'd make far more sense to remove that setting entirely.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Word censor: should be thoroughly tested, yes?

Reply #22

Quote from: Antechinus – Come to think of it, why is the admin option allowed to override the user's choice of censoring anyway? Presumably censoring is provided for people who don't want to see profanity. There's no obvious need for an admin to decide that people who want posts uncensored shouldn't be able to have it that way, and like I said before this is actually better for performance.

So, having an admin option to disallow users choosing uncensored posts makes no sense whatsoever, either from the perspective of preventing conniption fits or from the perspective of performance. It's pure bonkers. It'd make far more sense to remove that setting entirely.

If I'm reading your post correctly, your suggestion is that admins should never be allowed to restrict users from removing the word censor?

I can actually think of situations where you'd want to do just that. An admin may be running a site with a specific culture, or catering to a specific group, who aren't fans of profanity. Or, it's possible that the board is being used for an official purpose, like for a public school, where using appropriate language is enforced. This can occur in a professional setting as well, where an employer would prefer to restrict such language from the discourse. Lastly, it's possible that a specific group of users might be under age, and thus the stipulation for their participation is a certain caliber of language. Honestly, it's no different than stopping users from linking to porn sites, if that's the culture the admin wishes to enforce.

That's not counting that the word censor can be used for non-profane words as well. There are a myriad of situations where an admin might use the word censor to replace words. They may use it to explain acronyms, restrict content or have a low-tech trigger word for certain situations.

I'm not sure that a vendetta against the word censor is a wise course.

Re: Word censor: should be thoroughly tested, yes?

Reply #23

Quote from: Eliana Tamerin – If I'm reading your post correctly, your suggestion is that admins should never be allowed to restrict users from removing the word censor?

I can actually think of situations where you'd want to do just that. An admin may be running a site with a specific culture, or catering to a specific group, who aren't fans of profanity.
In which case there would be nothing forcing those people to disable censoring, so how would it be a problem? Note that I'm assuming that if site-wide censoring is enabled, users would have to turn it off deliberately. I'm not assuming that if site-wide censoring is enabled, users would also have to turn it on.


QuoteOr, it's possible that the board is being used for an official purpose, like for a public school, where using appropriate language is enforced. This can occur in a professional setting as well, where an employer would prefer to restrict such language from the discourse. Lastly, it's possible that a specific group of users might be under age, and thus the stipulation for their participation is a certain caliber of language.
Same applies. The thing about trying to enforce censorship is that if you ban one incarnation of a word, someone will come up with another (like phuk or fukn, which are both in common use). So, if you really want to banish naughty words you have to constantly police the boards anyway, lest someobody come up with a variation to get around your settings.


QuoteThat's not counting that the word censor can be used for non-profane words as well. There are a myriad of situations where an admin might use the word censor to replace words. They may use it to explain acronyms, restrict content or have a low-tech trigger word for certain situations.
Ok, now you're making a solid argument.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Word censor: should be thoroughly tested, yes?

Reply #24

Quote from: Fukn Foul-mouthed Cunt – In which case there would be nothing forcing those people to disable censoring, so how would it be a problem? Note that I'm assuming that if site-wide censoring is enabled, users would have to turn it off deliberately. I'm not assuming that if site-wide censoring is enabled, users would also have to turn it on.
Oh hey, here's a genuine bug in the current code. So, to do the job thoroughly, the censor should be re-coded to also handle equals stuffz in BBC tags.

(I noitced this coz the quotes were saying AntiKynarzse instead of @Fart Knocker)
Last Edit: March 29, 2014, 11:07:18 pm by Spuds
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Word censor: should be thoroughly tested, yes?

Reply #25

You know, I've lost track of what anyone wants.  That being the case I'll do what I want, if thats anything at all :P

Re: Word censor: should be thoroughly tested, yes?

Reply #26

It's ok the way it is for 1.0, but could be improved a bit for 1.1.

ETA: Oh, apart from the bug with BBC tags content. That should probably be addressed for 1.0.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Word censor: should be thoroughly tested, yes?

Reply #27

Quote from: Spuds – You know, I've lost track of what anyone wants.  That being the case I'll do what I want, if thats anything at all :P

Simple. Keep the Word Censor.

If possible, allow users to always enable the Word Censor, but leave disabling as a permission or option or whatever you want to do.

Re: Word censor: should be thoroughly tested, yes?

Reply #28

I believe thats how its now (with pending PR), but that is one of those messy areas.  If it needs further refining (assuming I did not break anything), it can wait for 1.1

Re: Word censor: should be thoroughly tested, yes?

Reply #29

Quote from: Antechinus –
QuoteThat's not counting that the word censor can be used for non-profane words as well. There are a myriad of situations where an admin might use the word censor to replace words. They may use it to explain acronyms, restrict content or have a low-tech trigger word for certain situations.
Ok, now you're making a solid argument.
And that makes me think that the two should really be two different functions, working the same way, but two different config pages and two different options. I think.
Bugs creator.
Features destroyer.
Template killer.