John Garvert

Thanks for the links Michael. I had already looked at those as well as many of the online tips. I guess that is why I was all wrapped around the axle and started this post. Information overload. I then started to implement the "place-person", but I decided that was getting too confusing. Plus, I already use "non-persons" for cemeteries, census, hospitals, etc, and by using TMG in a non-standard way, I got burned when I discovered that excluding witnesses does not work like it does for principals, citation sources, etc. (see prior post Hidding "non-person" witnesses). So I decided on a simpler approach I think will work, still working out the bugs (opinions welcome), although it includes evaluating the best implementation approach for each individual and place separately. I created several new place styles like "DE (modern in German)", "DE (modern in English)", and "German Old". I then created two new Address Group tags, "PlaceModernDeGerman", default place style "DE (modern in German)" and identical Principal/Witness sentences "<The modern name is [L].><M.>" "PlaceModernDeEnglish", default place style "DE (modern in English)" and identical Principal/Witness sentences "<The English spelling is [L].><[M].>" When I have a tag's place with both an old and modern name (a birth tag for example), I change the individuals birth tag's selected place style to "German Old" and enter only the location place information relative to the time period of the event. The exact data from the source is recorded in the source citation/footnote. I then optionally add a tag "PlaceModernDeGerman" with only the location fields populated, the sort date only (to position the sentence in the narrative), and an optional memo if additional clarification or historical note is desired. I then optionally add a tag "PlaceModernDeEnglish" in a similar manner. If the individual spent their whole life in this one location/town, I only include these two tags once, typically after the birth tag, so the information is not repeated a dozen times in a narrative report. Plus, I could totally exclude all these place tags from reports if desired. If the person has tag events in various locations, I can repeat this process for each location as appropriate. In special cases, I could condense the place tags to identify only component that changed, such as the country or state/country. This approach allows the place's start and end dates feature in the master place list to be utilized (I hope). For places without these multiple names, I just enter locations using the "U.S. Standard Place". I repeat the creation of new tags for each language of interest. The DE in the names above would be replaced with the appropriate country 2-letter ISO abbreviation. I also created a new location place style "US Old" and a new tag "PlaceModernUS" using the "U.S. Standard Place" style. I will use the "US Old" place style for tags with locations in territories and counties that have been renamed, followed by the optional PlaceModernUS" tag. Obviously, the "in English" place style and tag are not needed here. The only flaws I see are: - There is no direct link between the old and modern names, or foreign language and English names, the best I can come up with is using identical LatLong entry and a place's comment field in the master place list for common places. A manual process bound to be applied inconsistently over time. - If I have a lot of individuals in a specific city, I will have to create PlaceModernXXLanguage tags for each person which may be identical except for the sort date. Because of the sort date, the same tag with witnesses cannot be re-used. - I have to manually verify I have consistently applied this approach for all location through the entire database, but I already have that issue in a lot of other situations, so whats a few more ... (as a software engineer, this makes me cringe ) I hope this will work to meet my needs. Any potential pitfalls I have missed?

Hello, If I use the name of a place at the time of the event, which differs from the modern political name, will I have problems with the various place look-up buttons or external programs such as AniMap, Map My Family Tree, etc? Likewise, does it matter if I use the English spelling or the spelling the native language? What I am trying to do ... avoid changing to a consistent convention in a thousand places and find out I did it wrong! I am trying to clean up my database place names to be consistent. For some places I have multiple variants, the modern "political" place name in both the English and German spellings, and the old name (at the time of the event) in both the English and German spellings, and in a few cases, some mixture of the old and new names in both languages. Of course, this repeats for other languages/countries as well. And then there is that whole changing county names in the US, but I digress. My preference is to use the name at the time of the event in the native language, after reading Getting the Most Out of TMG. I am still deciding on how to convey the modern or English name. First I was considering using the memo field somehow, or more likely creating additional tags for each tag group like BirthModernPlace and BirthEnglishPlace. But then I read a post on the forum that caught my attention, about adding a non-person with the alternate spellings, creating roles for events with conflicting names, and adding the associated persons as witnesses using this role. I think that will control how often it prints. I don't want a narrative of a person to repeat a phrase like "Rhede, Westfalen, whose modern name is Rhede, Nord Rhine-Westfalen, Deutschland, whose English spelling is Rhede, North Rhine-Westphalia, Germany" for every tag event for a person born, raised, lived, died and was buried in the same town. Place names always get me wrapped around the axle. I know this topic is probably only second to censuses for opinions, but I would gladly read about any suggestions, advice, experiences or warnings. Thanks

