No Description Field in Birth fact?

There will be many users who have this problem.
Some have not noticed it yet, some others have noticed it and are frustrated.

@TomH besides any fact that you use description in, you have to go in and redo all your CUSTOMIZED FACTS-Ancestry will accept them and add them to the time line BUT without the customized sentence— BUT when you tree share, you lose the sentences for all your CUSTOMIZED FACTS BUT this only seems to happen when you tree share a NEW tree to RM-- as Renee says IF you import your fact list into the new database before the download, you are okay…

and of course you still lose all your shared facts on the new download as Ancestry does NOT accept shared facts…

Agreed. If a user has no interest in getting a narrative report from the database, then they need not be concerned with sentence templates. However, if they want the narrative, then they must ensure that they have an acceptable sentence template for every fact type and role in use. For those fact types for which they have enabled a field that is disabled by default, the default sentence template has to be edited to include the field.

The suggestion by @rzamor1 to create an empty ‘template database’ with all the desired customisation should be a viable labour saver after the effort involved in its creation. However, for sentence template editing, it is practically essential to have some data to work with to verify that one’s changes work as intended. This may require a parallel scratch database from/to which such changes are transferred and tested. Any subsequent changes to fact and role settings in the working database have to be copied back to the ‘template database’ for them to be propagated to the next empty database.

My suggestion of a function to copy Fact Type settings from database to database would avoid the need to create the empty ‘template database’, allowing the fact type and role definitions to evolve through generations without needing to keep it updated. That’s an old enhancement request that was partly answered when the Import Lists feature was added to RM7(?) and made more selective in RM10. But that feature only applied to custom fact types, not to the built-in ones. So that enhancement request remains only partly fulfilled and may not even be on the current list (@rzamor1 ?).

Meanwhile, the only choices for propagating any or all Fact Type and Role settings from database to database are:

  1. Manual duplication, one at a time through the User Interface in each new database
  2. Manual setup and update of a ‘template database’ file which is copied to start each new database.
  3. Outboard SQLite procedure(s) to copy them from one database to another, noting that the RM10 File > Import Data > Import Lists > Select File > Import Lists > Fact types > select fact type(s) may satisfy some users who are not looking to propagate customisations of the built-in fact types.

Confirming request is on the development list.

1 Like

Thank you!
This will also make it less of a problem for my heirs or descendants if they continue to work with RootsMagic.