19 replies to this topic

[purple]

Listers:

 

I'm embarrassed to ask this, but I can't find it in help and I can't figure it out by playing around. 

 

I understand the basic idea of sentences and variables.  Where in RM7 do I enter the sentence variables?  I know I enter the structure in the fact set up.  But, if I want to do one of those fancy compound sentences, where do I enter Piece 1, Piece 2, Piece 3, etc.

 

Also, the default sentence for the Anecdote tag is [M], but where does one actually enter the memo? 

 

I guess this is the same question posed in two different ways.

 

Thanks in advance

[Jerry Bryan]

There are two places. You go to Lists->Fact Type List if you want to change or set the sentence template for all sentences of that type. Pick the fact type, pick the role (usually Principal), and say Edit Role.

 

If you want to change the sentence template just for one fact for one person, you start with the Edit Person screen and edit the fact. Over on the right side of the screen about 2/3 of the way down, click on Customize Sentence.

 

Jerry

[purple]

Thanks Jerry.  I understand the global templates in the fact set up and I also understand the ability to customize a sentence anytime at the individual fact level of data entry.

 

But, here's my question ...

 

I want my sentence to say he had been married for [piece 1] years, and was reported to have [piece 2] children.

 

where piece 1 is 39 years of marriage and piece 2 is 8 children

 

where do I enter 39 and 8 and how should the format look?  39|8?

 

Similarly is the sentence for anecdote is [M].  Where does one enter the contents of [M]?  Is M just a custom sentence where you erase [M] and type something like:  A whole bunch of people came from their town in Germany and settled together in New Ulm? 

[zhangrau]

It sounds like you are a TMG refugee. RM does not have the capability to split the description/value element using the pipe "|" symbol.

 

Also, RM does not have a [M] variable.

 

The Help topic for "Sentence Template Language" seems very thorough to me.

[purple]

Well, Zhangrau, I am a TMG refugee and I'm trying to navigate my way.  I have split memos and witness memos from TMG and I'm trying to figure out what to do if I convert to RM7. 

 

Two points:

 

1)  The standard sentence in a brand new file in the anecdote fact was [M].  Not something that I imported.  I don't know where to enter data for [M].  I agree that the help file does not refer to the sentence variable [M] and hence my question.

 

2)  The following is from the sentence language help in RM7

 

Switches

A switch allows you to write different information, depending on the information that is available. Switches are contained inside of a less-than and greater-than sign (< >). Inside of the switch are any number of pieces, separated by a “|”. For example:

<First Piece|Second Piece|Third Piece|Fourth Piece>

You can set the kind of switch by using a special character after the first less-than sign. There are five special switch characters, ? for the Value switch, % for the Gender switch, @ for the Living switch, # for the Plural switch, and ! for the Private switch.

 

I think that this might be the same as "split memos" in TMG.  I was going to test it, but again, where do I put the "pieces"?

 

If you or anyone else out there is a TMG refugee and you have dealt with the split memo problem, I'd love to hear your experiences.  I'm not wedded to using the complex sentence structure in the future, but have to figure out what to do with what I have.  In fact, after all this hoopla over changing, I'd probably prefer to go with something less complicated.

 

Jane

[Laura]

Value switch:

 

<?[Expression]| Show this if true | Show this if false

 

[Expression] is the first piece, Show this if true is the second piece and Show this if false is the third piece.

 

<?[Date][Desc][Place][PlaceDetails]|[person:first] died< [Desc]>< [Date]>< [PlaceDetails]>< [Place]>< [Person:age]>|[person:first] has died>.

 

Expression:  [Date][Desc][Place][PlaceDetails]  RM checks to see if any of those fields have entries.  You can have all the fields in the expression or only the ones you want checked.

 

True, print this:  [person:first] died< [Desc]>< [Date]>< [PlaceDetails]>< [Place]>< [Person:age]>

False, print this:  [person:first] has died

 

Gender switch:

 

<%Male|Female|Unknown

<%[person:full]<, son of [Desc],>| [person:full]<, daughter of [Desc],>|[person:full]<, child of [Desc],>> was born< [Date]>< [PlaceDetails]>< [Place]>.

 

Male, print this:  [person:full]<, son of [Desc],>

Female, print this:  [person:full]<, daughter of [Desc],>