I am not familiar with the TMG Chat. Could you direct me to a link I can get more info, or provide a brief overview, please?

I don't believe you can do this for Witnesses. Even for Principals I don't think it will do what you want. My notes show that a leading ‘-’ in the Principal’s ID number marks this name as excluded data to not display in the Person View on the tag when the “other” principal is the focus if “Preferences>Tag Box>Show excluded data” is not set, but does not exclude the name from still being output in some reports. When I put a dash before the ID# for Principals, that person is then hidden (omitted) from the Individual Narrative reports I generate (what I wanted, a neat feature, even if unintended). When I try to do this with ID# for Witnesses, it doesn't work because the dash is never saved, although you would not know that unless you re-open the window to verify. Instead, you would assume it was saved since you can enter it without an error message/action and then OK/save without complaint from TMG. I re-verified this behavior to be certain (using v7.03 on a Vista PC). This is why I think it is a bug, it should either complain about the dash if not allowed, or preferably IMO behave like the Primary ID and allow the hiding of Witness IDs. I use non-persons all the time. The simple way I have found to exclude them from reports is by use of a flag, which I have created called PSEUDO. Its default value is set to 'N' for all "real" people and to some other value to reflect the "kind" of pseudo person. I then filter all reports to only include people with the value 'N'. I think this may get what you want. Let me know if you still have problems. Hope this gives you ideas. First, using the flag to identify non-persons is a good idea. I have just implemented it, much better approach than what I was doing, Thanks. But the flag does not solve my problem if I use [WO]. The flag with filters lets me easily eliminate non-persons from the group of people reports are generated for, but the non-persons still show up in the sentences/data for an individual's narrative if the non-person is a witness for that narrative's primary subject. I see several inelegant and/or time consuming partial solutions if this bug/feature is not implemented the way I would like. Do you have any more suggestions or feedback? Again, Thank you for your prompt response. That is one of the big reasons why I switched to TMG (the others being its sources management and program/report customizations).

v7.03 Hello, When I enter a dash '-' before the ID# in the Edit Witness window to hide that witness i.e. '-1234', it accepts the dash, but when I save 'OK' and later return to the Edit Witness window for that same witness, the dash is gone i.e. '1234'. When I enter a dash before the ID# of P1 or P2 of a Tag Entry window, it is preserved. Here is the task I am trying to accomplish. I have created TMG non-persons such as (Cemetery), (Census), (Church), (Hospital), etc. I learned this trick from the various online TMG tips. I use these non-persons for research/tracking purposes only, not wanting them to show up in reports for family. I then created appropraite Roles in the tags for Births, Marriages, Deaths, Burrials, Censuses, etc. When entering a tag's wintesses on the Tag Entry window I add a withness with the Role for the non-person and associated ID, i.e. a Burial tag would include roles for pall-bearers, celbrant, etc, and a CEMETERY role witness with the ID# '1234' of a non-person such as Cavalry Cemetery in Anytown, USA. For consistency I use the witness ID instead of the principal ID because in the case of the Marriage tag, both principals are used, so the witness ID is the only option. Likewise the birth of twins, etc. The Report I use most frequently is the Individual Narrative. I have some rather complex tags defined with many roles and sentence structures, especailly for Censuses. If one of the Sentence structures includes the Other Witnesses [WO] placeholder as [W] was enumerated in the 1880 Census ... blah blah blah. <Other household residents include [WO].> , my Census non-person is getting listed with all the other real-persons witnesses. When I set this up the roles for these tags and the use of non-persons, my plan was to hide the non-persons using a '-1234' in the ID field. But it appears to only work for principals, not witnesses. Is this a bug, or am I doing something wrong. Thanks.

