Modified August 19, 2020 12:19 pm
This site works better with Javascript enabled.
Michael J. Hannah, Los Ranchos, NM.
Customizing TMG™
Tag Sentence Details My Way ©MJH
Conditional, Living, Two Principals, Sensitivity, Exclusion, Trailing punctuation and concatenation
• Variables: Linked People, Parents, Age, Date, Location
• Memo, Empty Split Memo Parts, Memo Variables Table
• Embedded Format Codes, Embedded Format Codes Table
• Default Roles, Role Names, Role Variables
• Endnotes
These variables are only used in sentences, and sentences are only produced for narrative reports: direct line Ahnentafel, non-columnar Ahnentafel, Descendant Indented, Individual Narrative, and Journal. Variables that may be used in sentences can be grouped by the type of information they represent: People, Parents, Age, Date, Location, Memos, and Embedded Format Codes. Not all variables may be used in the sentences of all tag types. The variables available in tag types in the “Name” group are limited to [N] for the name entered, [P] and its variations, and [OBJ],1 date variables, and the memo variables. The variables [P1] and [P2] are fixed when the links to the individuals are assigned at tag creation and do not change whichever person is the focus. In a sentence assigned to a Principal, [P] (the focus Principal) and [PO] refer to [P1] or [P2] but change relative to whichever person is the focus. In a sentence assigned to a witness, [P] is the same as [P1] and [PO] the same as [P2]. Tag groups “Birth” and “Death” only have [P1],2 all other event tags have both. [W] is the same as [P] in a sentence assigned to a Principal, but is the focus witness in a sentence assigned to a witness. The new Subject variable [S] and its variations introduced in Version 9 always refers to the Subject who is the current focus of the sentence, whether a Principal or a witness, thus allowing the same sentence template to be assigned to either. Defining a Role for a tag allows separately defined sentences for each role in addition to those for the predefined roles of Principal and Witness.
You can construct separate sentences for male and female and they will be used based on the SEX flag of the focus person, whether Principal or Witness. You may also restrict the use of the tag and its associated role to only one sex or the other. If you try to enter a male in a role only appropriate for a female, you will receive a warning.3 For the Principal the warning occurs when you attempt to close the “Tag Entry” window. For the Witness the warning occurs when you attempt to close the “Add witness” window. In either case you can choose to proceed and not have the SEX flag appropriate for that role, but will be warned every subsequent time you attempt to close the corresponding window. By default no Standard tag types have separate male/female sentences, and none come with roles set to warn based on the SEX flag. I choose to customize many tag types and roles with these features.
Special Sentence Template Characters
The following are the effects of these constructs of special characters when they occur within a Sentence Template.
|
Conditional output only if the variable has a value. The conditional brackets are not recognized in a Memo and will be output as those characters.4 The enclosed variable in the Memo will be considered unconditional. Conditional brackets in the sentence template are intended to enclose only one variable. |
|
|
Alternate living vrs non-living output based on the value of the LIVING flag of the focus person |
|
|
Conditional two Principals alternate output based on whether there is only one or both Principals defined. [WARNING: if used and unescaped in memos this separator character is honored by TMG within the text of conditional memo parts.] |
|
|
Sensitive output conditioned on the option to output sensitive data5 |
|
|
Excluded output; if it begins the output, the output is either conditionally or unconditionally excluded |
|
|
[:NP:] anywhere (usually at the end) in the sentence template |
Causes the trailing punctuation and spaces for that tag to be suppressed. |
|
Causes a sentence to be concatenated (joined) with the previous sentence in a narrative in order to form a single compound sentence. |
Text may be made conditional based on whether a sentence variable “has a value” if that variable is enclosed in conditional brackets ( ‘<’ and ‘>’). A variable will not “have a value” if either the contents of the variable is empty, or the text of the variable is excluded and excluded data is not being shown. A pair of conditional brackets is intended6 to enclose one, and only one, sentence variable, but any or all variables in a sentence may be made conditional. You may also put actual text with the variable within a set of conditional brackets , e.g. “<along with [R:resident]>”. The value of the variable plus any other text that is inside the conditional brackets will be output if the variable has a value, otherwise none of the conditional text is output. The presence of leading text within the conditional variable can prevent the inclusion of an automatic preposition in front of the variable (e.g. Date and Location) output. Two conditional brackets in a row that output their text will automatically create a space between their output. TMG will avoid creating the space if the second conditional text begins with a comma, thus chaining the output. Unfortunately the space is still created if the second conditional text begins with a period. (It is not clear if this is by design or a bug, but can prevent certain desirable sentence structures. Second Site will prevent the space if the second conditional text begins with a period.)
[I need to test all the variations of the variables and options and describe when a preposition is automatically inserted for the date and place variables, and common custom workarounds for prepositions. Much of this preposition explanation should probably only be part of the date and location discussions, as the way prepositions are handled are probably different for each?]
Based on the value of the LIVING flag set for a person, the entire sentence template for that person may be split into two parts by two adjacent vertical bars ‘||’ outside any conditional variable brackets , i.e. “not-living text with variables||otherwise text with variables”. You can only use one set of these double bars in a sentence template. Everything before the separators will be used if the LIVING flag is set to ‘N’ for the person that is the focus of this sentence, otherwise (if LIVING is set to either ‘Y’ or ‘?’) the sentence structure after the separators will be used. Double-bars in the sentence template when [P2] is the focus will be controlled by the LIVING flag of [P2] not of [P1] of that tag. The person who is [W] is the focus of their Witness sentence, so double-bars in a Witness sentence template will be controlled by the LIVING flag of that Witness not by the flag of either Principal of that tag. Do not confuse this with the double bars defining split parts of a Principal or Witness memo. I do not currently use this control in my sentence templates.
A single vertical bar ‘|’ inside conditional variable brackets defines which part of the conditional text is output if there is one or both Principals known. This <one text|two text> construct outputs only the first part when there is one Principal and only the second when there are two, as in “[P] <was|and [PO] were>” or “<[M1]|><|[M2]>”. This control can be used multiple times in the same sentence template but only once within a given conditional text structure. For example, to produce the typically desired “John and Mary Smith” if both Principals are defined (and the P2 female of the couple has a married name selected) I use the two conditional text constructs both containing this “two principals” control character “<[P]|[P1F]><|and [P2]>” in a sentence. If there is only one Principal defined (either [P1] or [P2]) these two constructs will output only “[P]”, but if both Principals are defined the output from the two constructs will be “[P1F] and [P2]” which produces what I desire.
This Two Principals separator is honored in sentence templates even if the tag can have only one Principal, such as a Death or Birth tag. For such one Principal tags the text following this separator can never output.
WARNING: This separator (in my opinion) should only be recognized within conditional variable text contained in a sentence template itself. However TMG will recognize any set of conditional variable brackets containing a memo or memo part variable in a sentence template where that memo text contains a single vertical bar as having a “two principals” separator. Conceptually TMG replaces the memo or split memo part variable with its text and only then examines the resulting expanded text within the conditional brackets for this separator character. Depending upon the number of known Principals the resulting output will either be only the resulting expanded text before the vertical bar, or only the expanded text after the vertical bar. Thus either the text before or the text after the separator bar will not output in TMG narrative reports.
While some users may find this a useful feature, I believe it to be a bug and have included it in my My List of Outstanding Bugs document. Further Second Site only recognizes this special meaning of this character in sentence templates, not in memos. If this character is intended as text in memos and this sentence will output in TMG narrative reports, as recommended for all TMG special use characters always use a backslash to escape this character (e.g. “\|”) when entering it as data.
If you enclose all of a sentence variable entry (the text that is the value of the variable) in sensitivity braces (‘{’ and ‘}’) and choose the TMG report option to not output sensitive data, the sentence output will operate as if the value of that variable had been left blank. Thus if the variable is not optional it will produce the appropriate “unknown” output, and if optional the associated optional text is not output. If one wishes to enter a name as sensitive in a Source “People” Element, to allow the automatic name part processing for the different templates it should be entered as: {Surname}{, First Middle}. Some bugs remain which affect the TMG output of sensitive text and sensitivity markers.7 Most TMG reports have an option to show such data, optionally with their surrounding marker braces. TMG does not show such data in the preview of a tag’s memo in the Details window, or in a tag’s sentence preview. Note that Second Site never outputs any data marked sensitive, there is no option to do so. Therefore using custom tag types instead of sensitivity markers, such as my AnecdoteSens tag type, allows control over whether their data will output in either TMG or Second Site. As I use Second Site as my primary output, even for my own private use, such custom tag types provides an option to include such data in a private site. Thus I seldom use sensitivity markers.
Exclusion single ‘-’ or double ‘--’ markers
If a sentence template begins with a single exclusion marker, the tag and its sentence may be excluded. Whether the tag or its sentence will output will depend upon the option to output excluded data, the template, and the data fields referenced. If a sentence template begins with a single exclusion marker and the option to show excluded data is not checked, the tag itself is excluded and the tag will produce no output. I will often make a tag’s template local with a leading single exclusion marker (or a custom role) to cause the output of the tag to be controlled by this option. See also my AnecdoteSens tag type. If a sentence template begins with double exclusion markers, the tag itself is always excluded and the tag will produce no output. (See also special issues concerning excluded sentences on Name tags, double exclusion of Male sentences, and Source exclusion.)
If the sentence template does not begin with any exclusion marker, neither the tag nor the sentence is excluded but some or all of the sentence data may still be excluded. For example if the template contains nothing but the unconditional memo variable ([M] for a Principal sentence or [WM] for a Witness sentence) but that memo text itself begins with an exclusion marker, and the option to show excluded data is not checked, the sentence will output “(an unknown value)” due to the excluded memo. If the template contains nothing but the conditional memo variable (<[M]> or <[WM]>) for that excluded memo, and the option to show excluded data is not checked, no sentence text will output since that memo text is excluded so the variable is considered empty. But the sentence is not excluded so a sentence will output in TMG narrative reports with a free-standing concluding period and any citation references. Similar but different issues also exist with Second Site for sentences of tags which are not excluded but which output no text.8
Portions of a sentence may be excluded depending upon the data in fields referenced by individual sentence variables, including variables referencing individual split subfields (e.g. of memos, citation details, etc.), if that data begins with an exclusion character. This can also affect any conditional memo variable clause which contains hardcoded text (e.g. <this is conditional hardcoded text [M]>). If the referenced field begins with an exclusion marker followed by some text, the output of the entire conditional clause is controlled by the option to show excluded data.
A referenced field or subfield with only a single exclusion marker and no following text is treated inconsistently in TMG. Usually this should be considered a user error, as there is no text to be excluded. As what may be considered an undocumented “feature”, a tag Memo field or subfield containing only a single exclusion marker can be used to control output of hardcoded conditional text in the sentence template (e.g. <this is conditional hardcoded text [M3]> where [M3] contains only a single exclusion marker). If the TMG report option is set to not show excluded data, the entire conditional clause will not output as is appropriate. However, if the report option is set to show excluded data, the hardcoded text within the conditional clause will output but the variable will output no data, not even the dash. I have not found this undocumented behaviour to occur for any fields or subfields other than for the tag Memo. For example, it does not occur with the citation detail field or subfields and may produce undesired output such as the marker text itself.
A referenced field or subfield might have been entered with leading space(s) but then be followed by an exclusion marker and more text. Usually this should be considered a user error, as an exclusion marker should begin a field to be recognized as such. TMG will strip the leading space(s) from the beginning of an entire memo field upon data entry. Subsequent review in TMG of the field will show this change. However TMG will not affect leading space(s) at the beginning of an internal split subfield. (Second Site will strip both leading and trailing spaces of an entire field as well as each subfield.) Thus if this text of leading-space(s) followed by an exclusion marker was entered in the first (or only) subfield, the text will be changed to begin with that exclusion marker and will be handled appropriately. But split subfield parts after the first part with leading-space(s) and then marker are not changed and behave inconsistently. For a citation subfield (e.g <[CD3]> or <[CM3]>) after the first, TMG will treat the leading space(s) and then exclusion marker as text and always output them. However for a Memo subfield (e.g <[M3]> or <[WM3]>) after the first, in several cases TMG will treat such a memo subfield as excluded as if any leading spaces were stripped.
Note that if a tag’s sentence template, even a Witness sentence template, has a single excluded sentence template such as -<[M0]>[:NP:] intended to produce no sentence text or concluding period regardless of the option setting, any citation reference(s) for the tag may still output. If the option is set to output excluded data, while the tag will not output any sentence text due to its template, the tag itself will still “output” due to that option. Thus its citation(s), exhibits(s), etc., will output and appear as if to the previous tag. Only a double excluded sentence template will exclude the tag and thus prevent any other tag output when excluded data is chosen to output. A custom tag type could be created with such a single excluded template to cause citation(s), exhibits(s), etc. to conditionally follow a tag. Such a tag type could be selected or not, and thus enable including additional tag output (citations, exhibits, etc.) as if part of the preceding tag when the option for output of excluded data was chosen.
Trailing Punctuation ‘[:NP:]’ and concatenation ‘[+]’
Most punctuation is permitted in sentence templates. Punctuation placed with the text inside the optional delimiters of a variable in the sentence template only outputs if there is text to be output for that variable inside the delimiters.9 If the text has a trailing period at the end of the sentence, a second period is not inserted. (In earlier versions there was an issue with the [L] variable and following periods but that has been fixed.10) If you finish a sentence with a period that precedes a close-quote e.g. ‘text.”’, TMG will not add a period. If you finish a sentence with a close quote not preceded by a period e.g. ‘text”’, TMG will add a period in front of the close quote.11 (This follows the North American style of a sentence ending with quotes.) If you wish a period to follow the close quote (the UK style) escape that period e.g. ‘text”\.’, and TMG will not add another period.12
Two special sentence variables can be used to affect trailing punctuation. [:NP:] (see notes about bugs with this variable13) can suppress the trailing punctuation for a sentence, and [+] can concatenate a sentence with the previous sentence in a narrative report. While the [:NP:] code will work when placed anywhere in that tag’s sentence template, it is recommended practice to place it at the end of the template as a visual reminder that automatic trailing punctuation will not occur. (Unfortunately the [:NP:] code does not work to override the automatic end-of-sentence processing which always occurs in TMG reports for Source Citations.) However the [+] code must be first in the tag sentence template or it will be ignored. Neither will cause the desired effect if simply placed in the memo. The [+] code also will automatically suppress trailing punctuation from the preceding tag14 so an [:NP:] code is not needed in that preceding tag. As there is never a “preceding” sentence, the [+] code makes no sense in a citation. Automated capitalization is suppressed for the concatenated [+] code tag’s sentence. Text output starts immediately after the [+] code, so the code may be followed immediately by separating punctuation (e.g. comma or semicolon) and then a space and then the rest of the concatenating sentence. If you do not include such separating punctuation, place a space after the [+] code to avoid direct concatenation of the leading text of this concatenating tag with the ending text of the preceding tag.
Most people variables (the variations of [P], [W], [R], and [S]) output some form of the name of a person in the dataset. (Note that the forms of the [S] variable are not recognized in Name tag type sentence templates, as these tags can only have one Subject.) If the person referenced by the variable is unknown (e.g. no person is assigned that role) and not conditional, the English version will give the text “an unknown person” for the name. If the variable is designed to output a pronoun and either the one person referenced is unknown or their SEX flag is set to ‘?’, both gender pronouns will be output (nominative: “he/she”, possessive: “his/her”, objective: “him/her”). See also the special character mentioned above controlling conditional text when there is only one or both Principals defined. If a pronoun is not output, the name will be based on the selected name for that tag, which by default is the Primary name.
A plus after the four basic name variables ([P+], [W+], [R+:rolename], [S+]) which are for the Subject or focus person of the report will cause that form of the name to be output in full rather than allowing a pronoun to be substituted. Pronoun substitution occurs only for the Subject or focus person of the report, not for any other person, no matter how many times their name may appear. Only the main focus person variables, e.g. [P] or [W] or [R:rolename] or [W] (or [S] as of Version 9), will be changed to a pronoun, and only under three conditions:15
1) This is the second or subsequent sentence in the same TMG text grouping (usually a paragraph16 as the TMG report defines it, ignoring any [:CR:] you may have included) for that focus person, AND
2) this is the first variable in the sentence, AND
3) the variable does not have the ‘+’ modifier.
NOTE: Variables in the table below marked with a 9 superscript (e.g. [S]9) were introduced in Version 9. Further, Role variables are marked with a 9.2 superscript (e.g. [R:rolename]9.2) since the output of all variations of Role variables was changed in Version 9.02 to always output based on all persons, Principal or Witness, assigned that role in this tag. Previously [R:rolename] would output only the focus person’s name data if the focus person (Principal or Witness) was assigned that role. Name part variables such as [RF:rolename] would output only the focus person’s partial name data if a Principal was the focus person assigned that role. The new [S] Subject variables should now be used to limit output to only the focus person, whether a Principal or Witness.
|
Current Principal’s selected full name (if this is the first variable in the TMG sentence, an appropriate pronoun is used for all sentences after the first within that same person’s text narrative grouping unless this substitution is suppressed by the ‘+’). If used in a Witness sentence, output is the same as [P1]. |
|
|
This and all other variants of role-based codes can be used for the predefined/prenamed role “Principal” but there are no predefined names for the roles of “Principal1” or “Principal2”. You can use the available variables for a specific Principal such as P2G, etc., but there are no variables for the pronoun, possessive pronoun, or objective pronoun of just P1 or just P2, only of the “current” principal. See also the S Subject variables below. |
|
|
Only available in tag types in the Name tag group and refers to the name in this tag. If this variable is used, there will be no automatic inference of values from the Primary name in empty fields of this Name tag in narrative report output. |
|
|
Current Principal, Possessive of full given name. [Fred Samuel’s] |
|
|
Current Principal, Possessive first word of given name. [Fred’s] |
|
|
Current Principal, Possessive of full selected name. [Rev. Fred Samuel Smith’s] |
|
|
Other Principal’s selected full name. A leading ‘-’ in the ID number prevents this name displaying in the Person View on the tag when the “other” is the focus, but does not affect report output. If used in a Witness sentence, output is the same as [P2]. |
|
|
First Principal’s selected full name. A leading ‘-’ in the ID number prevents this name displaying on the tag when the “other” is the focus, but does not affect report output. |
|
|
Second Principal’s selected full Name. A leading ‘-’ in the ID number prevents this name displaying in the Person View on the tag when the “other” is the focus, but does not affect report output. |
|
|
Full name of person(s) (either Principal or Witness) with this “role” in this event.17 |
|
|
Current Witness’ selected full name [Warning: [W] is changed to [P] when used in a Principal sentence.] Roles and the [S] variables can help avoid confusion. |
|
|
This and all other variants of role-based codes can be used for the role “Witness” as that is a predefined/prenamed role, but like all other roles if there are multiple people assigned the role “Witness”, then all the names will be output. |
|
|
Other Witness(es)’ selected full name(s) — separated by commas. Excludes any principals and this person if the focus is a witness. Roles can help avoid confusion, but there is no predefined/prenamed role “WitnessOther” like there is for “Principal”. |
|
|
Current Subject or focus person’s selected full name (either Principal or Witness). |
|
For all versions of the PAR variable to refer to both parents, the expansion not only provides the name(s) of the parent(s) but begins with “son of”, “daughter of”, or “child of” depending upon the SEX flag of the child, and includes both a leading and trailing comma surrounding the phrase.18 If the variable is unknown and not conditional the English version will give the text “whose parents are unknown”. The versions of MOTH or FATH produce only the name. While you can customize sentences using MOTH and FATH to avoid the automated relationship and commas, the PAR variables automate the handling of all the cases of only one or both parents defined. Notice that all versions of the parent variables output only the primary full names. To obtain other versions of the names Witness roles must be used, which would also have the problem of cases of only one or both parents defined.
Age19
Whether TMG and Second Site can calculate an age is dependent upon what is entered as the date (not sort date) in both the primary tag in the Birth group and the tag with the age variable in the sentence. There has been much discussion on this calculation, and TMG even changed the behavior of [A] for version 6.02 only, but reverted in 6.03 to the following behavior. The discussion which follows about the [A] and [AE] variables applies to all the variations of those variables. Unfortunately Second Site has different rules as to whether it will output an age based on the structure of the dates entered.
If the date is irregular, for both the [A] and [AE] variables if the variable is bound by conditional brackets “<[A]>” then the sentence variable is ignored and no age is output. An unconditional use of the variable will return “at an unknown age” for such dates. The [A] variable produces output in years or estimated age (years) of current principal, output: “at age yy”, only when both the primary tag in the Birth group and the tag that contains the [A] variable contain the full (day, month, year) dates, and the age is over one year. Note that the number of years is not followed by the word “years”. If either date has an appended question mark, then the age will have an appended question mark.20 It returns no value when the age can not be precisely calculated (e.g. incomplete dates that have only the year). If the [A] is bound by conditional brackets “<[A]>” then the sentence variable is ignored for incomplete dates or an age less than one year and no age is output. An unconditional use of the variable will return “at an unknown age” for such dates. The [AE] variable will produce an exact age, output: “at age yy years, mm months and dd days”, or estimated age, output: “at age yy years”, of the subject if both dates are complete. Note that each number is followed by its definition: years, months, days. It will still produce output even if only approximate dates are known, but it will be only years. The TMG documentation calls [AE] an exact age variable, I choose to call it an Exact or Estimated age variable. There is no variable to always output just years21 regardless of the completeness of the dates. When one or both of the dates involved are estimates using “about”, “circa”, etc., Second Site will not produce a value for the [AE] age variable, and if the variable is conditional then the entire conditional phrase will not output. If either date is incomplete (e.g. a year only) the computation of the age in years may differ by a year. For these reasons tag sentence templates which use [AE]where either date could be an estimate or incomplete may either need to define alternate roles, or use a local sentence, with separate sections using Second Site-only format codes since the output in TMG may differ from Second Site. In my custom sentences the only tag types which use the [AE] age variable are Death, DeathAssume, DeathAssumeBur, and DeathAssumeCrem in the Death group, and I do my best to make both the TMG and Second Site reports output the same text.
These variables refer to the main date of this tag. There is (intentionally) no way to refer to or output the Sort Date. A preposition is only prepended if the date is conditional and there are no characters in front of the variable within the conditional brackets. An irregular date will always output as input for the [D] and [DD] variables; but a conditional [Y] variable will not output and will return “an unknown year” if unconditional. An unconditional use of the variable will return “an unknown date” for blank dates. How the date will output will depend upon report options.
Although location fields can have customized labels to assist in the data entry for tags, these customized labels may not be used as variable names in sentences. If the sentence structure (also) includes any explicit component(s) (e.g. [L1], [L2], [DETAIL], [STATE], …) of the location variable then the generic variable [L] will not output that component, regardless of the definition of [L] for that report. This may be useful to define a different preposition for a given location component, e.g. set the report option for locations to use “in” but have a sentence with “<at [L2] ><[L]>”. The preposition defined in the report options will be prepended to any separately specified location variable if that variable is conditional and there are no characters in front of the variable within the conditional brackets. The preposition is never prepended to unconditional variables. If the [L] location variable will output more than one component, all components including the last will be followed by a comma.22 If the report options are set to output Short Place, [L] will output as Short Place is defined regardless of any component(s) also specified in the sentence.23 An unconditional use of a location variable will return “an unknown place” for blank locations. The output of Location variables is also dependent upon Place Styles. Some use Place Styles to handle prepositions (e.g. put them in the addressee without a trailing comma) to get a better look in output that doesn’t use sentences.
On the Memos tab of report Options many reports can choose to output “Memos that are not included in the sentence”. The operation of this option is complex, especially if either the Main memo or the Witness memo contains split memo parts.24 However some general principals have been observed concerning this option:
• If the sentence for this Subject (Principal or Witness) is excluded from output, no memo will output as a result of this option even if there is no memo variable included in the excluded sentence.
• A memo part is considered “empty” by this option if it only contains the single placeholder character.
• In two reports (Descendant Indented Chart and Pedigree-Compressed), when this option is selected the entire memo is output including the subfield separators.
• Except for the two reports mentioned above, for tags which output a Subject’s sentence only the output and placement of the contents of the first Main memo part (i.e. [M] or its equivalent [M1]) is controlled by this option. No text from any other split part of the Main memo or any part of the Witness memo is generally output by this option, even if there are no variables to include such other parts in the sentence. Only the first Main memo part is output in the two reports (Family Group Sheet and Individual Detail) which do not have sentences for output.
• If a variable for that first Main memo part (i.e. [M] or its equivalent [M1]) is included in the sentence, its text will not also output as specified by this option since it has been included.
• If a variable for any memo part accessible by this sentence is included in the sentence and that memo part is not empty, then some memo text is output and thus included in the sentence. If such text is output, TMG will not output a non-included first Main memo part by this option. [See below concerning Witness variables and Second Site, which differs from TMG.]
• The inclusion of the special conditional Main memo variable <[M0]> in a sentence that will output will always inhibit the output by this option of a non-included first Main memo part in both TMG and Second Site.
• If all other conditions are met to output the Main memo part but that first Main memo part (i.e. [M] or its equivalent [M1]) is empty, it will not output due to this report option.
• While this option exists in the Pedigree Chart, it appears that only the first Main memo part of relationship memos are ever output.
To further explain, for a Principal sentence template, if any split memo variables of the Main memo beyond the first are included in the sentence template, and at least one of these parts is not empty and therefore outputs in the report, the first Main memo part (which does not have its variable included in the sentence template) will not output due to this report option. Only if the contents of every split Main memo variable beyond the first in the sentence template is empty, the non-included first Main memo part will output as controlled by this report option. This non-included non-empty first Main memo part will output even if any of the empty Main memo parts is specified by an unconditional variable and does output the text “(an unknown value)”.
The special variable for the (non-existent) “zeroeth” split Main memo part may be included as a conditional variable <[M0]> in the sentence. It should always be made a conditional variable25 and will output no text, but this report option will operate “as if” it outputs a memo value. Thus the perceived “output” of this special non-first Main memo part, like the output of any other non-first Main memo part, will prevent a non-included first Main memo part from being output by this report option. While it could be included in any sentence template as it will not output any text, it is only meaningful in a sentence that will output, i.e. one that is not excluded.
Witness sentence templates have access to more memo parts, thus the operation of this report option is more complex. These sentence templates can not only include Main memo part variables, but also all Witness memo part variables. The [WM] Witness memo variable refers to the memo for the focus Witness who is the Subject of this sentence, which is a separate memo from the tag’s Main memo and is separate for each Witness. In Witness sentences, the report option “Memos that are not included in the sentence” is controlled by both the Witness memo parts and the Main memo parts. All of the following must be true in a Witness sentence for this report option to have an effect:
• The Witness sentence must output for the Subject (i.e. is not excluded), and
• There must not be a Main memo variable for the first (or zeroeth) Main memo part in the Witness sentence, and
• There must be no other split Main memo variable included in the Witness sentence template which is not empty and thus will output, and
• In TMG there must be no (split) Witness memo variable included in the Witness sentence template which is not empty and thus will output. [In Second Site the presence or absence of any Witness memo variable has no affect.26]
If all conditions are met, the output in the Witness sentence which is the result of this report option will be the first Main memo part (the text for the non-included non-blank variables [M] or [M1]). This option will never cause any part of the Witness memo to output even if there is no variable included for such a Witness memo part. If you intend to use this Report option, it may be prudent to always include the special conditional Main memo variable <[M0]> in any Witness sentence template where you want to be certain to prevent output of a non-included non-blank [M] (or [M1]) as a result of this memo report option whether in Second Site, or in TMG in case all Witness memo variables in the sentence have no values.27 While a companion variable [WM0] may seem to make sense to ensure there is a Witness variable in TMG, that variable construct is not defined in TMG and will be treated as text.
Most standard tag sentences do not include any memo variables, so these tags seem to expect the memo to be controlled by this report option. If you want different memo text for roles assigned to the two Principals, you will have to subdivide the single available Main memo with the split memo code of ‘||’. The sentence must then use the split memo variables [M1], [M2], etc. and define the role sentences to include the variable for the appropriate split subfield. Such variables are usually made conditional in the sentence since they may not always have text.28 (See below concerning empty split memo parts.) Separate local or global sentences can be defined for each Principal, but [M] will still refer to the first part of the single Main memo. Some users who split the memo for each Principal reserve [M1] for use in the P1 sentence, [M2] for the P2 sentence, and [M3] for memo text to be included in both sentences so the numbers of the memo variables match the Principals. But if you intend to allow this Report option to control non-included memo output, it is recommended that you reserve [M1] for text to be controlled by this option, with subsequent memo parts reserved for the P1 or P2 sentences.
If you want to have some of the Main memo as part of sentences and some Main memo text controlled by this report option, you could be sure to always split the Main memo, make sure neither [M] nor [M1] (nor <[M0]>) is in any Principal or Witness sentence where you want this report option to operate, and thus reserve [M1] for entering text controlled by this report option.29 Alternatively you could create a second tag to sort immediately following the first. The second tag sentences would contain only the Special Sentence Variable [+] with no memo variables and the text to be controlled by the report Memo option would be entered in that tag’s unsplit Main memo.
People and Location variables, such as [P] or [L], can be used in the text of event memos as well as in sentences, but the values of those variables will output only if the memo will output as part of a report sentence. If the report option directs the non-included memo to be output in a footnote or endnote, the variable contents are not output. Instead the variable code itself (e.g. [L]) will be output. For example, you might use [WO] in a memo in order to keep from having to split the memo field. You can say either:
|
John Jones, Jane Smith and||also signed the marriage license as witnesses |
|
|
John Jones, Jane Smith and Sally Baker and Fred Adams also signed the marriage license as witnesses. |
|
Both forms will produce the same output in report sentences, but are completely different (and probably not useful) if the memo is output in footnotes or endnotes. In the first the footnotes/endnotes will contain the code [WO] and not the name(s), and in the second will only include the text from [M1].
If a memo field is split, and some earlier split parts are intended to be empty while later parts have text, a single special character must always be used as a placeholder in every earlier split part to ensure that TMG will always treat the split part empty. While leaving the split part truly empty will sometimes work in TMG (and always work in Second Site), there are at least two known bugs (in charts and citation detail output)30 where empty split subfields will cause problems in TMG. Thus I strongly recommend a placeholder character always be used for any TMG field which can be split. All missing subfields following the last split part entered will always be treated as empty, so trailing split separator codes and placeholders are not required. All narrative reports (that I have tested) will treat all split memo fields with the placeholders described below as empty. If the sentence variable referring to the split part with the placeholder is conditional it will not produce output associated with that split part. If the variable is unconditional it will produce the appropriate “unknown” text. TMG Filters searching for empty or non-empty split parts also will test empty for any split part containing only its placeholder character.
For any split part after the first, (e.g. [M3], [CD2]) a placeholder character of a single space will always cause that part to be recognized as empty. While TMG HELP in the topic “Memo” recommends using a placeholder of a single space in any empty memo part, I propose this is not a recommendation but a requirement. A single space in non-first split parts also has always been recognized by Second Site as a placeholder indicator for an empty subfield. (Since Second Site strips leading and trailing spaces from all memo fields and subfields, it is actually recognizing a now truly empty field after stripping the space.) Thus I strongly recommend this single space placeholder character always be used in a non-first subfield of a split field so the subfields will be treated the same in both programs. This space placeholder character can be inserted globally in existing completely empty subfields using the TMG Utility (see details below). Do not use a non-breaking space or an escaped space, as neither TMG nor Second Site will treat a split part with such text as empty. Also a split memo part containing only an exclusion marker, or leading spaces followed by an exclusion marker, may produce unexpected output.
For the first split part with following non-empty split parts (e.g. [M1], [CD1]), and only that first split part, a single space cannot be used as the placeholder since TMG will remove leading spaces from the beginning of any memo field upon data entry. Instead an actual ASCII Tab character must be entered as the placeholder to always cause that split part to be treated as empty by TMG.31 While leaving this split part truly empty will usually work in TMG (and always work in Second Site), as mentioned above there are several known cases where such a truly-empty first split part will cause problems in TMG. Current versions of Second Site will also treat the first split part containing only the Tab placeholder character as empty.32 Thus I strongly recommend this Tab placeholder character always be used in the first subfield of a split field so this subfield will be treated the same in both programs. Unfortunately TMG sometimes still will output and “display” the subfield in a way to indicate that Tab character by shifting following text over some spaces in both the field of the Tag Entry screen and in the expanded separate Memo screen. Further most “List of” reports will output and display this subfield with this placeholder character by shifting following text over some spaces if this memo part or the entire memo is explicitly selected for output. However, TMG narrative reports using the sentence templates and sentence variables will treat a first subfield with this placeholder as empty.
This special Tab placeholder character can only be entered within TMG by using Alt + 0009 on the numeric keypad.33 Outside of TMG this Tab placeholder character can also be inserted globally in existing completely empty first subfields using the TMG Utility (see details below). Do not enter the TMG code ‘[:TAB:]’ for this placeholder or try to press the Tab key to enter this character while within TMG. Using any other character in the first split part will not work as a placeholder, such as a non-breaking space or an escaped space, as neither TMG nor Second Site will treat the first split part with such text as empty. Also a first split memo part containing only an exclusion marker may produce unexpected output.
Existing projects may have some split subfields which were entered completely empty, lacking their necessary placeholder character. The TMG Utility “Other / Find and Replace” feature can be used to globally insert the appropriate placeholder character into whatever empty memo parts require them. It can also be used in “Log Only” mode to identify any empty subfields which require a placeholder. To insert the ASCII Tab character in all empty first split subfields, use Pattern Matching with the following patterns on all events for the “Event Memo” field, the “Witness Memo” field, or any field which can be split, as desired.
To insert a single space character in empty non-first split subfields, use Pattern Matching with the following patterns on all events for the “Event Memo” field, the “Witness Memo” field, or any field which can be split, as desired. Run the TMG Utility on a given field with this set of patterns as many times as necessary until the Log shows that no further replacements are being made.
|
Text entered in the Memo Field (with no delimiters). All variations of this variable work identically in Principal and Witness sentences. |
|
|
Same as above if no field delimiters in the text, else subfield one. Always use a single actual ASCII Tab character (Alt + 0009) as a placeholder to indicate this is an empty subfield whenever there is a later non-empty subfield. |
|
|
Subfields of the Memo field separated by the “||” delimiter(s) (two vertical bars/lines). For any subfield after the first, always use a single ordinary space character as a placeholder to indicate this is an empty subfield whenever there is a later non-empty subfield. |
|
|
A Memo subfield which is empty by definition. Included in both Principal and Witness sentences to avoid the Main memo [also] being output when not included in the sentence. Always place in conditional brackets “<[M0]>”. |
|
|
Text entered in the Witness Memo field for this Witness (with no delimiters). Any unconditional variation of this variable used in a Principal sentence outputs “an unknown value”. |
|
|
Same as above if no field delimiters in the text, else subfield one. Always use the actual ASCII Tab character (Alt + 0009) as a placeholder to indicate this is an empty subfield whenever there is a later non-empty subfield. |
|
|
Subfields of the Witness Memo field separated by the “||” delimiter(s) (two vertical bars/lines). For any subfield after the first, always use a single ordinary space character as a placeholder to indicate this is an empty subfield whenever there is a later non-empty subfield. |
|
|
While it would appear that this construct would define a Witness Memo subfield variable which was a companion to the [M0] Main Memo subfield variable, this variable construct is not defined and is treated as text. |
|
|
A source citation embedded in a memo of an event tag will produce a source footnote or endnote as appropriate for source citations using the elements of source num with a surety of sure, cd as the citation detail, and cmemo as the citation memo. See my Source Guide for details concerning the use and limitations of embedded citations. |
There is no mechanism to identify when last you edited a specific tag.34 The Last Edited date in the Other information box on the Details screen will be automatically updated for that person for a variety of reasons35 which you may not consider to be “editing” a tag, and that date is by person not by tag. To track tag editing information one could reserve an otherwise unused split memo part, e.g. [M9], to record the history and details of editing that tag. The edit information could contain only the latest or a sequences of editing session dates, and even comments about the editing. If the memo begins with the (most recent) edit date text as YYYY/MM/DD numbers, you could output the [M9] field in a List of Events reports sorted by that date, or even filtered for a specific session where [M9] “contains” a specific date. I have not (yet?) found a need for this granularity of record keeping to justify the added data entry. See also using a dummy source for this purpose, which I consider has more advantages.
While these special formatting codes are extremely useful, care must be taken if multiple codes are used associated with the same text. For example, there may? be issues when Italics, etc. surround variables as well as text.36 These codes may be entered either directly as text, or by use of the menu obtained by a Right-Mouse-Click. However that menu must be used with care as adding new formatting to text with existing formatting may delete that existing formatting.37 To separate into paragraphs, put [:CR:] (and optionally [:TAB:]) at the beginning of a sentence, not at the end. Embedded format codes may be used in sentence templates, memos, text exhibits, and in a citation’s detail or memo field. My testing also shows that most text-modifying codes work in both source elements and source templates.38 Embedded format codes may be nested, but may not be crossed, and there is an order of precedence required when nesting codes.39 In addition to the note to not nest other TMG Embedded Format Codes inside the TMG internet codes (WEB, EMAIL, or HTML), there is a remaining bug where any text simply formatted with those TMG internet codes has display problems on the screen regardless of any further nested formatting.
I use both the WEB and HTML Internet codes to provide hyperlinks to Internet URLs, but have settled on custom ways to use them which includes bracketing URL or hypertext link output with ‘<‘ and ‘>’ brackets. While I prefer to let Second Site automatically include them in source text, or use the TMG WEB code in narrative text since it is simpler, there are often circumstances where the more general HTML codes are required. This can be either if I wish special options in the HTML, or there is a semicolon40 in the URL itself, or if I desire some portion of Internet hyperlinked text to have formatting, such as italics. For example, I usually enter the Title of that URL’s web page as the hyperlinked text, and such Titles often contain Italics. As an undocumented feature the TMG ITAL codes “can” be nested interior to the TMG WEB codes in the text part, but this can cause problems and program errors. While the nested Italics will be honored within the raw WEB text and the codes will cause formatted output in TMG reports, those nested ITAL codes are output as raw text in Second Site. Further, nesting these TMG ITAL codes interior to TMG WEB codes causes data entry problems in TMG (described in a remaining bug) whenever you re-edit such text.
The trick in safely using semicolons in the URL or formatting within the hyperlinked text is to use multiple sets of TMG HTML codes instead of a single set of WEB codes and thereby avoid any nesting.41 My (rather complex) HTML codes below ensure that their output will look identical to output from my similar WEB codes in both TMG reports and in Second Site. They include the special Second Site format codes described below to ensure selected “portions” of the HTML commands are only seen by Second Site and some text is only output by TMG. If a TMG report is desired to output directly to HTML my set of codes will not be appropriate, but I seldom produce TMG HTML report output since I prefer to use Second Site for Internet output instead. The table below allows me to copy/paste these more complex HTML codes whenever I wish to use them. See also my use of these Second Site codes for Exhibit captions.
|
[HID:] |
|||
As an example of using the complex set of HTML codes above, one of my common uses is to include the specific web page found on the FindAGrave site as part of the Citation Detail of a Burial tag. The URL title for a married woman on that site will usually include her maiden name in Italics. The following CD fragment is an example which will include those Italics for such a citation.
\<[HID:][SS:][HTML:]<A HREF="[:HTML][:SS][:HID]https://www.findagrave.com/memorial/51128111[HID:][SS:][HTML:]">[:HTML][:SS][SS-HID:][:HID];[HID:][:SS-HID][:HID] Elizabeth [ITAL:]Forsythe[:ITAL] Furey[HID:][SS:][HTML:]</A>[:HTML][:SS][:HID]\> Old Saint Patricks Cemetery, Enfield, Hartford County, Connecticut
TMG HTML Internet codes can enclose portions of the actual HTML commands, such as one set for the beginning portion of the hyperlink command and one set for the ending command. With these separate portions the TMG ITAL codes (or any similar embedded formatting codes) are not nested within a TMG Internet code, and thus no errors occur. The above example fragment of a Citation Detail when in TMG reports not output to HTML will not include a hypertext link since such reports are usually printed. But identical to the equivalent WEB code, these HTML based codes in such reports will output the URL as well as her name yet with the maiden name in Italics as:
… <https://www.findagrave.com/memorial/51128111; Elizabeth Forsythe Furey> Old Saint Patricks Cemetery, Enfield, Hartford County, Connecticut …
And identical to the equivalent WEB code, these TMG HTML based codes in Second Site will output this Citation Detail fragment as only her name but with the maiden name in Italics:
… <Elizabeth Forsythe Furey> Old Saint Patricks Cemetery, Enfield, Hartford County, Connecticut …
and like the equivalent WEB code that full name is now a hyperlink to the URL. With these sets of HTML based codes the output can be made to look identical to my use of the WEB code but can now include nested formatting in the text in both TMG printed reports and Second Site.
|
Define First Letter Capitalized text.42 |
|
|
Replace ‘<F>’ with a single letter to assign the font definition of the report output type ‘F’ to this text. The single letter ‘F’ is one of the upper case characters from this list of report text types: Text, Surnames, Given, Dates, Locations, Memos, Exponents, laBels, tItles, Page no. This FONT code will override the default font definition for this text from the report options. |
|
|
Define up to three levels for the TMG index named at this point in the text. Separation of the output values by [semi]colon within the INDEX codes causes a newline within the generated index, a comma keeps it on the same line. Do not include spaces either before or after the [semi]colon values separators. Example: [INDEX:] |
|
|
Define text that is never to output in a TMG report under any circumstances. |
|
|
Define the point size of text, where size = 0.9 to 999.9. Only a semicolon separating the size from the text is required. This code will be ignored if the current font is not scalable. |
|
|
[COLOR: |
Specify the color of the font and background for the enclosed text. Each color is an RGB color integer, 0-255. This COLOR code will override the color from the default font definition in the report options for this text.43 |
|
Left indents text.44 Both the starting and ending code automatically produce a carriage return. The pair [:LIND][LIND:] inside already indented text will produce a single carriage return, but multiple such pairs will not produce multiple carriage returns. Added carriage returns or [:CR:] codes either before or after these codes may produce extra blank lines.45 [Note that the ending [:LIND] code will always produce a carriage return in Second Site46, whereas in TMG reports it will only produce a carriage return if there is not already a carriage return following that ending code.] |
|
|
Centers text.47 Both the starting and ending code automatically produce a carriage return. Added carriage returns or [:CR:] codes either before or after these codes will produce a blank line.48 |
|
|
The text between the codes is assumed to contain HTML command coding. This HTML formatting will only work when output to HTML or in Second Site. Otherwise the TMG HTML beginning and ending codes will be stripped but the entire text will output. If you place TMG HTML codes directly into a sentence structure field, its contents may include “<” and “>” which will need to be escaped using the “\” character to prevent them being interpreted as TMG conditional brackets for sentence variables. Alternatively, enter the HTML codes into the memo field instead and refer to it from the sentence field with some variation of the <[M]> code. See below to output HTML code only in Second Site. Do not nest other TMG Embedded Format Codes inside these HTML codes.49 Depending upon whether I desire to format some of the text, such as with Italics, I use either these TMG HTML codes or WEB codes and my trick mentioned above to have consistency between the two types of output. |
|
|
This is equivalent to the TMG codes If only the url is provided it will be duplicated as the text. Like the similar TMG HTML codes, this formatting will only work for output to HTML or in Second Site. Otherwise the TMG WEB beginning and ending codes will be stripped and the entire url;text will output. See the remaining bug if the url contains an ampersand. See below to output HTML code only in Second Site. See the note to not nest other TMG Embedded Format Codes inside these WEB codes. Depending upon whether I desire to format some of the text, such as with Italics, I use either these TMG WEB codes or HTML codes and my trick mentioned above to have consistency between the two types of output. |
|
|
This is equivalent to If only the address is provided it will be duplicated as the text. If the address does not include “mailto:” then it will be inserted. This formatting will only work for output to HTML or in Second Site. Otherwise these EMAIL codes will be stripped and the entire text;address will output. See below to output code only in Second Site. See the note to not nest other TMG Embedded Format Codes inside these EMAIL codes. |
|
|
The Second Site program will recognize this pair of codes as marking the text within as special code for its use. [HID:][:HID] codes are also used to prevent TMG from outputting the SS codes as text. For an example of my use of this construct with the Second Site PageLink code, see linking Source citations to Source People. |
|
|
[HID:] |
This sequence will be recognized by Second Site as direct HTML code to be output only in Second Site as part of this memo/sentence. Because of the [HID:][:HID] codes none of the bracketed text will be output by TMG. For an example of my use of this construct see my trick mentioned above for using these codes to include other TMG formatting within hyperlinked text. |
|
[HID:] |
The Second Site program will recognize this pair of codes as marking the text within as special text which it should ignore. [HID:][:HID] codes are also used to prevent TMG from outputting the SS codes as text, but since the interior text is not hidden it will be output by TMG. See my trick mentioned above for using these codes to include other TMG formatting within hyperlinked text. |
|
The exact coding ‘\|\|’ indicator as text within a NarrativeChildren tag sentence causes only Second Site to use any text before this indicator as the Family Section heading, and the text that follows as a narrative note appearing above that Family Section’s list of children. HID and SS codes are used to prevent TMG from outputting these SS-only codes as text. |
|
|
This special code is only recognized by TMG and can be used in the sentence structure of a NarrativeChildren tag to completely suppress a Journal’s Family Section output. |
|
|
This special code is only recognized by TMG and can be used in a custom sentence structure of a NarrativeChildren tag to cause birth places to be suppressed from the subsequent list of children in a Journal’s Family Section. Normally if this variable is present in that tag sentence, that sentence will output the location from the tag in the heading as a common birth location for all children. |
Roles can only be defined as part of the generic global definition of a tag type.50 A role name has a maximum of 23 characters.51 They can not be added to a single instantiation of a tag, although as of Version 8 the “New Role” window can be accessed from a tag for adding a role to the definition of this tag’s type. Version 8 added a number of new provided roles and expanded the role names of many existing roles in new projects. It also now allows any role (other than Principal and Witness) to be disabled so that it will not show in the list of available roles. Generally I prefer to disable TMG provided roles I don’t use rather than delete them, so I can choose to review them for ideas later. As of Version 8.08 trying to create a sentence using a role variable for a role name which does not (yet) exist will give an error and not allow the sentence as defined. You will need to first add all the roles desired to a tag type, then go back and create sentences using those role variables.
As of Version 9 Roles can have separate Reminders defined in the Tag Type Definition, and as of Version 9.01 the Principal role can also have a Reminder. When in the Tag Entry screen the Reminder window will show the Tag Type reminder, plus the role reminder(s) of the role(s) assigned the Principal(s), if any such reminders exist. The Reminder window will only show the role reminder on the Add/Edit Witness screen if it exists, and will change if you change the Witness’ role. If no role reminder exists, the Witness Reminder window will display only the tag type reminder if it exists. If no approprite reminders exist, clicking the Reminder button will give a “No Reminder” message on the Tag Entry screen, and on the Add/Edit Witness screen the Reminder window simply will not open.52
Enabling the new provided roles in early releases of Version 8 could change which role would be offered as default for a new witness.53 As of Version 6 but prior to Version 8.07 the sort order of role names in the list of roles for that tag type could determine which roles were defaults.54 As of Version 8.07 the default role for Principals and Witness now may be set by the user in the Tag Type Definition regardless of that role’s sort order in the list of roles. The conversion of earlier version projects to Version 8.07 and later may cause some roles to be default which are not intended.55 One role now may be set as ‘P’ which will make it the default for both P1 and P2. Alternatively one role may be set to ‘P1’ and a different role to ‘P2’ and those roles will be the default for those Principals. Only one role may be set to ‘W’ and this role may not also be set to be a Principal default. When entering a series of witnesses during a single tag edit session, the default role is always set to the role assigned as the Witness default.56 Prior to Version 8.07 the default would be the role selected for the witness just previously added to that tag.
A role marked as a default in one language will cause the role in that same role order in all other languages for that tag type to also be marked as that default. The appropriate default role will be assigned to any Principal that has no linked person, and to a new Witness. If the tag type of an existing tag is changed, the role of a linked person will be retained for any role name that also exists in the new tag type. If the role name from the old tag type does not exist in the new tag type, the person’s role will be changed to the appropriate default role as defined for that new tag type.
If a role is marked as a default, you cannot delete or disable the role, and you cannot edit the role name. To do any of these, set the default to some other role. The roles “Principal” and “Witness” can never be renamed, disabled, or deleted whether or not they are currently set as a default.
Role names have a max 2357 characters for the name of the role.58 They can be assigned to either a Principal or a Witness, but your custom sentence for that role usually is intended for one and not the other. As a memory aid, I choose to capitalize custom role names intended for Principals, and use all lowercase for role names intended only for Witnesses.59 WhollyGenes changed the behavior of role names in Versions 8.0 through 8.04 in an attempt to enhance internationalization and standardize translations of role names. However, the implementation proved to cause many problems for users. Version 8.05 reverted to a behavior more similar to Version 7 and before. Role names are now a Tag Type property and thus unique to each Tag Type and each Language within that Tag Type. The role name in a different language is considered a translation of the role name in that same role order in that tag type in all other languages. While any capitalization may be used, only one role name using the same case-insensitive sequence of letters may exist in a given language in a given tag type. The right-click menu within a sentence or memo now provides a list of all the role names and their variables in this language.
Any tag type can specify whether a person’s role name will show at the beginning of the descriptive information for a tag of that type in the Person View of the Principals and/or Witnesses. I find this a very helpful visual reminder that this person has been assigned this role in this tag.
There is generally no need to use the role variable (see also Linked People sentence variables) in the sentences just because this tag type defines roles, but there are cases where you must, and cases where you cannot.60
1. If you use a role either for Principals or for Witnesses, you still can use the appropriate [P] or [W] or [S] to refer to that target person. Prior to Version 9,02 [R:role] could be used to refer to the target person(s).
2. If you use a non-Principal role for one Principal, you no longer must also use a non-Principal role61 for the other Principal. Also, if you use a role for one Witness, you still can have other witnesses that only have the prenamed role of “Witness”.
3. Special name forms (e.g. first word of given name) are not available for [W] variables, so either the variations of the [S] variable must be used or roles must be used. The name “Witness” is a predefined role and prior to Version 9.02 could be used in most (not RPAR) role contexts, e.g. [RF:Witness]. Now such a Role variable always will return all first names of people assigned the role “Witness” where previously it could return only the focus Witness’ first name. The [S] variable with all its variations was introduced specifically for this purpose.
4. When you are writing the sentence structure to refer to any other person(s) (not the focus person) linked to the tag, and want to refer to people who have a Role:
1) A Role variable must be used if you want to refer only to all persons assigned a specific Role (and the tag has people assigned that role).
2) In a Principal sentence if you want to refer to the other Principal who may have been assigned any one of several possible roles you must use [PO]. For example, if you have a tag type in the Marriage group where custom Roles are defined and assigned to identify whether a spouse was the first, second, etc., then you must use [PO] in the global Principal sentence to refer to that spouse since you cannot know which one of these many custom Roles will be in use for this spouse in this tag.
3) In either a Principal or Witness sentence to refer to all the (other) Witnesses who each may have been assigned several different Roles you must use [WO]. Even if all witnesses are assigned a variety of roles, and not the generic role of Witness, [WO] in a witness sentence will still refer to all witnesses to the tag excluding Principals and this focus witness.
4) There are no variables defined to use in a sentence for a Role which refer only to all the other people assigned this same Role. You must either list all persons with this Role with some form of [R] variable, or list all other Witnesses regardless of their Roles with the [WO] variable.
5. If multiple people are assigned the same role, the output of a role variable specifying pronouns for that role will be plural.
There are probably as many different ways to use roles as there are users of TMG. One example is to collapse different potential custom types of the same kind of tag into one tag type by having roles and their respective sentences that reflect those other types. For example, a Birth tag type with a custom role of “Conflict” and a role sentence like “Conflicting evidence indicates [P] was born <[D]> <[L]>. <[M]>” would avoid defining a separate custom tag type in the Birth group possibly named “BirthConflict” with its (probably this same) custom sentence. Other classic examples of custom roles are to identify roles in a wedding, a will, or an obituary as part of a single tag. Often these can lead to extremely long and complex sentences, with an optional part for each of the many defined roles.
Proposed Tag Sentences not yet entered
These multiple roles insure consistency of text for a given witness, and allow that role to show in their Person View. However, I prefer to have split memos, and put the role as one of the memo parts. This allows a single more generic role to be used for nearly any contingency and still get a tailored sentence. Multiple roles also automatically provide appropriate added text in the Principal’s sentence simply by adding that specific role. Again, I prefer to have a split memo for the Principal, and a generic Witness role, and manually insert the appropriate variable text in the main memo and witness memo for their sentences.
[:CR:][:TAB:][R:wife] was listed in [R:Deceased]’s obituary <[D]><[L]> as his wife.
Example Obituary Full Footnote Template
[ARTICLE TITLE], [ITAL:][NEWSPAPER TITLE][:ITAL], [LOCATION]<, [DATE]><, [PAGE]><. Original held by [REPOSITORY INFO]><. [PRESENT OWNER]>. Hereinafter cited as [SHORT NEWSPAPER TITLE]><: [PERSONAL FILE FOLDER]><, [SOURCE NUMBER]>.
[PP] obituary was published< on [D]>< [L]>, and stated:[:CR:][:TAB:][M]
Wife: [:CR:][:TAB:][R:wife] was listed in the obituary of [P], <[D] ><[L] >as his wife.
[PP] obituary stated [:CR:][:TAB:][M]
and put [ITAL:][:ITAL] around the text in the memo. Don’t put them in the template as you get a hanging period.
[TESTATOR] will< ([DATE])><. As quoted in [AUTHOR], [ITAL:][TITLE][:ITAL] ([PUBLISHER ADDRESS]: [PUBLISHER]<, [PUBLISH DATE]>)<, [CD]><. [REPOSITORY INFO]><, originally recorded in [WILL BOOK]><, [PAGE]> <: [CD2]><. Hereinafter cited as [ITAL:][SHORT TITLE][:ITAL]>.
|
Endnotes |
|---|
|
1. The Subject variable [S] and its variations introduced in Version 9, as well as any witness variables, are not recognized in Name tags since these tags cannot have witnesses and their sentences can only be for a Principal. For the same reason Name tag sentences do not recognize [PO], [P1] or [P2] or their variations, or any role variables, since a Name tag cannot link to a second Principal nor assign a role to the one Principal. A Name tag also has no location so none of those variables are recognized. If any unrecognized variable is included in a Name tag sentence, the variable and its brackets will be output as text. 2. The variables referring to the “other” Principal ([PO] or [P2] or their variations) are always undefined when used in sentence templates in these two tag groups and will give the “unknown person” text if used unconditionally. 3. Prior to Version 8 there was a bug which caused Preferences > Program Options > Warnings to control whether you got this SEX warning. If you unchecked “Warn when date is outside the appropriate date range” and unchecked “Warn when date MIGHT be outside the appropriate date range” then the appropriate SEX warning was also not given. There was also no warning if no date was entered in the tag. This bug was fixed in Version 8. 4. It is assumed that when entering the memo you will know whether the variable has a value so conditional is not recognized. 6. The TMG HELP explicitly states that “Conditional brackets and variables cannot be nested” and implies that only one variable may be included within a single set of conditional brackets. However it can be shown as an undocumented feature that if multiple variables are included within a single set of conditional brackets, the text within those brackets is only output if all variables within those brackets have value. 7. Sensitive data in a Name is always included in a TMG Individual Narrative Index. Sensitivity markers in a sentence template are not removed. 8. In the narrative formats where the tag is not excluded but there is no sentence text output, Second Site is more careful about end of sentence processing. There will be no period like in TMG, but since the tag is not excluded any citation references or icons for linked exhibits for the tag will output. These will appear to be for the preceding sentence. Also, for non-narrative formats, since the tag is not excluded there will be a row or list entry for the tag, and that may show the label, date, place, etc. even if the sentence template would produce no sentence text. 9. As of Version 6.08 a leading period or a leading semicolon would generate an inappropriate space in front of those punctuation characters, but a leading comma in an optional field would not. There is no inappropriate space in the final Version. 10. As of Version 6.08, if there was an optional variable following [L], but the optional variable was not present you got ‘,.’, i.e. the trailing comma from inserting the location data was not removed before the end-of-sentence period. My workaround was if there were more optional variables following [L], put [L] immediately before an explicit period, e.g. “<[M]><[L]>.<[WM]>” but not “<[L]><[M]>.<[WM]>”. The following split memo structure at the end of a sentence worked as expected: “… [D]<, text [M2]>.< [M3].>< [WM]>”. This problem was fixed as of Version 8.05. 12. As noted in a remaining bug, this “trick” of an escaped period works in sentences, but not in TMG reports for citations. 13. There is a remaining bug for a sentence with an [:NP:] code which has multiple citations. Only the first citation will be output. A second remaining bug will add a closing period to a tag sentence even though the [:NP:] code should prevent that, if the sentence is the last tag which is output for a person in a Journal report and it contains text which does not end with sentence-ending punctuation. A third remaining bug will cause end-of-sentence processing to be performed at the end of a citation even if some part of the citation (a source element field, or the source template) contains the [:NP:] code. 14. Reported as a remaining bug, if no tag sorts previous to this tag for this narrative report, the [+] code itself is output. 15. Due to a remaining bug, for sentences in tags in the Name group the [P] variable used at the beginning of a new paragraph in a narrative will always output the appropriate pronoun. 16. For example, the new paragraph with the heading for the list of children in a Journal report will use the full name, but a [:CR:] to force a new paragraph within a person’s narrative does not cause a subsequent [P] to revert to full name. 17. See the Lee Hoffman book GMOTMG, pp. 76-77, for admonition to avoid using the role variable in the sentence for that role. The new [S] variable was introduced in Version 9 to avoid this issue, and with its availability all [R:] variables then were changed in Version 9.02 to always output based on all people assigned that role in this tag. 18. Due to a remaining bug, the trailing commas from the various PAR variables will output in reports, but do not show in the Sentence Preview. 19. TMG computes age as a sentence variable, the person’s Age in Other Info, or the Age column for each tag in the Details window. The age may have a trailing question mark usually based on the question mark as a date modifier, or for the Other Info also if the LIVING Flag has a value of ‘?’. See also Date Question Mark, and my Style comments about the LIVING flag. Need to retest this as my notes on this behavior vary, then update all comments. Last tested as of Version 7.04. 20. Need to test a number of examples of date formats, including the presence or absence of an appended question mark, to figure out how age is calculated. Also need to test whether the LIVING flag being a value of ‘?’ will produce the question mark for age in reports since it does not do so for the Age column in the Details view, but it does do so for the Age in the Other Info. This is mentioned in numerous places in these documents and my notes vary, so more testing is needed, and all notes updated. 21. The desire for such a variable is what motivated the brief change in the output of [A] in Version 6.02. 22. Due to a remaining bug, the trailing comma from the [L] variable will output in reports, but does not show in the Sentence Preview. 23. Note that the numbers and order for the location fields (L3, L4, etc.) changed from Version 4 to Version 5 when the combined Lat/Long/Temple field was moved to the end of the list and split into two fields. Upgrading an existing set of files moved the entered data to the appropriate new order and number. 24. The pair of characters ‘||’ which indicate a split memo are recognized in any TMG filter as a special case, so each of these characters do not need to escaped when entered as a pair. To find events with split memos, run a List of Events report which includes the filter condition of: 26. John Cardinal, author of Second Site first reported on the TMG Listserv that SS worked like TMG: “When you check the SS report option ‘Include Memos from witnessed events’ in the section ‘Memos that are not included in the sentence,’ the Main memo will not appear if there is the [WM] variable in the witness sentence. Apparently a [WM] is a memo for purposes of this option in Second Site.” But that is not the case in SS. Even if WM is output, the Main memo will appear. Both John and I were initially fooled by this one. Unfortunately, that means that SS works the way one might have expected TMG to work: in SS, you have to supply <[M0]> to suppress the Main memo whether or not you use [WM]. 27. If you never want the first Main memo part output associated with the Witness sentence, including the special “<[M0]>” conditional variable construct in the Witness sentence will do no harm. 28. If the sentence for a tag in the Name group contains an unconditional split memo variable (e.g. [M2] not in conditional brackets) it does not output “an unknown value”. Instead due to a remaining bug it outputs the variable as text (e.g. “[M2]”). 29. I actually like this idea of reserving [M1] for a memo controlled by the report option. But I have not (yet) gone back and redefined all my sentences to use this feature now that I (finally) understand how it behaves and have discovered a working placeholder for an empty [M1]. Instead I have made sure to include <[M0]> whereever appropriate in my custom sentences. 30. While placeholders should always be entered for empty subfields, there are at least two remaining bugs in the final TMG Version which occur if placeholders are not entered. One occurs in some charts if any of the memo parts are without their special placeholder character. If the first memo part is left completely empty without its Tab character placeholder, or a subsequent memo part has no space character placeholder, this bug will produce output which is not at all what is expected. Another bug occurs when leaving non-first memo parts completely empty (“||||”), especially in citation detail subfields. While such empty parts may work in other subfields for “most” TMG output, the absence of the space character (“|| ||”) placeholder still can cause unexpected output, and is known to cause the problems described in the previous chart’s bug. Also users have mentioned other cases where missing placeholders will cause incorrect output, but I have not tested or recorded these cases here. I simply urge always using a placeholder character to ensure proper output. 31. I believe I have tested all possible ASCII characters and the ASCII Tab is the only placeholder character I could find which when entered in the first memo part subfield will cause that memo part to be treated by TMG in most situations as if it is empty. The fact that TMG treats it in this manner is an undocumented feature since it is not mentioned in TMG HELP. 32. In Second Site versions prior to Version 5.3 Build 07, a single ASCII Tab character in the first memo part was not treated as a placeholder for an empty subfield. That character was always treated the same as the [:TAB:] printer code: Second Site wrote 5 non-breaking spaces to the output file. As of Version 5.3 Build 07 and later a single ASCII Tab character as the only text in the first memo subfield now is also recognized as a placeholder indicating an empty first memo part to match its TMG behavior. 34. There were numerous wishes for such a mechanism posted by users on TMG ListServ but the final Version has no such feature. 35. The date is updated whenever a Tag Entry screen is exited using either the “OK” button or F9, even if no changes were made to any information. It is not updated if exited using either the “Cancel” button or Esc. It is updated for both Principals when editing either shared Event tags or Relationship tags. Depending upon Preferences and Report Options settings it also may be updated when a Flag is edited either manually or by Secondary Output of a report. 36. Not sure why I have this separate admonition about Italics codes, as it does not seem to be true? Needs testing since last observed in Version 6. However, there is a separate issue which I identified when I attempted to use Italics within the text in a [WEB:][:WEB] construct. 37. While it is not clear if this is a “bug”, I have detailed the circumstances where existing formatting can be deleted as a bug in my separate Outstanding Bugs document.
38. The following codes have been tested and work in Source elements, such as the Title field, of a source definition: UND, BOLD, ITAL, SUP, SUB, SCAP, CAP, FCAP, FONT, and COLOR. However one must be careful about nesting codes. If the template encloses the element in a code (e.g. ITAL) be sure to end that code before starting a different code within the element text, then end that different code and restart the template code. For example if the template encloses the element with ITAL, enter: All these codes except FONT and COLOR also work in Source templates. FONT seems simply to be ignored. COLOR produces an error that the template “contains unbalanced embedded codes.” Some others (e.g. FCAP as of Version 8.04, and :NP: in the final version) may not work in various versions. I need to do further testing of all embedded codes in both source elements and templates. Last tested in Version 9.05. Also need to do more testing concerning nested sequence order in source templates. 39. The final Version Help in the topic Available Format, Font, and Other Codes lists the precedence order in sentence and memo fields for only the following codes: UND, BOLD, ITAL, SUP, SUB, WEB, SCAP. This list is clearly incomplete, missing are: CAP, FCAP, FONT, SIZE, COLOR, LIND, CENTER, HTML, EMAIL, HID, INDEX. There was some discussion that these unmentioned codes are processed independently, but testing shows that order does matter for some, especially the two Internet codes. (See the note for TMG’s Internet codes of HTML, WEB, and EMAIL concerning their partially documented requirement to be most interior when nesting.) As one test, the Right-Click menu puts the Bold codes outside the new Color codes, and I suspect based on other tests that FCAP must be very/most interior. I need to test the precedence order requirements for all these codes in the final Version. So when using multiple codes, they need to be applied in that order — earliest outermost. [BOLD:] [SCAP:] text [:SCAP] [:BOLD] is correct. [SCAP:] [BOLD:] text [:BOLD] [:SCAP] is wrong, and has side-effects. 40. In a [WEB:][:WEB] construct one can replace the semicolon in a URL with the three character HTML code ‘%3b’, but I prefer seeing the actual text so I revert to using the more general [HTML:][:HTML] codes instead. 41. If you already have nested ITAL or similar formatting codes within WEB codes, you can use the powerful TMG Utility to change all occurrences of WEB codes to my equivalent set of codes which use HTML all at once. As an example, the following “Change Citation Parts” rules will make this global change within CDs. Note that it will only change one occurence of WEB codes with embedded formatting codes within a CD. If you have more than one set of WEB codes with embedded formatting in a single CD then multiple passes using these “Change Citation Parts” rules will be required. If Detail like "\[WEB:.*?\[ITAL.*?\[:WEB" Change Detail replace pattern "(.*?)(\[WEB:\])(.*?)(; *)(.*?)(\[:WEB\])(.*)" with "$1[HID:][SS:][HTML:]<A HREF="[:HTML][:SS][:HID]$3[HID:][SS:][HTML:]">[:HTML][:SS][SS-HID:][:HID];[HID:][:SS-HID][:HID] $5[HID:][SS:][HTML:]</A>[:HTML][:SS][:HID]$7" 42. [FCAP:][:FCAP] did not work (was ignored) in Second Site Version 4.0. (It is possible a nesting sequence in my data was my issue. Second Site’s author John Cardinal claims that FCAP works but must be most interior in nesting.) However, Second Site has more aggressive code to recognize internal sentence breaks and may give an initial capital at the beginning of a sentence (e.g. internal to a single tag narrative output) which TMG will not. All this needs to be tested again in the latest Version of Second Site. 43. The COLOR code was added in Version 8 with the new report generator which will now output color. 44. Due to a remaining bug, in a report output as HTML the [LIND:] code begins (more) indentation, but [:LIND] never causes the indentation to end. Due to a second remaining bug, in any report which itself is designed to be indented, text following a [:LIND] ending code does not use the correct (possibly indented) margins but instead goes back to the far left unindented page margin. 45. Prior to Version 8 the LIND code did not take effect until the next carriage return, and the indentation did not end until a carriage return. [LIND:] was often preceded by the [:CR:] code since that would immediately start the indentation, and [:LIND] was often followed by a carriage return to end the indentation. Also as of Version 8 the formatting works in screen preview. 47. The CENTER code has no effect on the output if the TMG report is output to HTML due to a remaining bug. 48. Prior to Version 8 the CENTER code did not take effect until the next carriage return, but the centering ended with the closing code since it also produced a carriage return. [CENTER:] was often preceded by the [:CR:] code but any carriage return following the closing would produce a blank line. Also as of Version 8 the centering formatting works in screen preview. 49. Discussions on the Forum and TMG ListServ suggested that, when nesting codes, by their nature all three of TMG’s Internect codes HTML, WEB, and EMAIL must be most interior, and other TMG format codes may not nest inside them. Testing shows that some formatting codes interior to these Internet codes do cause problems (described as a bug). The Help does not explicitly discuss format codes interior to EMAIL, but the precedence order in Help does imply that WEB must be interior to other format codes (except possibly SCAP). And the separate Help topic HTML Embedded Codes does explicitly state: “TMG embedded printer codes for bold, etc., may not be embedded within HTML code.” Need to test this further in the final Version to determine which other codes could work interior to which of these Internet codes (as an undocumented feature with or without problems), and which will not. Clearly some codes (such as italics) appear to work nested within these TMG Internet codes, although with associated problems. 50. An excellent tutorial on roles is on Terry Reigel’s site at: https://tmg.reigelridge.com/Roles-Tutorial.htm 51. Version 4 limit on a Tag Type Label was 10 characters, and Version 5 expanded this to 21. As of Version 6 names were truncated at 20. Since Version 8.05 the maximum is 20 characters for the Label and 23 for a role. Previous versions had side-effects if you entered too many characters, but since Version 6 your entry is truncated to the maximum. 52. Note to self: Need to define and test Reminders for all my custom tag types and roles, and record them in my Tag Type Descriptions chapter. The table in the Tag Sentences chapter should then have a link back to the Reminder text for that tag or role. 53. In Version 8 but prior to Version 8.07 a new witness would default to the first/topmost enabled role in the list for that tag type, not including “Principal”. By default for all tag types prior to Version 8 the default for all new witnesses was the role name “Witness”. If the new provided roles were enabled, for some tag types the new role names were inserted in the list before “Witness”, and thus the first of those enabled roles in the list became the default role for a new witness. For example, “Bride” was the default witness role presented for a Marriage tag. In Version 8 but prior to Version 8.07 users need to customize which roles are enabled, and/or their order, to cause their desired role to be default. In those versions to revert to Version 7.04 behavior, the role “Witness” should be the first/topmost enabled role in the list for that tag type, not including “Principal”. The list of tag types where the placement in the list of new Version 8 roles will affect the witness role default are: Address, Baptism, Birth, Birth-Covenant, Birth-Illegitimate, Birth-Stillborn, Burial, Christening, Death, Divorce, Divorce Filing, Engagement, Marriage, Marriage bann, Marriage contract, Marriage license, Marriage settlement, Probate, Rebaptism, SealParentLDS, SealSpouseLDS, Stake. As of Version 8.07 the order of roles in Standard tags was reordered to make “Principal” first and default ‘P’, and “Witness” second and default ‘W’. 55. As of Version 8.07 standard tag types will have the role “Principal” set to default ‘P’, and “Witness” set to default ‘W’. Converted tag types will have the role sorted first in the list set to default ‘P’, and the second role set to default ‘W’. 56. In my tag types I generally set the Witness default to the role which is likely to have the highest number of such Witnesses for that tag type to minimize the need to change role assignments. If I am going to enter a series of the same type of Witness, I can temporarily change the Witness default in the tag type. |
Disclaimer
I am not affiliated in any way with TMG™, its company Wholly Genes, Inc., or its primary author Bob Velke, nor with John Cardinal, author of several TMG after-market programs. I am simply a satisfied user of these software packages and have constructed these documents to aid me in their use.
If others find these documents useful, so much the better. I do not warrant in any way that they are accurate or useful, and any use of them is at the user’s own risk.
These documents were composed with Adobe® Framemaker 2019® using its hyperlink and "Save as HTML" conversion features.
©MJH Consulting, 1996-2020. All rights reserved.