Feature Request Number: 14211
As outlined on the feature request, it would be useful if, as well as having divorced, annulled and married for relationship events/Civil Union, Married, Never Married, Unknown for Family Status, to have a status or event (perhaps both?) of Separated for couples that are still wed, but no longer live together (Event use case), or couples that were together, but are no longer (Family status use case)
It is present in other family tree software, such as Family Historian 7 and My Family Tree (Chronoplex) as examples.
The Relationship Type field in the Family Editor is a custom type field that has a Selector Combo Box. You can simply type âSeparatedâ in that box to add the new type.
Likewise, you can add custom Event types if there are legal filings to record.
I appreciate that as an option, and if not accepted I will be choosing that path, as I have done for other matter, but arenât custom types just empty tags so to speak. By that I mean that it wouldnât be exportable/readable outside of another Gramps file?
I was proposing something that could bring Gramps into alignment with other family tree softwares
Gramps typically exports tags that are compliant with the GEDCOM standard. And Separated is not one of the supported Relationship or Family Event types for GEDCOM 5.5.1 nor even for GEDCOM7 (see section 3.3.1.2 of The FamilySearch GEDCOM Specification)
The GEDCOM import tends to handle importing custom types by writing it into a Note.
What you are requesting is supporting custom tags in nonstandard dialects of GEDCOM. (Which is certainly possible but an bottomless quagmire.) Adapting to the right dialect is a pretty big challenge. (Although there are some interesting proposed âsnifferâ code changes for 6.2, the release for this coming Fall. With that code, dialect handling might be more viable as addon pluggins. So the feature request becomes more viable too.)
Thank you for providing the GEDCOM Spec. As had seen it applied in multiple softwares (did a wider check, and seems Heredis 2026 also has separated), I had made the assumption that it was an overlooked/not yet implemented GEDCOM 7 type.
makes me wonder how they do theirs. I can only say that My Family Tree they have it as both a RELATIONSHIP_STATUS element, and then separation which gets picked up as a custom event by Gramps when cross importing.
Please how that looks below after importing in (My Family Tree having added the UID, RELATINSHIP_STATUS, separation and CREA elements, the other 3 made in Gramps before I imported into My Family Tree to test)
Yes. All GEDCOM tags beginning with an underscore are non-standard (custom) types.
The problem is that GEDCOM is an aged, lossy, and limited format not meant for transferring genealogy data in a public or scientific manner. It was created as a clerical transfer format for the legacy LDS Ancestral File system, not as a common-use format for modern research.
This discussion about a âSeparatedâ status is a perfect illustration of why Gramps should not be shackled by this 40-year-old religious submission format. It doesnât matter if FamilySearch releases a minor âpatchâ every 10 or 20 years; their updates often make the format even less historically accurate and socially relevant. GEDCOM was never intended for the way we use it today; it only became a âstandardâ because commercial developers in the 80s failed to collaborate on proper social science or humanities standards.
While GEDCOM might have been âfineâ in the era of punch cards, it is woefully inadequate for the depth of data available today. Furthermore, limiting exports to the restrictive âlineage-linkedâ methodology creates unnecessary bottlenecks for evidence-based research.
In my view, the Gramps XML structure is already one of the best formats for digital humanities researchâshort of moving to pure Linked Data or Graph databases.
A software as inherently agnostic as Gramps should never limit its internal functions or data model to the constraints of GEDCOM. Support for GEDCOM in Gramps should be treated strictly as a âdata subset exportââa feature included only because it remains a ânecessary evilââaccompanied by a clear warning that data integrity will be lost when using this export format.
Nothing in Grampsâ internal logic or relationship handling should ever be defined or limited by GEDCOMâs lack of support for real-world historical data. We should prioritize the integrity of our internal model over the limitations of a legacy relic.
â
Note: Denne teksten er skrevet pÄ norsk, basert pÄ tidligere innlegg jeg har skrevet om GEDCOM i dette og andre fora, den er oversatt til engelsk og strukturert av Goggle AI for lesbarhet pÄ engelsk