Similar to any sentence you where you would use a [A], [AO], [A1], [A2], [AE], [AOE], [A1E], [A2E], [RA:role] or [RE:role] variable, let the user use the appropriate [AA] or [RAA:role]. - If complete dates are available, [AA] would works identical to [A]. - When a date only has a year component, display the approximate age, using a similar format already used in an individual's Detail Window Age column, e.g. ~31, or >=31. In these situation, [A] does not generate an age. Note: the situation with age ranges generating the average age still exists (see newsletter), but the user has more options on how to deal with this, like a unique sentence structure using [A], and more importantly, existing users NOT using the new [AA] feature are not impacted. Because of the existing syntax convention with roles using using [RE:role] instead of [RAE:role], [RAA:role] might be confusing and using a single letter (other than 'A' which is already in use) might be appropriate, but I have not been privy to the TMG software/user interface design team roadmap, so whatever syntax seems logical to them would work. An example: A witness sentence for the a Death tag with a role wSon1: "<[D]> <[RAA:wSon1],> [W] survived the death of his< [AA] year old> father [P] <[WM]>" to produce a witness sentence like: "In 1863 at age ~14, John Q. Public survived the death of his ~91 year old father Jack Public." using existing [A] age variable I get. "In 1863 John Q. Public survived the death of his father John Q. Public." Possible tags: The tags I see it being used with most are Birth and Death tags, possibly Marriage tags, in the Individual Narrative reports. But each user could have their own uses for various tags since TMG is so flexible to user customizations. If a user defines a lot of specific roles (like I do to circumvent the "feature" where [W] is desired to be one person, but [RA:role] may print ages for 10 people, but that's another issue ), then the [RAA:specific-role] could be used in-place of [RA:specific-role] to show the age of [W], since there is no [WA] or [WAE] variable (another new feature that would be nice). What would really be nice is some new variables similar to [PAR] to identify siblings, children, spouse, but I have not yet thought out the the details of that, but making all these witness links for family members takes a lot of time, and I know the TMG s/w should have the potential to gather this data automatically. Is there an obvious simple way to do this I've missed? I have a family member that has requested narratives that show a person's age (principal or witness) at the time of an event, especially for witnesses with multiple specific roles defined for each witness in birth and death tags. She would rather know someone was approximately 31 rather than have no information and have to break her line of though on the circumstances and context to find the appropriate dates and do the math with each sentence. I agree. As a new TMG user but experienced professional s/w programmer, there are lots of improvements to the rules I would make to the way variables for Principal and Witness roles are implemented & behave in sentences, but I think the entire concept is a great idea. But as a programmer, I also understand how features evolve, backwards compatability must be maintained, deadlines met, and with hind-sight alternate design decisions to user interfaces might have been made, and obvious changes cannot be made without pissing off your entire user community. This addition seemed to be a reasonable compromise between the user interface changes I would like to see versus a non-trivial UI redesign I would really like to see.

I would like to see approximate dates produced in sentence structures when I have an individual for whom I only have a year for birth and death dates. Per 22 August 2005, Issue 2005, Number 10, I see in TMG v6.02 approximate dates were printed for <[A]> but removed in v6.03, and which explained the pros, cons and reasoning, link . I might propose an alternate approach. Add an Age Approximate [AA] variable, similar to the way the [A] Age variable already has a [AE] Age Exact variant. Then the TMG user can decide if they want to use the less accurate age at format, without impacting existing users. I'm a new user, convert from FTM, and first post, I hope this is where to make product update suggestions. Tx for your time