* ver 7.0.17.1 - spurious full stops

[dewilkinson]

Before I report this to Calicoe Pie I was just wondering if other people are seeing something similar. I am now getting full stops inserted after the age field in sentence templates. See attached example which shows no full stop in the template.

I am thinking there is an error in the enhancement regarding full stops at the end of sentences.

Template.jpg (78.4 KiB) Viewed 1062 times

Report.jpg (323.46 KiB) Viewed 1062 times

Entry.jpg (60.47 KiB) Viewed 1062 times

[tatewise]

Check the https://www.family-historian.co.uk/v7-updates for Reports and Books regarding the old {note} and new {inline-note} codes. In your case, the Note text is a short phrase that needs the {inline-note} code.

[dewilkinson]

Many thanks I hadn't twigged that and it works. Whilst it doesn't take long to update the sentence templates I guess the only way people can update the actual senteces is using Find and Replace {note} with {inline-note}

[tatewise]

Yes, but it gets more complex if the same Fact Type sometimes has Note text that is a short phrase needing {inline-note} and others have long multi-line text needing {note}. i.e. The code required depends on the format of the Note text.

I am sure that FH V6 handled both long and short Note text with just the {note} code.
So I don't fully understand why FH V7 has complicated things.

[dewilkinson]

I agree, I think it is an unneccesary complication. I wonder if Calico Pie consulted any users over this? (rhetorical question)

[ColeValleyGirl]

Well, we did have a topic a while back about unnecessary full stops when a {note} was placed inline and (I suggested) FH was clearly expecting a {note} to be a full sentence, rather than a sentence fragment. And now we have

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.

so perhaps they have reacted to that topic (which I can't now find).

An {inline-note} doesn't seem to have any length restriction in my experimentation...

[Mark1834]

I must admit, I never use FH to compose prose text, but my instinct is that changes such as this should be backwards-compatible and not force users to change their data to continue doing what they did before.

There would have been at least two intermediate versions that never made the light of day (7.0.16 and 7.0.17) but would have been sent to invited users for testing, but it looks like nobody picked this up.

[ColeValleyGirl]

I must admit, I never use FH to compose prose text, but my instinct is that changes such as this should be backwards-compatible and not force users to change their data to continue doing what they did before.

There would have been at least two intermediate versions that never made the light of day (7.0.16 and 7.0.17) but would have been sent to invited users for testing, but it looks like nobody picked this up.

I would agree, but it's hard to see how that would work in this instance when the status quo was problematical. Some people will have been using {note} for one or more complete sentences; some people will have been using {note} for sentence fragments (and complaining about extra full stops). Which set of users do you force to change?

[tatewise]

I haven't done any exhaustive tests, but I think {inline-note} now does what {note} used to do in all earlier FH versions.
FH V7 introduced an undocumented full-stop strategy to {note} code entries that were not backwards compatible.
It is that change that has resulted in the current complications.
IMO the best option is to simply revert to what {note} always used to do, i.e. as {inline-note} now does.
If some users have to insert an explicit full-stop then that makes more sense than having some undocumented automatic insertion of full-stops.

The related improvement where %FACT.NOTE2% inhibits enabled Note options in Report should be retained.
It is not clear whether %FACT.NOTE2% is equivalent to {note} or {inline-note}.

[Mark1834]

Neither - I'd make it so both legacy approaches still worked, but the logic deleted any multiple full stops at the ends of sentences. But I fully recognise that's me speaking off the cuff without knowing in detail (or being particularly interested in) how such templates are set up, so it may not be a viable option.

[ColeValleyGirl]

If some users have to insert an explicit full-stop then that makes more sense than having some undocumented automatic insertion of full-stops.

Only if the need for that extra full stop doesn't depend on the content of the note.

Disclaimer, like Mark, I don't have a dog in this hunt -- I don't use sentence templates -- if I want decent narrative, I'll write it myself.

[tatewise]

How does anyone except CP know what the full-stop rules are? They are NOT DOCUMENTED anywhere!

[ColeValleyGirl]

No need to shout, Mike. You've said it several times, and nobody has disagreed with you.

[ColeValleyGirl]

How does anyone except CP know what the full-stop rules are?

Especially when they'll vary from language to language...?

[tatewise]

I felt it needed emphasising as several strategic solutions for applying full-stops were being proposed when nobody knows the rules of the game, so it appeared that the lack of documentation point was being ignored.

[ColeValleyGirl]

I felt it needed emphasising as several strategic solutions for applying full-stops were being proposed when nobody knows the rules of the game, so it appeared that the lack of documentation point was being ignored.

I must have missed the proposed solutions -- I'm only seeing questions/discussion, not answers in this thread.

[AdrianBruce]

I would agree with Helen's identification of the reason for the creation of {inline-note} - someone was using {note} in the middle of a sentence and it wasn't coming out properly.

In my personal view, the solution that CP have adopted seems the cleanest - actually make the distinction between notes that form fragments of sentences (the inline notes), and notes that form sentences of their own. Bear in mind that there must be a ton of punctuation related logic trying to put notes into narratives. My use of {note} in narrative sentences is a third option, by the way - I don't put the thing in the narrative template at all but press the button to add the note and the end of the narrative.

I think back to the problems that I ran into with extra spacing because I was using spaces inside < and > to control the spacing of a narrative sentence. But I was told that I was working against the software logic and I'd do better not trying to second guess the logic. And so it proved. This indicates to me that there is a ton of formatting logic that (in my case, certainly) was tottering - better by far to provide a clean base. Or so say I.

[ColeValleyGirl]

A brief experiment with {note} and {inline-note}, and various punctuation/spacing reveals the following behaviour around sentences:

• In all cases, FH capitalises the first word of a sentence if it is not already capitalised and adds a trailing full stop if one isn't already present (unchanged from FH6).
• In all cases, FH leaves the contents (including punctuation and spacing) of {note} or {inline-note} untouched -- it makes no changes whatsoever (unchanged from FH6).
• In all cases, FH removes duplicate spaces in a sentence outside {note}/{inline-note} (unchanged from FH6).
• If using {note}, FH ensures it is preceded by a full stop and a single space by adding them if necessary, i.e., treats it as if {note} starts a new sentence (new in FH7).
• If using {inline-note}, FH does not make any changes to the text immediately preceding it -- it does not add a full stop/single space, i.e. it doesn't treat {inline-note} as the start of a new sentence (same behaviour as {note} in FH6)

So, the only difference I can find between {note} and {inline-note} is as mentioned in the Version 7 Updates page:

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.

This is consistent with the help file that says:

Note (long)

Code: {note}

Inserts the note, if any, associated with the relevant fact. Is most suitable for long notes, such as notes which contain one or more whole sentences. The {note} code is normally the last code in the sentence template. If you want the note to appear within its own separate paragraph, you can use <para> formatting codes before and after it, within angle brackets - like this: <<para>{note}<para>>(see How to Add a Prefix or Suffix to any Sentence Template Code below).

Note (inline)

Code: {inline-note}

Inserts the note, if any, associated with the relevant fact. Is most suitable for notes which are short, and typically less than a full sentence. The {inline-note} code is typically used for notes which are intended to be inserted as a clause within a sentence.