* Fact Note Sentence issue (TMG Imported template)

[cjdenbow]

I'm a TMG refugee. I'm still trying to sort things out as the TMG specific import while it did many things well also has created some problems. Here is one that been giving me a headache:

The Fact Note sentence template imported from TMG seems to have an error in it somewhere, but I can’t figure out the best way to modify it. The sentence template is:

“{individual} <and {=Witness(%FACT%,"Principal 2")}> {note} {date} {place}”

It seems to produce undesirable results. For instance, when a Fact Note of “was a test” is entered on a Facts List of a particular individual, it is rendered in both FH and John Cardinal's GedSite as the following sentence: “He. was a test in 1943 in test place.”

Where is this "He." coming from? How do I modify the template to make it read like an actual sentence? Also, shouldn't this refer to "Principal 1" rather an "2"?

Any help you can give me on this issue is greatly appreciated. Thanks.

Carl

[ColeValleyGirl]

I'm away from my pc but if you search the forums you'll find a discussion about the difference between {note} which is assumed to be one or more complete sentences, so gets a full stop before it and {inline-note} which is assumed to be a text fragment and doesn't get punctuation added.

[LornaCraig]

The change Helen is referring to came in with FH v 7.0.17. This is from the release notes:

There is a new template code, {inline-note} which can be used in sentence templates, if you want to insert a note into a sentence, without treating the note as the start of a new sentence. The code {note} still exists but should only be used for notes which consist of one or more sentences.

When v7.0.18 was introduced CP went a step further so that the new {inline-note} code is now used when importing from TMG (but too late for you, as you have already done your import!)

This is from the V7.0.18 release notes:

When generating sentences and sentence templates for narrative reports, Family Historian will now use {inline-note} as replacement for the TMG memo code, [M], as this is the code that most accurately reflects the behaviour of the TMG [M] code. Note: If you have made any modifications to the code replacements file for TMG imports (see the ‘Code Replacements’ button on the TMG Import Options page, displayed prior to import), and if you want to incorporate this same change, you will need to either update the code replacements file yourself and replace {note} with {inline-note}; or alternatively, you can just click the ‘Reset’ button to the right of the ‘Code Replacements’ button, to restore the default version of the file (which includes the new code).

So you will need to change most or all of your {note} template codes to {inline-note}.
This has been a minor irritation for a number of us!

[tatewise]

Where is this "He." coming from? How do I modify the template to make it read like an actual sentence? Also, shouldn't this refer to "Principal 1" rather an "2"?

"He" is coming from the {individual} code because it avoids repeating his name in successive sentences.

The rogue full-stop is explained by the {note} to {inline-note} change.

=Witness(%FACT%,"Principal 2") is referring to the shared Fact Witness with the Role of "Principal 2".
Are you saying that there is no such Role for this type of fact, but that the Role of "Principal 1" does exist?

[cjdenbow]

Mike,

Yes, the particular Fact Note in question refers to just Principal 1. There would be cases where there was a shared fact with a witness, but not in the case being referred to here. It looks like the template imported from TMG references Principal 2 in all cases. However, even though the template refers to Principal 2, the information in the sentence is correct except for the screwed up syntax. This makes no sense to me.

According to what one other TMG refugee posted, it looks like I transferred to FH a little too early as the TMG import routine has now been further refined.

On a related issue, can you tell me if Local Notes are exported in GEDCOM files?

Again, thanks for your help.

Carl

[tatewise]

Carl, help me here, as I don't entirely understand your response.

Is Fact Note an imported custom fact listed with that Name/Label in the Tools > Fact Types... list?

In its Fact Definition dialogue does the Witness Roles: box only list Principal 1 and not Principal 2?
I would expect the =Witness(%FACT%,"Principal 2") component to be derived directly from your TMG template.

By "the screwed up syntax" are you referring to the {note} versus {inline-note} codes?
If so, then that is nothing to do directly with TMG importing. It is a problem all users have suffered due to CP changing the way the {note} code is interpreted compared to previous FH versions. Many of us have had to replace some {note} codes with {inline-note} codes in our Sentence Templates.

It is true that FH is often improved and that includes the TMG import routines.

Everything that appears in any Property Box including local Note fields gets exported in GEDCOM files.
In fact, every time you Save your data, it gets exported to the project's GEDCOM file.