Unknown, print this:  [person:full]<, child of [Desc],>

Rest of the sentence:  was born< [Date]>< [PlaceDetails]>< [Place]>.

 

Parents are entered into the description which I have enabled for the Birth fact..

 

See the Help, Sentence Template Language article for adding different Sharee roles to the Principle's sentence for each switch.

 

Didn't you find it complicated to get the sentences how you wanted in TMG when you first started using it?  Everything is complicated when learning a new program.

[TomH]

That [M] variable did not come from a newly created, empty RootsMagic database. It came from outside RM. Have a look at http://sqlitetoolsfo... & Format Codesto gain some understanding of the relationships between TMG and RM sentence variables.

There are several other pages related to importing from TMG at http://sqlitetoolsfo...content?tag=TMG

And are you aware of the TMG-Refugees email list?

[zhangrau]

BIRTH
Original: [person] was born< [Date]>< [PlaceDetails]>< [Place]>.
Revised: [person]<% a male,| a female,| of unknown gender,> was born< [Date]>< [PlaceDetails]>< [Place]>.
 
Here's an example of how I used the pipe "|" to modify the standard Birth fact type sentence. Some users may decide that this revised sentence is too formal and redundant, but I have a number of individuals whose names don't follow my expectations. For example: males with "Marie" as part of their name; and females named "Clarence."

[purple]

Thank you all for your patience.

 

I got it.  Switches are for male/female or other conditions that will allow a single sentence to work in both cases.  I was confused. 

 

Yes, Laura, sentences were hard in TMG (and still are!) so I have to be patient with myself and my learning curve.  I haven't even imported my whole database yet.  I'm just experimenting to see what goes where and how it will work.

 

TomH, thank you for pointing me to the SQLite tools and also to the Refugees List.  I have read a lot, but one really needs to get in and "do" before everything sinks in.  The database tools are intriguing, but scare me a little.  After I get a more clear picture of what I really want, the tools may help me achieve it.

 

Zhangrau, I appreciate the example.  Seeing something in real practice makes it so much more understandable.

 

Jane

[Laura]

zhangrau, you are right.  My Birth sentence above did not take into account situations where you can"t tell gender by a person's name and the person has no parents entered in the description field.

 

So I rewrote the sentence.
[Person:full]<%, a male,|, a female,|, of unknown gender,><?[Desc]|<% son of [Desc],|, daughter of [Desc],>| unknown parents,> was born< [Date]>< [PlaceDetails]>< [Place]>.

The sentence I will probably use is:

[person:full]<%, a male,|, a female,| of unknown gender,> was born< [Date]>< [PlaceDetails]>< [Place]><?[Desc]| to [Desc]>.

When I get all the parents entered into the description field, I will add the False part to the Value switch:
[person:full]<%, a male,|, a female,| of unknown gender,> was born< [Date]>< [PlaceDetails]>< [Place]><?[Desc]| to [Desc]>| to unknown parents.

[Laura]

Jane,

When I experiment in a Play database, I open the Edit person screen of a person that has the fact I want to experiment with.

In the Customize sentence screen for that fact, I enter the sentences I am playing with.

Example:
1. [person:full]<%, a male,| a female,| of unknown gender,> was born< [Date]>< [PlaceDetails]>< [Place]>.
2. [person:full]<%, a male,|, a female,| of unknown gender,> was born< [Date]>< [PlaceDetails]>< [Place]><?[Desc]| to [Desc]>.
3. [person:full]<%, a male,|, a female,| of unknown gender,> was born< [Date]>< [PlaceDetails]>< [Place]><?[Desc]| to [Desc]| to unknown parents>.
4, [Person:full]<%, a male,|, a female,|, of unknown gender,><?[Desc]|<% son of [Desc],|, daughter of [Desc],>> was born< [Date]>< [PlaceDetails]>< [Place]>.
5. [Person:full]<%, a male,|, a female,|, of unknown gender,><?[Desc]| child of [Desc],> was born< [Date]>< [PlaceDetails]>< [Place]>.

The numbers makes it easier to see which sentence may need corrections and will be removed later.

I can change the sex of the person and enter or delete entries in the fact fields as needed to make sure my sentence is working as expected.  Save the fact before opening the Customize sentence screen again.  For Family facts, I may also need to check how the sentence is printing for the spouse.

