Family Historian User Group

I am looking for a way to find out whether a witness is single or plural to conditionally insert different text in a sentence. Anybody knows how to?

If there is more than one Witness for a Fact then %FACT._SHAR[2]% will exist.
i.e. {=TextIf(Exists(%FACT._SHAR[2]%),"Plural","Single")}

But it gets more complex if there is more than one Witness Role.

Thanks Mike, how complex? Indeed I would like it to be role specific. Is it doable?

My first reaction is that it is not possible.
The biggest problem is knowing which _SHAR[index] is the first with the desired ROLE.
So there would have to be a lot of tests for %FACT._SHAR[1].ROLE = "Witness", %FACT._SHAR[2].ROLE = "Witness", et seq.
Then for each case finding the second one with that ROLE is just as tricky.
e.g. something like:
=TextIf(IsTrue(%FACT._SHAR[1].ROLE="Witness" and IsTrue(%FACT._SHAR[2].ROLE="Witness" or %FACT._SHAR[3].ROLE="Witness" or %FACT._SHAR[4].ROLE="Witness" or ... or %FACT._SHAR[9].ROLE="Witness")),"Plural", TextIf(IsTrue(%FACT._SHAR[2].ROLE="Witness" and IsTrue(%FACT._SHAR[3].ROLE="Witness" or %FACT._SHAR[4].ROLE="Witness" or %FACT._SHAR[5].ROLE="Witness" or ... or %FACT._SHAR[9].ROLE="Witness")),"Plural", TextIf(... an so on ...), TextIf(IsTrue(%FACT._SHAR[8].ROLE="Witness" and %FACT._SHAR[9].ROLE="Witness"),"Plural","Single"))))))))

And that only caters for 9 Witnesses.

