The Translator

I've been poking around with the problem of the translator for a few days now, and I'm ready to start writing specifications. There are really two sides to the translator: the editor that feeds data into it, and the translator itself. The editor will be part of the Erasmotron, and the translator itself will be part of the runtime package.

The first issue I must face is whether to tokenize the translator variables. This certainly seems like the right thing to do, but it runs afoul of the TextEdit package in the Macintosh, which wants to edit text the standard way. I don't see any way that I can controvert the TextEdit package's methods, so I am stuck with conventional text entry.

One alternative is to provide icons that, when clicked on, will insert text variables into the the text stream. I'm sure that I can pull it off, but would it really save time? What about command keys or menus that accomplish the same thing? This strikes me as more efficient. Done.

Next question: what will the text variables be? Here's what I had in the previous version:

Name He Him HisHer HisHers

Subject X X X X X

DirObject X X X X X

IndObject X X X X X

IndObjectNumber

ThirdObjectName

ThirdObjectPerson

ThirdObjectNumber

ThirdObjectHim

ThirdObjectArray

In order to upgrade this to the current system, I'd need the following variables:

SubjectName, SubjectHe, SubjectHim, SubjectHisHer, SubjectHisHers

DirObjectName, DirObjectHe, DirObjectHim, DirObjectHisHer, DirObjectHisHers

CharacterObject1Name, CharacterObject1He, CharacterObject1Him, CharacterObject1HisHer, CharacterObject1HisHers

CharacterObject2Name, CharacterObject2He, CharacterObject2Him, CharacterObject2HisHer, CharacterObject2HisHers

ThingObject1Name

ThingObject2Name

StageObject1Name

StageObject2Name

VerbObject1Name

VerbObject2Name

NumberObject1Value

NumberObject2Value

That's 28 text variables &emdash; yow! I suppose I can handle that.

Now let's talk about all the grammatical elements. Should I just leave them the way they were? I suppose so. I'm not too penetrating today, am I?

Then there's the question of default values. I suppose that every textstring should default to <SubjectName> Verb_Name <DirObjectName>. Yeah, sure, sure.

Lastly is the matter of POVs. I had these POVs in the previous version:

GossipPOV = 1;

FollowupPOV = 2;

SubjectPOV = 3;

DirObjectPOV = 4;

SubjectFollowupPOV = 5;

DirObjectFollowupPOV = 6;

MenuPOV = 7;

ToArthurPOV = 8;

WitnessPOV = 9;

AdviseAgainst = 10;

AdviseNegative = 11;

AdviseUncertain = 12;

AdvisePositive = 13;

AdviseFor = 14;

WhatsGoingOn = 15;

ToldPOV = 100;

TellNewPOV = 101;

How should this list be changed? One possibility is to make the followup aspect automatic. That is, you can send a flag that specifies whether this sentence is to be presented as a followup, or as an original; then the code figures out the difference. But what would the storybuilder enter as the variable? Sometimes she wants a pronoun within the same sentence. This would really require doubling all the personal variables, e.g., SubjectHe, SubjectHeName, SubjectHis, SubjectHisName, and so forth. In each case, the former form would always substitute the pronoun, while the latter form would substitute the name if FollowUp = false, and the pronoun if FollowUp = true. This strikes me as overly tedious. On the other hand, all those extra POVs are even more tedious.

Now let's come to the matter of advice. Do we want to support this feature? For now, I think it best to dispense with it.

So let's see if we can't regularize these POVs. What are the combinations? The matrix crosses speaker/listener with Subject/DirObject/ThirdPerson and with tense:

Speaker Listener Tense Example POV Name

Subject DirObject Present "I pay you." PlayerActs

Subject 3rdParty Past "I paid Mary." PlayerTells

DirObject 3rdParty Past "Mary paid me." DirObjectTells

3rdParty 3rdParty Present "Mary pays Fred." WitnessSees

3rdParty 3rdParty Past "Mary paid Fred." WitnessTells

OK, this set looks fairly good. Let's print it.