[LornaCraig]

By "the screwed up syntax" are you referring to the {note} versus {inline-note} codes?
If so, then that is nothing to do directly with TMG importing. It is a problem all users have suffered due to CP changing the way the {note} code is interpreted compared to previous FH versions. Many of us have had to replace some {note} codes with {inline-note} codes in our Sentence Templates.

Carl is probably referring to the fact that the TMG import now uses {inline-note}.

My earlier reply in this topic included this quote from CP, in the context of importing from TMG:

When generating sentences and sentence templates for narrative reports, Family Historian will now use {inline-note} as replacement for the TMG memo code, [M], as this is the code that most accurately reflects the behaviour of the TMG [M] code.

So it was partly because of the way TMG works that the rest of us had to replace a lot of {note} codes with {inline-note} codes!

[tatewise]

But Lorna, that was the way that {note} used to work originally and happily coped with inline Note text.
For some reason that has not been fully explained, CP changed the behaviour of {note} so that it was treated as a separate sentence with an initial capital letter and followed by a full-stop.
That change prompted a lot of discussions and eventually led to {inline-note) being introduced some versions later which caused a round of changes including the revised TMG import rules.

If CP had left {note} alone and introduced a new {note-sentence} code then the TMG import rules would not have needed changing and those of us who were happy with {note} as it was would not have changed anything.
Presumably, there were some users who wanted the new sentence style of Note who would have to change some {note} codes to {note-sentence} but I suspect they would be in the minority.

[LornaCraig]

Yes, as we have both said, all users have been affected by this change.

When Carl said " it looks like I transferred to FH a little too early as the TMG import routine has now been further refined " I think he meant that he did his import from TMG before the import started using {inline-note} (in v7.0.18). So if he had done his import with v7.0.18 or later he would not have encountered the problem. Instead, he is in the same position as the rest of us.

[ColeValleyGirl]

Yes, as we have both said, all users have been affected by this change.

Not those of us whose understanding of the English language led us from the beginning to treat {note} as a set of sentences. We may be a minority but i suspect we"re a large minority.

Plus there are the userd who have never meddled with sentence templates

[LornaCraig]