[Laura]

zhangrau, you might like this Birth sentence:

[person:full]<@ is| was><% a male| a female| of unknown gender> born< [Date]>< [PlaceDetails]>< [Place]>

The Living switch, @, prints is if the Living tag is checked on the Edit person screen and prints was if the Living tag is not checked.
 

[zhangrau]

Laura suggested: "<@ is| was>"

 

If my database were more complete, I'd have a death date for everyone who has died. Sadly, despite my years of data collection, this is not true.

 

My construction of the Birth sentence is grammatically correct, in that every recorded Birth is a past event. On the other hand, with Laura's addition to my sentence, an individual who has a Birth event, but has died younger than the default age (110?) to trigger the Living switch to off, would be non-grammatically described with "is" (implying the person is alive), when in fact, I do not know that condition to be true. So I've decided to leave Laura's suggestion out of my sentence. But, of course, others may choose....

[Mercator]

 

When I store\enter the parents names in the birth desc field for a wife and enter the names of the husbands parents in his birth desc field, the birth sentences read correctly in a narrative report. (both wife and husband). However when you read the birth sentence of the "husband" on the "wife's narrative report" the names of the parents are repeated.  The same is true of the wife sentence on the husbands report.

 

Wife narrative:

 

1 Jane BATHA daughter of John V Batha and Jean Jacqueline Otto was born about 1950.

 

Michael Alan RUTZINSKI son of Roman Francis RUTZINSKI and Naomi Verlin APPLEGATE,, son of Romman Francis Rutzinski and Naomi Verlin Applegate, was born at Waukesha etc.

 

The second set of parent names are from the birth desc field.  I have checked this by using incorrect information.

[TomH]

RootsMagic's default setting for Birth leaves the Description field disabled and the standard sentence template does not have the [Desc] variable in it. Consequently, the narrative report uses a hard-coded sentence template for the spouse's Birth sentence, not the sentence template you see in Lists > Fact Types for Birth (or it hard codes an insert after [person] to add "son|dau of so and so"). There is nothing you can do about it afaik except to give up using the Birth Description field to identify the parents.

[Jerry Bryan]

There is nothing you can do about it afaik except to give up using the Birth Description field to identify the parents.

 

The same issue came up recently in another context in another thread. I am trying to change all my sentence templates to produce a much more terse narrative report than the default. My narrative reports are looking somewhat like family group sheets or a series of individual summaries or something like that. That obviously begs the question of why I should want to use narrative reports in a fashion that so abuses the way they are intended to be used, but we will let that issue slide for for the purposes of this message.

 

The problem I ran into is much more picayune than yours. Namely, my terse sentence templates result in an extra comma appearing in the sentence for the spouse. The comma shouldn't be there and I can't get rid of because it's hardwired in an invisible and undocumented sentence template that's internal to RM. I can get rid of my comma pretty easily by saving my narrative reports as RTF files and editing the files. But the underlying problem of the hardwired sentence template that you can't gain access to is not picayune and really needs to be fixed. I agree with Tom that there is nothing you can do about the problem until and unless RM exposes that secret sentence template to the user interface.

 

Jerry

[Mercator]

Thank you Gentlemen - the two words I did not want to hear was "hard code" but I did like "picayune" - I used to smoke them years ago.

[momakid]

I am trying to find or get a list of all of the variables to create sentences/templates with. I don't care if it is by query, I just need a query.  I actually prefer the query. I don't care if there is a document having the list. I just need a list that has all variables in it.

[TomH]

There is no SQLite query that can list all fact sentence variables. They are defined in program code. You have to trust the documentation to be complete and accurate.

[Nettie]

Suggest you look thru the old forum messages. For the given name Laura,  She gave us a lot of sentence suggestions over the time frame of when RM 3 made available  to us.  .  One thing I did to help me create new ones was made an Excel Sheet with the Fact list and included the sample template that was given in the original list.  Has had additions with each new Rev of RM.  Each time I found one on the forum a new choice I copied it to my Excel & OneNote  files.  and no I am not willing to share that file. Because every person has a different idea how the sentences should be done. 

 

Forgot one that Laura gave on 1 Jan 2014  was "You could enable the description field for the marriage fact."  /or any fact.  Which I did and included it in the sentence.  Was the best suggestion that I have.