check input for gibberish

Isskint

Slowly Developing
Local time
Today, 22:26
Joined
Apr 25, 2012
Messages
1,302
Hey gang :p

I am looking for a way to check a string for gibberish. So aaaaaa, bbbbb, lsdjadjlajdkljas etc is not allowed.

Now i have done this thus far for aaa bbb etc by using INSTR() through a loop through an array, but obviously you need to anticipate EVERY conceivable piece of gibberish.
Code:
Public Function ValidString(Phrase As String) As Boolean

Dim strValid As String
Dim strArray() As String

strArray = Split("aaa|bbb|ccc|ddd|eee|fff|ggg|hhh|iii|jjj|kkk|lll|mmm|nnn|ooo|ppp|qqq|rrr|sss|ttt|uuu|vvv|www|xxx|yyy|zzz", "|")

ValidString = True

For Each Gibberish In strArray
    If InStr(Phrase, Gibberish) <> 0 Then ValidString = False
Next Gibberish

End Function

Is this achievable, perhaps pattern matching with VBScript.RegExp OR assigning a value to identify consecutive/repeated letters from the keyboard?
 
Well for a start, you could run a spell check.
But of course, that's only part of the answer as something can be spelt correctly but still gibberish in the context it has been used.

Anyway GIGO ...
 
Thanks Colin. Thought about using spell checker, however there are a lot of abbreviations used (different users use different abbreviations!) so can not 'allow' for that. Plus the environment is a call center and they are not too bothered about correct spelling!
 
...Now i have done this thus far for aaa bbb etc by using INSTR() through a loop through an array, but obviously you need to anticipate EVERY conceivable piece of gibberish...

You've really answered your own question...how could expect Access to recognize every conceivable piece of gibberish if you don't tell it what constitutes gibberish?

I think, from a practical standpoint, about all you can do is run SpellCheck and let the users have their legitimate abbreviations saved into the SpellChecker's dictionary by hitting the 'Add' button when one of them comes up.

If, for instance, abbr is legitimate, when it is flagged by SpellCheck, the user clicks on 'Add' and it will never be flagged again, for that user/on that installation of Access.

Linq ;0)>
 
I agree with Colin and Linq -spell check and "accepted terms/abbrevs" would seem to cover most things (relatively easy). Trying to outguess the weirdos/saboteurs may not be worth the effort.

Isskint, what exactly is the business issue? What sort of info do you expect in typical strings?
 
Damn, I checked the list and Windows doesn't list Gibberish as a supported language...

Your problem in a nutshell is that even spell checkers that allow words to be added to a dictionary don't do so well. And let's not forget our old friend Grammatik (that eventually got folded into Word's grammar style checker). They can't get it right. As a hobby, I write fantasy fiction. There is no "fiction" setting on the grammar checker so I had to set it to "government documentation." (It was the closest match of all the styles.)

I'm in a playful mood here but I'm serious, too. The problem with finding Gibberish is that you WILL find it, right where you expect it. Because you are dealing with people who are in a rush to finish one call and get to the next, so they abbreviate the best they can.

In a sense, if you tried to filter their words through a spell checker or grammar checker, you would probably find that you would slow them down and make them less effective in handling calls. So in your attempt to improve the readability of the text, you will decrease your call throughput. That isn't a call for you to make. That is for the call center director to decide that it is a good thing or a bad thing. Perhaps the issue is one of training? Perhaps it is that they have different educational backgrounds? Who knows? Who cares? The real question is whether there is a "sweet spot" that offers a balance between legibility and volume.

There is one other business where it appears that legibility is not that important. Have you ever tried to read one of your doctor's handwritten prescriptions? Now THERE'S food for thought...
 
Having worked in a call center doing customer service (I know, right?!?), believe me, the director isn't going to be interested in proper spelling and grammar in the notes, especially if requiring it slows down call handling. As long as the notes are legible, they're good enough.

Bsclly, goal is effcy, not accrcy, & if csr cn rd ntes, thn no prob. :D
 
"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools" - Douglass Adams, Mostly Harmless
 
Thank you all for your inputs.

I was hoping someone, somewhere had figured a way to check for this. But as Linq pointed out, i had really already answered it:rolleyes:

I did find a list of pairs of consecutive letters that do not show up in words in the English language, so i have added that to the array.
 
I agree with Colin and Linq -spell check and "accepted terms/abbrevs" would seem to cover most things (relatively easy). Trying to outguess the weirdos/saboteurs may not be worth the effort.

Isskint, what exactly is the business issue? What sort of info do you expect in typical strings?

The context here is at the point of closing a case. The agent is required to record the method used to resolve the case (to be used as 'library' for future cases). Whilst retrospectively the call center manager can keel haul lazy agents, it then takes time to remember and update the entry (which is a dev only as the field is locked on every form it is displayed!)
 
I sympathize. I worked for many years at the Navy Enterprise Data Center in New Orleans where I was a tier III responder (for problems specific to the system I was managing at the time). Our calls came from the entire US Navy Reserve, so you might guess our call volume wasn't small.

We were ALWAYS getting pinged from management on unintelligible entries in our case closure notes. Your problem isn't unique and I sympathize. But in the final analysis, you have to have a buy-in from the people who use whatever you make. If they don't like it, they will complain about YOU getting in THEIR way (instead of you complaining about their unreadable inputs). I've been on both sides of that argument. Lost both times, because it is truly a no-win scenario. Or perhaps just a very difficult "finding the balance" situation.
 

Users who are viewing this thread

Back
Top Bottom