Helen, I too always have always treated {note} as a sentence or set of sentences. (I'm entirely with you on this.) But if you have edited a fact sentence to be simply {note}, and nothing else, you now get a full stop at the beginning of the note! So even a whole sentence note has to be treated a {inline-note} in this case.

Yes, know the aternative is to leave the sentence completely blank because the note will then be inlcuded in reports anyway. That's what I do now, but I didn't have the benefit of hindsight years ago!

[ColeValleyGirl]

But if you have edited a fact sentence to be simply {note}, and nothing else, you now get a full stop at the beginning of the note! So even a whole sentence note has to be treated a {inline-note} in this case.

Has that been reported as a bug?

[LornaCraig]

Has that been reported as a bug?

I can't remember. But I will report it now, because I’ve just checked again and it’s no longer possible to get round it by supressing the sentence and letting the note take care of itself. If the sentence is supressed the note is also now supressed! (I’m sure that was not the case when I first tried, but I hadn’t checked a generated report for a while). So at the moment the only option, if you don’t want anything but the note, is to edit the fact sentence to {inline-note} even when the note itself is a full sentence. And you have to remember NOT to put a full stop at the end of the note because that will result in two full stops at the end of the note in reports!

[tatewise]

Lorna, that sounds like another fault to report.
Fact local Notes are included in non-narrative reports based purely on the Report Options.
It seems odd that Narrative Reports should suppress local Notes just because the Sentence is suppressed.

[LornaCraig]

I will report both bugs. I agree the suppression of the narrative sentence should not automatically suppress the note in narrative reports.

At present the {inline-note} option is better, but only if you remove the existing full stop from the end of the note, to avoid getting two full stops after the note in the report.

When {note} is used the extra full stop shown at the beginning of the note in the sentence field of the Property box is now eliminated in the narrative report, but there is no space left between the full stop at the end of the preceding sentence and the beginning of the note.

Otherwise you just have to copy the entire note text into the setnence field.

[tatewise]

It seems that CP have made a bad job of modifying the {note} behaviour in trying to satisfy a minority of users.
They have got the {note} coding wrong which presumably upsets at least that minority of users.
By introducing {inline-note} to do what {note} used to do CP have upset another minority of users.
Well done CP

[cjdenbow]

Yes, as we have both said, all users have been affected by this change.

When Carl said " it looks like I transferred to FH a little too early as the TMG import routine has now been further refined " I think he meant that he did his import from TMG before the import started using {inline-note} (in v7.0.18). So if he had done his import with v7.0.18 or later he would not have encountered the problem. Instead, he is in the same position as the rest of us.

Lorna, you have interpreted me correctly. I also suspect, but don't know, that other improvements in handing these kinds of issues have been made in the import process as well as other more subtle improvements.

My major concern now is exports, using Mike's nice GEDCOM export plugin, for uploading to my GedSite site. For a few months I fiddled with trying to use TNG but that was a complete exercise in frustration, so I went back to GedSite. When I used TMG I used John Cardinal's SecondSite program. So, I'm kind of familiar with the basic concepts of these programs. They certainly make it easy to maintain a website for your genealogical data.

In the last few days I've had some email exchanges with John about the sentence renderings I was getting with my FH exports on my GedSite site. He was very helpful, and I was making progress, until he abruptly stopped, and told me to figure it out myself. I guess I asked too many dumb questions, or something.

While John was communicating with me he did advise not using "person notes" at all, and as had been said here, substituting {inline-note} for {note}. That latter was quite a help and eliminated a good deal of "syntax weirdness" that I referred to earlier. The reason John recommended not using person notes was the following:

"GedSite converts the person note to an undated NOTE event. The text of the NOTE is stored in [M:Text]. Your FH sentence template for a NOTE event refers to {note} (see below), but the Note event created from a person note does not have a note value. As explained just previously, it has a text value.

{individual} <and {=Witness(%FACT%,"Principal 2")}> {note} {date} {place}"



Since I didn't have that many Person Notes, I converted them all to Fact Notes. This also helped. However, the phenomenon referenced in the graphic above still persists. I'm wondering if some other note type entries are somehow being treated as Person Notes. I guess that's for me to try and figure out.

I also had an issue with a hyperlink in a note that works in FH, but is eliminated in GedSite. That's not a big issue, but John would not even tell me if there's a way to make a note hyperlink work in GedSite, or if it's just not a supported function. Again, I'll have to puzzle that out on my own.

Sorry, if some of this sound a little be like a rant, I don't mean it that way. I know that are some other GedSite users on this board, and perhaps some of them have run into similar issues.

Carl

[AdrianBruce]

Has that been reported as a bug?

I can't remember. But I will report it now, because I’ve just checked again and it’s no longer possible to get round it by supressing the sentence and letting the note take care of itself. If the sentence is supressed the note is also now supressed! (I’m sure that was not the case when I first tried, but I hadn’t checked a generated report for a while). So at the moment the only option, if you don’t want anything but the note, is to edit the fact sentence to {inline-note} even when the note itself is a full sentence. ...

Oh - assuming I'm not missing a subtle (or not) meaning, I don't have a problem with suppressing the narrative sentence and replacing it with the note because the construction I use for the fact-specific sentence is:

Code: Select all

<para>{note}

The Note only appears once in the resulting report. No need for {inline-note}... (NB - my Notes are full sentences, starting with a Capital Letter and finishing with a full stop. E&OE. So blame me as well for CP's choice (grin)...)

Normally I let the {note} be added to the narrative sentence by whatever the option is - I don't code the {note} into the sentence because there are times that I want a narrative without notes - ancestor reports by generation, e.g.

[LornaCraig]

Adrian wrote:

Normally I let the {note} be added to the narrative sentence by whatever the option is - I don't code the {note} into the sentence because there are times that I want a narrative without notes - ancestor reports by generation, e.g.

That’s fine if you sometimes want the narrative sentence without the note. But I sometimes want the note without the narrative sentence. (For example if it's a very 'tentative' fact.)

I don't have a problem with suppressing the narrative sentence and replacing it with the note…

By ‘suppressing’ the narrative sentence I mean using the option to exclude it from reports. That’s not the same as replacing it with the note. Excluding the sentence from reports effectively replaces the template with {blank}, as you will see if you exclude the sentence and then choose to edit it again. The problem is that when the sentence is supressed (i.e. {blank} ) the note is also excluded from reports.

This is why I need to replace the sentence with the note, but both {note} and {inline-note} have problems. I can see that replacing the sentence with <para>{note} produces a successful outcome (I hadn’t tried that, thanks for the suggestion). But what if you don’t want the sentence to start a new paragraph?

[AdrianBruce]

... But what if you don’t want the sentence to start a new paragraph?

I've never tried that, so hadn't seen any problems with it, I'm afraid. (Very often my notes include two or more paragraphs, so I don't want to tag the first sentences on to the end of the previous fact. I only have one or two fact sentences that don't start with <para> - e.g. IIRC Baptism doesn't because it normally follows Birth - except when it doesn't - and I always have a Birth fact. E&OE)

[LornaCraig]

As it happens, baptism is one of the cases where the issue arises for me! If I know (from other sources) that someone was probably born around 1810 in Farnham, Surrey, I will search for possible baptisms and might find two or more around the right time with the right name. I will then have a baptism note saying something like "Two possible baptisms have been found...." giving the dates and the names of the parents in each case, and explaining that it is not possible to know which set of parents he belonged to. I then want the report to say "John Smith was born circa 1810 in Farnham, Surrey, England. Two possible baptisms have been found....." I don't feel the baptism note needs to start a new paragraph.

[AdrianBruce]

Hmm - after reading, Lorna, that I went straight to my 3GGF, John Cooper, whose baptism cannot be found - the only one missing from that family of children. There is a complicated story because there is a candidate baptism but it has two fathers. Haslington in the early 1800s was that far ahead of the times? No, I don't think so...

But I've added this story to the Note against John's birth event, so it's not setting up a problem.

However, my query on over-ride sentences (once I found it) shows me I have 3 sentences where I wanted to run the fact's note together with the previous fact's note. One, for instance, was the second estate valuation for probate purposes. This is what the second sentence looks like (it's just {note} only - the rest has been overridden.)

Screenshot 2023-04-02 220405.jpg (10.22 KiB) Viewed 1055 times

Note the free-standing full stop and space at the front. However, by the time it gets into the narrative report, it looks almost correct:

Screenshot 2023-04-02 220435.jpg (16.8 KiB) Viewed 1055 times

I suspect it's lost a space but otherwise there's no extraneous full stop.... I've not checked the other two.

[LornaCraig]

I suspect it's lost a space but otherwise there's no extraneous full stop....

Yes, the current problem is that it loses a space. This is more obvious with some fonts than others. As I said in an earlier post:

When {note} is used the extra full stop shown at the beginning of the note in the sentence field of the Property box is now eliminated in the narrative report, but there is no space left between the full stop at the end of the preceding sentence and the beginning of the note.

I think (but memory may be wrong) that someone reported the issue of the extraneous full stop appearing and CP tried to correct it but ended up losing the space in the report while still displaying the full stop in the Property box. So the two don't match each other, which is confusing, and both are wrong!

The problem with using {inline-note} is that you get two full stops at the end, unless you remove your own full stop from the end of your note. This is perhaps not surprising, as the {inline-note} code is supposed to be “most suitable for notes which are short, and typically less than a full sentence.”

There are several workarounds: Your decision to add the baptism note to the birth event is one solution. Another is to copy and paste the entire text of the note into the Sentence field, but as the sentence window is small it's not easy to edit the note there if you need to. A third solution is to remove the full stop from the end of the note and use {inline-note}. It's just irritating that any workaround is necessary at all. A sentence template consisting of just {note} used to work perfectly but for some reason it stopped working when CP introduced the new {inline-note}. I can see the reason for introducing {inline-note} but it shouldn't have had any impact on {note}.

Moan over! I'll await CP's response to my ticket

[RS3100]

There's nothing I can add to the above, except to say that as a fairly extensive user of {note} and now {inline-note} to add to or replace fact sentences, and even add multiple paragraphs of information to narrative reports, such as a summary of military careers, I agree with all the above. Just wanted to add my frustration in the event that CP read this thread or refer to it as a result of the bug report.

[LornaCraig]

CP have given their standard response:
"Thank for your feedback. I have logged it for consideration."