That is a bit too complex. But, for my understanding:
1. %FACT._SHAR[x] only exists if [1] to [x] witnesses of whatever role exist?
2. %FACT._SHAR[x].ROLE (if existing) will return the name of role x?
3. Is there some kind of ordering of the witnesses (by use, by definition or...)?
4. If "by definition" and "within that by use" and suppose I arrange the order in such a way that the first role is the one I am interested in; would such a setup work (in a less complex way??

Your understanding is perfect, and yes you can order them.
Use the Facts tab, Witnesses... dialogue Move Up/Down buttons.
If the Role of interest Witnesses are always top of list, then %FACT._SHAR[2].ROLE%="Role" is true for Plural case.

Thanks Mike, I think I can always make it the first one. So worth a try!

Have you looked at the Help page on Template Codes? It addresses this topic. To find the page, open the Help and then type "Template Codes" in the Index. You can also get there by clicking the Help button when editing fact definitions or roles. If you scroll down to the 'Role Codes' section, there is a section on how to put together singular or plural sentences, with respect to roles. If you want to see an example of how this works in practice, look at the fact definition for the Marriage fact type. For example, the sentence for marriage principals includes these sections which give you an idea of how it works:

<{role(single)=bridesmaid} was a bridesmaid. ><{role(plural)=bridesmaid} were bridesmaids. >

Hi Simon,

Yes I know how that works. But, suppose I want something like {bridesmaid}<, {note},> and then "was" or "were" depending on whether there is one or more? The need for this arises when {note} (or a paragraph of it) is used as extra information related to (in this case) the bridesmaid(s) e.g. the family relation to the couple.

I think the most easy and elegant solution would be to be able to use {rol(single)=bridesmaid} in a conditional test (and off course to be expanded to general usage of template codes in functions; I see no reason why it should be prohibited). Maybe something for 6.1.3?

I agree that it would be a major benefit to allow Template codes within Functions.
Currently, as soon as a Function is needed, then everything that was a Template code has to be created using Functions.
In particular {date} is a nightmare to recreate using Functions.

Yes!
And hoping that Simon is still reading this thread:
1. give {note} an optional index e.g. {note(2)} to fetch te second paragraph - would improve readability of sentence templates a lot;
2. make a witness note accessible through a template code e.g. {wnote} - it's even a bit odd to currently have a note for a witness without a template code to access it;
3. witness notes don't support paragraphs (as yet ) - would be really nice to be able to handle them like principal notes. So maybe also {wnote(2)} etc.?

You say "3. witness notes don't support paragraphs" but I have no problem using the Witnesses... dialogue and Edit Witness Details dialogue to add multiple paragraphs to the Note box.
BTW: A paragraph is any text terminated with a newline character.
They can be referenced using =GetParagraph(%FACT.NOTE2%,2), etc.

What you cannot do is create multiple Note tags NOTE[1], NOTE[2], et seq, as you can for Facts.

I used {%CUR~WITN.NOTE2%} to access the witness note (for "that" witness) and tried =GetParagraph(%CUR~WITN.NOTE2%,2) to get to the second paragraph of this note. What am I missing?

Sorry, in what way does that not work?
Assuming {%CUR~WITN.NOTE2%} displays all the Note paragraphs for that Witness.
Then {=GetParagraph(%CUR~WITN.NOTE2%,2)} displays the 2nd paragraph.

Sorry Mike, I didn't make myself clear. I meant that fetching the second paragraph when the first one is only a CR/LF doesn't work. The CR/LF is ignored (as it is not in the fact note, I am happy to say). I don't know whether it is by design or has been overlooked, but it seems that the fact note is handled a bit different from the witness one.

My usage for the GetParagraph for principals and witnesses is to improve on the sentences and this works pretty well but a few extra's would make the feature complete (see my suggestions in this discussion).

I will check out that anomaly tomorrow.

I have looked at the Witness Note field, and found the problem, but your analysis is not quite correct.

The =GetParagraph(...) function works absolutely perfectly.

The problem is that the Witness Note field does not retain leading or trailing layout characters such as newline, tab & space. So when the 1st paragraph is blank it is removed from the Note completely, and all the paragraphs shift up one. Similarly any trailing blank paragraphs are removed. This behaviour is contrary to all other long text fields such as Record/Fact Note, Address, and Text From Source, and was an improvement implemented years ago in FH.

It seems the Witness Note has regressed to the earlier mode of long text fields.

Please report the misbehaviour to Calico Pie Support.

Thanks Mike, I'll report it.

What's your view on my proposed enhancements:
a. template code for the witness note field e.g. {wnote};
b. template code enrichment for the note field to get rid of a lot of GetParagraphs by allowing something like {note(x)} to fetch the xth paragraph;
c. combine a and b, e.g. {wnote(x)}?

Possible wish list requests?

Yes, that is a good enhancement, and I would take it a bit further and apply the concepts to {address} and {place} too.

{note(x)} or {address(x)} or {wnote(x)} would return the xth paragraph equivalent to =GetParagraph(...,x).

{note("label")} or {address("label")} or {wnote("label")} would return the labelled paragraph equivalent to =GetLabelledText(...,"label").

{place(x,y)} or {address(x,y)} would return text parts x to y equivalent to =TextPart(...,x,y).

A variant of the above would be to allow Template Codes within Functions so that =GetParagraph({address},x) would return the xth paragraph and =TextPart({address},x) would return text part x. This technique offers a more generalised benefit in many more scenarios as it applies to all Functions.

BTW: =GetLabelledText(%CUR~WITN.NOTE2%,"label") offers a workaround for you by labelling your paragraphs.

I like the generalizations; they fit within the current concept and improve readability. Can you move this part of the discussion to the wish list or should I open a new item there?

BTW: your BTW is nice; it might even give me a way to kind of document what "subfield" of a note is what. It returns everything from right after the label text to the end of paragraph?

I will create the Wish List Request.

Your BTW observation is correct, and is why I prefer it to =GetParagraph(...) as you only need to include paragraphs for the details required, and they can be in any order.

Thanks Mike and I agree that GetLabelledText (although longer, but not anymore if our wish gets honored ) is preferable. Together with the Auto-Create Note feature it would be ideal for documenting the sub-fields of a note.
On the other hand... wouldn't that insert a lot of unnecessary and duplicate text into the database? In essence a label is meta information and should not be part of an information field. Maybe a more system based solution is the better option?

It is a trade off.
For example, Gedcom Note and Text From Source are generic text fields easily portable between products.
If you add meta data labels, they are still understood by recipient humans.
If system fields are created instead, then they are not portable Gedcom fields, c.f. Individual Flags, and Media Date and Keywords in FH, and similar custom fields in other products.
Product support of an extensible Gedcom field structure would be even less likely than the current (poor) support of the rigid GEDCOM 5.5 standard.

New functions in FH7.

I think that in FH7 the Witness function allows us to test for plural witnesses of a specific role. Which, if I'm right is a great addition.

Something like {=TextIf(Exists(Witness(%FACT%,"heir",2)),"are","is")} could now be used?

Yes, except that you also need to test for Exists(Witness(%FACT%,"heir",1)) otherwise it says is even if there are no heirs!