Maintain two versions of the same text

I’ve got a story that I’m writing that will have some sexually explicit bits in it, and I want to pull those out into an adults-only version. Ideally there would be some knob or frob inside of Scrivener that would allow me to maintain both versions of the text in one file and then select the version to use at compile time with the flick of one checkbox or something silly like that. I’m betting that there is not such a feature, though (but how cool would it be if there was!).

So, assuming my bet is a good one, how do other people manage these types of things?

Sometimes a change could be just a few words that are different, other times a three-word sentence fragment in one text will turn into five paragraphs in the other.

Thanks!

Mark all of the naughty bits in RED??

For some similar purposes I use simple search and replace. If I was you, I’d keep only one Scrivener project and put the delicate parts inside tags, like: [censored] text her [censored].

After exporting or compiling, I’d create a duplicate: the other is to become the censored version, the other full. I’d use then an external editor and make a search for the tag [censored]. For the censored version I’d search for the tag and delete the content and tags as I go. If your editor supported wildcard search, it would save you from the manual work. For the uncensored version I’d simply replace the tags with nothing.

If the export contained several files, I’d use a great tool like TextFinderX sw.ixoft.com/texfinderx to remove the tags.

So I’m just suggesting textual tag use and simple search and search and replace.

I just noticed that Mariner Write marinersoftware.com/products/marinerwrite/ can find and replace text styles, also text colour. So this would work with druid’s color suggestion. I don’t know about other processors with this feature. However, Scrivener’s different Find options might offer a solution inside Scrivener.

If it’s a simple matter of removing explicit words or sentences (and not replacing them), then you can {surround the explicit words} in brackets like that. Then in the Replacements section of the Compile window, create a search for:
{.*?}
and replace with nothing. Be sure to mark it with the REGEX checkmark.

For the explicit version, search for:
[{}]
and replace with nothing. Again, check the REGEX checkbox.

The first will remove anything bracketed by curly brackets, plus the brackets themselves. The second will simply remove every left and right curly bracket it finds. You’ll probably want to save a “clean” and an “explicit” compile preset fore each of the replacements above.

Thank you robertdguthrie for this advanced tip! I’m just learning to use Scrivener and it sure seems there’s a lot to discover.

No problem. This is definitely advanced, but hopefully simple to implement with the info above. A couple of extra ideas have occurred to me…

First: You can highlight the bracketed text to make it stand out. There are options in the Transformations section of the Compile window that will strip out highlights, so you don’t have to worry about it ending up in your output.

Secondly, if you want to surround {explicit text with curly braces}, you can effectively have the “dirty/clean” texts right next to each other. You then just create a couple of more rules to strip out either all of the text between <>s or just the <>s themselves, following the pattern above.

Finally, If you want all the rules to be in the same compile window for easy reference, you can temporarily disable some of the rules simply by adding stuff in front of them that will not match anything in your text. For instance, editing:
{.*?}

to look like:
disabled–{.*?}

… in the search field of the Replacements window will effectively make it impossible to match, unless your text just happens to have the word “disabled” followed by two dashes immediately before a curly bracket.

This is not entirely related (and I didn’t start this thread) but speaking of replacements…

I need to transform the project into an HTML website, the texts being separate pages, and I wonder if there is a way to add something in the HTML head section? My piece of code would replace whateverishere part in the output. I doubt if Replacements in the Compile options are capable of this. I also assume the compile won’t allow me to have separate files like when exporting. When exporting, I don’t see any way of modifying the HTML head section.

I’ve never done any regex search and replace during compile – that will probably work just fine. Thanks!

Another way would be to create separate documents within the project for each version (remember that documents can be as short as one paragraph) and then use labels or custom metadata to distinguish between them. Then, when you compile, you can select which version you want (or create collections based on each version).

I suggest this because I find it very distracting/confusing having multiple versions in the body of the text. Invariably I end up with an unfinished sentence in one version, or a double space, or something not quite right. At least by separating them into separate documents you can use Scrivenings mode to ensure that each version reads correctly. With separate documents you could also view them side-by-side (in split screen mode) and see how each version compares.

I vote for nom’s suggestion as well, for pretty much the same reasons. Having two versions in the same document would drive me insane. Also, pulling the naughty bits out to separate documents might give you an extra layer of security relative to just using brackets and replacements: if it were me, I’d be pretty much guaranteed to inadvertently delete a set of brackets, causing massive havoc at compile time.

Katherine

I heartily endorse Nom’s suggestion if you have more than a couple of words or phrases to remove or swap; it’s really easy to get carried away with this technique, making for an unreadable draft. However, if you do go with my suggestion, I want to emphasize that you highlight the bracketed text. When you compile for proofing, don’t remove the highlighting. That way, you can easily spot the words or phrases that are left in your output. Once you are satisfied that everything is working properly, you can use the option to strip out highlights.

In fact, I suggest that you include highlights on all such phrases, no matter how you manage the alternate text.

Another, even more radical approach, would be to write one version, complete it, then lightly copyedit that version into the other. Write the naughty, finish it, clean it up for the nice version. Or write the nice version, finish it, dirty it up for the naughty version.

On the whole, I think a writer gets into some trouble in thinking that the only difference between such versions amounts to no more than a word or two.

But if that is indeed the case, how about this way? Write the naughty version, and mark each section that has naughty words with keywords – use the naughty words as key words. Then you can just pull up those sections and rewrite them. If indeed it is only a matter of bowdlerizing the naughty text, a compile-era replacements list might even do it (though that could get complicated).

  • asotir

I came into a similar problem when learning Scrivener and I approached it somewhat differently. I needed to test in front of two different audiences different tones for the same narrative voice: a formal one and a more colloquial one. This is very frequent in Spanish writing, and fortunately I managed to do it with Scrivener’s out of the box features.

I’ll try to give a simple example in English. I’ll use italics for the formal voice and underscore for the colloquial one.

Voice 1: You are just an incompetent and a clueless aspirant writer.
Voice 2: You are nothing but an asshole and a wannabe writer.

Then I wrote:
You are just an incompetent nothing but an asshole and a clueless aspirant wannabe writer.

I converted to comments everything that pertains to voice 1 (in italics above), and tagged as in-line annotations what pertains to voice 2 (underscored above).

Then I compiled the two versions changing just two settings in the Footnotes/Comments compile pane:

Voice 1 (formal)
Remove inspector comments (un-ticked)
Remove inline annotations (ticked)

Voice 2 (colloquial)
Remove inspector comments (ticked)
Remove inline annotations (un-ticked)

If you don’t want to leave evidence of the switch points just remove the brackets from the Inline annotation enclosing markers boxes.

This approach worked for me when using simple sentence rephrasing.

Just my 2 cents!