Translator Formatting

OK, I'm back from my meetings with Markle and it's time for me to get cracking on this damn translator. I want it working by the end of the week!

 

My first problem is that the built-in text editor in the toolbox only handles conventional text editing. How am I to insert all the clever little delimiters that the translator needs to define its structure? It seems that such delimiters should be transparent to the user; she should see only the raw text, and the editor should insert the delimiters invisibly. This means in turn that my display will be very special. So, what will it look like? My first task is to define the various capabilities of the translator:

 

Variables: the substitution of character names, pronouns, stage and thing names into the text string.

 

Apposition: the creation of alternate words and phrases for portions of the text string.

 

Variation: the creation of alternate sentence structures for the text string.

 

POV: the different points of view required for the expression.

 

So we're talking about a basic template that is initialized to a basic format, and then permits substitution of text, variables, appositives, or variations. How are each of these to be substituted?

 

The basic text is easy: you just edit the text as you would any other text string.

 

Variables should be insertable via a menu, but they can be deleted or altered by regular text editing. Can they be copied or pasted? What to do here? I suppose that the best solution is to retain the old format of <VariableName>, which is then inserted automatically by the menu system. However, if the storybuilder wants to mess with it by hand, she's welcome to &emdash; and takes her chances with misspellings. The alternative is to use some special single character to represent a variable, but this would be unreadable. What if we used color or textstyle to indicate a variable? No, we can't do that: the text editor would get us into all sorts of messy trouble. Stick with the dumb delimiters.

 

Now we turn to Apposition. The old way of doing this is with curly braces and pipes, but the right way to display it is with the appositives in a vertical stack. This could be done if I break up the string into substrings, one for each appositive. Then menu commands could be used to create or destry appositives. My complaint about this is that it sure wastes screen space:

 

This is a sample sentence with many appositives.

some

a group of

a set of

 

I don't like that wastage. On the other hand, it vastly improves proofreading, so I suppose it's necessary. So what does it take to program? I need to set up a rectangle whose height is defined by the number of appositives, and whose width is equal to the widest appositive phrase. We can frame each such rectangle. You edit each singly, then they are assembled into the final text string which uses the old delimiter system.

 

Can I retrofit this idea to the use of text variables? Can a text variable be its own TERecord, inserted into a sequence, printed in its own color or style? Then we could just use a pop-up menu in its place, with no text editing of the thing. Yes, yes, that's it.

 

OK, onward to Variation. How to implement this? The old way used a single carriage return to indicate a variant sentence; I think that I need something else here. But wait, if I retain this system, then the system will output a text file that is readable and editable with a regular text editor, which would be critical for such things as global search and replace. Yes, let's retain the ability to import flat text; it gives us an extra level of flexibility. So now my only problem is the display of variants. It should be visually analogous to the display of appositives. Indeed, why not think of them as high-level appositives and low-level appositives? Then we use exactly the same visual approach... what would that look like?

 

This is a sample sentence with many appositives.

some

a group of

a set of

There are many ways to show apposition.

indicate

display

Sample sentences are not difficult to display.

easy

 

Yep, it wastes screen space. So what will I do if the display breaks out of a single page? Scroll? I suppose so. Harrumph, I hate scrolling. Perhaps I can scroll by POV rather than by text line. One thing's fer sure: fixed font size. None of this variable line height nonsense. I have more important things to worry about.

 

Let's do it.