Feature Request: Allow sources to auto create titles

I switched over to Rootmagic from FamilyHistorian because of all the restrictions placed on how you use the software. Being a lumper, having only one citation that is shared between events is one reason I came over. The other was being not allow to setup the templates the way I want. But FH has one feature with it’s source templates that I would love to see, The ability to have source and citation fields in the Title box that auto populate it. An example would be:

[CensusID], [Location:Reversed], [Person of interest]

This would save a lot to typing for us handicapped people.

1 Like

Confirming request has been reported to development.

This indeed would be an excellent enhancement. This feature for a template for the the initial Source names in RM has been asked for before - perhaps not decades ago, but at least many years ago. It may seems strange to say so, but I think the same feature is also needed for Citation names.

The reason that the request for the same feature for Citation names might seem a little strange is that in a sense the feature already exists for Citation names. Namely, RM does auto-populate the Citation name when a new citation is created. However, when RM auto-populates the Citation name, the user has no control over the name that is generated automatically. There really needs to be a template sentence for the initial Citation name. I say “initial Source name” and “initial Citation name” because the user obviously needs to be able to type over the names for further customization.

In my move from RM7 to RM9, one of the most difficult problems has been to come up with a good way to generate source names and to override RM’s default citation names. It has been harder to deal with the source names than the citation names because panels where you can edit Source fields in the Edit Person screen keep closing on me, just when I most need them to remain open. RM7 didn’t have Citation names. But for Source names, it was much easier for me to create the desired Source name than it is in RM9. That’s because in RM7 I could fill in the source template fields and then copy and paste pieces of the footnote sentence into the Source name. The mechanical process of doing the same thing is very difficult in RM9. But a template sentence for the Source name and for the Citation name would make entering Source names and Citation names into RM9 much easier.


I fully support this request. Like you, I struggle with the way FH handles shared citations. It is the reason I am back working with RM despite all of the other features that I like in FH (including this enhancement you are requesting).

I talked with FH tech support and was told since FH stores its data in a strict gedcom format that they wouldn’t be able to have a true shared citations. Which is funny, since if it was a strict gedcom format then why do they have an export to gedcom command.

This issue actually affects RM as well, although RM calls the feature reusing citations rather than sharing citations. I sort of think that “sharing citations” is a better description than “reusing citations”, but it’s the same feature either way.

The RM database is an actual database rather than being GEDCOM. That’s why RM can support reusing citations and FH cannot. But doing a GEDCOM export from RM or doing a drag and drop in RM has the practical effect of unsharing citations in the GEDCOM because GEDCOM doesn’t support shared citations. And remember that RM’s drag and drop feature uses GEDCOM as its transport mechanism.

If the data is imported back into RM (and by definition, it is imported back into RM when there is a drag and drop), the citations remain unshared in RM at that point. They can be re-shared by using the Sources => 3 Dots => Merge All Duplicate Citations tool. However, the tool doesn’t not take differences in media files or WebLinks into account when it is deciding which citations to merge.

True, I would consider this a shortcoming in the GEDCOM spec, but that is another discussion.

I have never understood the virtue of using “strict gedcom format” (which is, in my opinion, a data communications protocol) to store and manage data. There are much better DBMS solutions for that. Even so, there are programmatic ways to handle that, even if you want to maintain a “strict gedcom format”, but it appears they have chosen not to invest in that. This is something that I believe RM got right.