Hello,
For the Death fact, I use the Description field to add time of the death and other details that are not Notes ones.
This Description syncs as Value to Ancestry, and it’s perfect
I would like to do the same with the Birth fact. When we sync it to Ancestry, we also have this Value field
But I don’t see any corresponding filed, like Description, in the Birth fact form???
For now, I use the Notes field but it’s not fantastic
Many thanks
Open fact type list ( under 3 dots next to wrench), click on Birth then hit edit–put a check mark in USE description field ( left side) – then click on PRINCIPAL and hit edit role–on that screen, you need to add <[desc]> to the fact sentence such as
[person] was born < [Date]> <, [PlaceDetails]> <, [Place]> <[desc]>.
hit okay several times to get back out of it…
you can add the description anywhere you want actually-- just have to get the spacing right-- play around with it…
don’t know if it will show up in the value field for Ancestry – just have to try it…
YEEESSSS !!! You are the best !
Until now, I was afraid of modifying anything in the definition of the facts…
When TreeShare will have the feature for selecting which Sources, Media and Notes we want to keep/delete on Ancestry side, il will be very great. For example in my screenshot, I don’t need any more the Notes in Ancestry.
Many thanks for your great help
I also don’t know if it will show up in the value field for Ancestry after you have made the changes to the Birth fact. As nkess suggests, just try it. I have a suspicion that it will “just work”, but I don’t know for sure without trying it.
More generally, the Description field is enabled by default for some RM fact types and not for others. A rather naive question I have always had is why not enable the Description field by default for all fact types. I guess the answer is that there would seem to be no reason to enable it if there is no [Desc] variable in the default sentence for the fact type. And if you decide to include the [Desc] variable in the sentence for the fact type, you can enable the Description field at the same time. That is the suggestion from nkess for your Birth fact - enable the Description field and also add the [Desc] variable to the sentence.
But I think the situation is actually a little more subtle and nuanced than that. For example, I have fact types that I have defined for which I have enabled the Date field and for which I have not included the [Date] variable in my sentence. I enter the date so I can see it in the Edit Person screen and so it is in the correct order. But for whatever reason I don’t want or need the date to appear in reports. And yes I know I could accomplish somewhat the same thing with the Sort Date field as far as getting the fact into the correct order.
But I also have at least one fact type where I have enabled the Description field and for which I have not included the [Desc] variable in the sentence template. I manage to get the same information into reports in a different way. But enabling the Description field for that fact and entering data into the Description field gives me a lot of tools to work with even though I don’t print the field. For example, I can search on the Description field for that fact, or make groups or color code based on the Description field. I can make the Description field for that fact into a column in People List View or in Custom Reports. So for all those reasons, I think it would probably be a good idea to enable the Description field by default for all fact types, even for fact types where there is no [Desc] variable in the sentence.
But since the Description field is not always enabled by default, you can always enable it yourself when it’s needed.
Be not afraid. The definitions of the facts are there to be modified. For example, you can change the sentences to read better or differently for your purposes.
Here are some Facts that do NOT have Description enabled.
Bar/Bas Mitzvah
Blessing
Burial
Divorce
Immigration
have wondered the same things before and what if/when you toggle off/on (Desc field) – does it loose previous info or just no longer displays it (haven’t tried testing)
It just doesn’t display the Description field if the option is turned off. No data is lost by turning the option off. If you turn the option back on, the data is still there.
Thanks – that is what I suspected but wanted to be sure before I suggested incorrectly
As to why the Description tield is not enabled by default, it’s probably due to the GEDCOM specs which RM does a middling job of honouring. The BIRTh object has no such field. Consequently, the values could be lost when exported to other programs that adhere more closely. To reduce that risk, the field is disabled by default to preclude data entry. However, it still can import data to the database but it remains hidden until enabled.
Add and modify fact types.
If I use treeshare to fetch complete family tree data from ancestry, why do I have to laboriously edit all fact types afterwards?
Is there no way to show everything that comes from ancestry in the facts?
One should be able to set the facts for all future imports to Yes/Yes/Yes in advance.
If you mean the Description - go thru the Facts and mark to display.
again and again and again and don’t forget to do it again for every complete Import from ancestry ?!
This isn’t clear what you are doing.
In RM when you enable the Desc, it doesn’t change.
Do a screenshot to show what you are doing.
They want RM to force every fact to have the description field enabled. The problem with us changing the default settings is it will effect the sentence templates for all existing databases. That is partly why Import Lists will not change any of the default facts in the database. If you want the birth fact to always have the description field enabled then you need to enable it on every database created. Make sure to add < [Desc]> to the sentence template.
As you have realised, every new RM database starts with the default set of Fact Types and Roles et al. Using SQLite, it is possible to import the custom settings for same from another database to a new database. See:
https://sqlitetoolsforrootsmagic.com/database-copy-master-lists-to-shell/
Now that script is not compatible with RM10 and maybe not fully with anything since RM6 but strip out all but the operations on the FactTypeTable and RoleTable and it would probably address your problem as a workaround to the labour and error-prone intensive editing you would have to do through RM itself.
Because you don’t get to access the empty RM database shell when you do a TreeShare download to a new database, you would have to run this procedure on your new database before you do any manual editing of Fact Types and Roles else they will be overwritten.
I have not tried out my suggestion so there may be a gotcha! that I haven’t thought of.
You could create a new blank database and adjust all the Fact Types as you want them. Just don’t add anyone to the database, instead use it as a blank template database. Copy the database and then import the Ancestry tree using TreeShare. Make a backup of your template database is case you mess up and add someone to it by mistake. Once someone has been added to the database it won’t import an Ancestry tree.
I maintain and expand family trees at ancestry.com.
I was very happy when I found RootsMagic. With RM I can find errors (dates in text format, problems with place names, etc.). And I can get all the document images, which is great.
Unfortunately, I later found out that RootsMagic suppresses some information. Why?
Now I found out that the settings of the RM fact types are to blame for this. So you have to set all fact types to YES/YES/YES.
But if I want to get the family tree from ancestry completely new to RM, I have to use a new RM-file.
But then I have to set the fact types again and I must not forget that.
Why is there no default YES/YES/YES for all new RM-files? For the NON-GEDCOM-facts it works fine. But the suppression of information for GEDCOM facts is completely incomprehensible and frustrating for the user.
Translated with DeepL.com (free version)
The default features for Fact Types is a legacy from GEDCOM specs up to at least GEDCOM 5 and RM Inc’s strategies to comply while using a more general database structure. That resulted in the settings which determine whether the Date, Description and Place are supported in the User Interface (UI) because there are variations defined for different GEDCOM objects. The idea was to protect the user from entering data in a field that would violate the GEDCOM spec and might be lost when a RM export is imported into another program which does not recognise that exception. That answers the WHY it behaves the way it does but your issue raises the question if it is relevant given the shift of data exchange from GEDCOM to TreeShare - there may be many users of TreeShare who will seldom, if ever, export a GEDCOM.
That said, I’m unfamiliar with what fact types Ancestry exports for which RM’s defaults hide some of the information. It would be a trivial SQLite query that could enable the appropriate fields for these fact types. And, therefore, it should not be a major programming effort for such a control to be incorporated in the RM program.
Yes, but as I mentioned earlier there is a way to work smarter when you do that. Simply make a copy of a master blank database where you have already changed the fact types to support the description field. As long as you keep the master copy as a blank template you can copy it over and over again. You can skip making extra work for yourself that way. Open the copied database and then go to Publish, Ancestry TreeShare and import a new tree.
