FindChangebyList with strings of text?

Question

I'm trying to setup a findchangebylist document to change strings of text to match my company's verbiage. I've been successful changing items like:  $10.00 to read as $10 but I cannot get regular text like:  over-sized to read as oversized
More examples of text I'm trying to convert:
over-sized to oversized
CAT to CAT(R)   (adding the registration mark)
screenprint to screen print
Is this possible with this script?? There's over 100 words that follow this mindset. The custom dictionary isn't something that works, as it only checks for single words and not 2 words with a space inbetween.
Anything would be helpful.
Thanks!

Answer 1

Hi Trevor:
I have to admit, I like your script (The syntax for the arrays is pretty clean, esp. with the tags) but we don't need to completely reinvent the wheel, and we have a lot of functionality within the FindChangeReplace script that wouldn't need too many more additions.
nukleas wrote:
 There is the conflict of case sensitivity and some words you don't want to close up. A good example of this is in official titles (So you don't want to close up Over-All Program Goals 2012, but you are fine closing up over-all goals or over-stated nature.
By adding a tag at the begining of words one wants to be stictly case sensertive one can deal with this
By useing slice and toUpperCase() one can make sure that over-sized becomes oversized and Over-sized becomes Oversized.
In the case that one only wants the upper case to be changed that would not need tagging i.e. in our example only CAT would become CAT®, cat would stay the same.
To avoid Over-All being closed one also would not need to tag it because of the capitol A of All.
One would only need to tag something like Over-all if one did not want it to become Overall but wanted over-all to become overall.
True, but why don't we just add this to FindChangeReplace:
grep     {findWhat:"(Over|over)-(?!\\u|\\d)(\\S*)"}     {changeTo:"$1$2"}     {includeFootnotes:true, includeMasterPages:true, includeHiddenLayers:true, wholeWord:true}
This way we don't need to write any more javascript code, and we preserve the features from that script, especially the option to do the search on individual stories or selections rather than the whole document, which is default for the script (I see these things usually from an inCopy standpoint, where you are working closely with the text) Having an easily editable text document as a list of things is probably not a bad idea either.
We also catch any hyphenations of digits (which we ought to keep hyphenated) or uppercase letters and keep whatever formatting existed previously with a single entry.
nukleas wrote:
Also, if whole word is turned on in the given regular text search example, over-size will not be converted to oversize. over-sized would be converted to oversize.
True, over-size would not be converted to oversize unless over-size was included in the word list.
False, over-sized would be converted to oversized and not oversize
Check the spelling in the script >.> (Yes, this is kinda pedantic, I apologize)
nukleas wrote:
This is also a concern copy editors have with closing up schoolteacher. In most cases it's fine, until you have a teacher that works at a high school. A high school teacher should probably not be written as high schoolteacher (although I'm sure some of them need to be to deal with some of today's youth.) and that's only really avoidable with a negative lookbehind.
This can easily be dealt with by adding in the array after the entry of ' school teacher'  , 'schoolteacher'
'high schoolteacher' , 'high school teacher'
see script below
Or in one line:
grep {findWhat:"(?<![high|elementary|middle] )([S|s]chool) (teacher)"} {changeTo:"$1$2"}     {includeFootnotes:true, includeMasterPages:true, includeHiddenLayers:true, wholeWord:true}
Using the FindChangeReplace, we basically configure the text or grep search each time, so if we want, we can have something like this:
Makes million/billion/trillion units not break over lines:
grep     {findWhat:"(\\d+) (mil|bil|tril)(?=lion)"}     {changeTo:"$0",noBreak:true}     {includeFootnotes:true, includeMasterPages:true, includeHiddenLayers:true, wholeWord:true}
This way we don't need to set about defining tags, since the way the script is written we can just call them when we need them.
And in this case, wouldn't we be in trouble if the query we wanted has a semicolon or something at the beginning of it? This can be the case in changing delimiters and other things. By defining options outside of the query, we better sanitize the query from errant symbols.
I think it might be best to also avoid changing things in the first place (like school teacher to schoolteacher and then backtrack with high schoolteacher to high school teacher) and the more exceptions or backtracks we need to make, the more likely errors will make it through.
Then again, for some, if not most changes that need to be made without exceptions, regular text search is fine. However, there can be a lot more errors introduced without lookaheads or lookbehinds than it could be worth, and this is one of the things that keeps copy editors like me employed
Also, with the script, why keep Pussy cat if it begins the sentence? The example would be perhaps the Pussy Cat Lounge, in that case you dont want to close that up or change that. However: Pussy cat is another term for a feline. Would not get changed, but it ought to. The script catches school teachers and high school teachers correctly, but not "School teachers are important to our nation" and (correctly) School Teacher's Association. These may need different capitalized versions of each type, or would possibly be better with grep and just brackets with both types alone. Case insensitivity in the grep can also preserve the capitalization of the original text, whereas I believe the text replace would change it to whatever the result is that is provided.
grep     {findWhat:"([pP]ussy) (cat)"}     {changeTo:"$1"}     {includeFootnotes:true, includeMasterPages:true, includeHiddenLayers:true, wholeWord:true}
(and the problem with this, that I would have to get to later, is that the plurals need to be dealt with)
All in all, I don't think it truly matters whether one uses GREP or text for such changes (it's actually best to know both!) and I appreciate you laying out how to perform these searches using javascript, I have definitely learned from it!
I apologize for any errors, I typed this quite fast D:
Many thanks Trevor,
Nukleas