Editing marriage dates
I wish that when there are multiple variations of the marriage date you could just edit one and have it be the one that shows up on the person page. If the correct/full date is there along with others, you have to delete all the not quite complete dates. Why do we have to jump thru hoops to correct or standardize the date rather than just change it like all other dates? Please make this easier and like all other date edits or else have the capability to indicate the correct one and have it be on the person page?
Answers
-
I, too, find this a bit annoying. As multiple records of a marriage are attached, duplicate marriage dates often get added. The source linker appears to recognize birth and death dates in a record as being the same as what is already in the person's record page, but not so for marriage dates. Perhaps this is due to the marriage being for a couple, not an individual?
Note that I'm not talking about a date that is different than what's already there, which can happen when a marriage bond date is indexed as the actual marriage date.
1 -
This issue doesn't seem to have be raised recently, but it has been many times in the past.
The fault partly lies with the source linker, the new version of which still allows for multiple marriage events to be carried across to the profile pages of the individuals concerned. Perhaps the problem does lie in the fact that a marriage event effects a couple, because once one of the other Vitals events (baptism, birth, baptism, death) has been entered on the profile page of an individual, a further event cannot be added - only modified if there is a difference in detail from the data on the source.
There have been general calls for a complete workover of the Couple Relationship section in Family Tree, but that is one part of the program for which improvement had been sadly neglected by the developers.
On the specific issue being raised here, I think most of us would be happy to continue seeing the multiple details, but are certainly not happy that the event with the earliest date (including if it just includes a year, rather than a full date) is programmed to always be placed on the profile page. For example, if I add a source that shows just "1858" for the date of marriage, that will replace the more detailed "3 March 1858" date that has already been inputted. As suggested, the only way to rectify this is to delete the other (less detailed items) that have been added.
One further problem is that sometimes (though less rarely nowadays) an "related" marriage event (e.g., banns or licence) has been indexed as if an actual marriage. This can cause the date of the banns / licence to replace the actual marriage ceremony date on the profile page, too. And, of course, all this is difficult to notice, because the finer detail in the Couple Relationship section is hidden from view when looking at the profile page(s).
@EricShelton - Sorry if I have repeated points you raised in your earlier response.
7 -
The fact that multiple marriage dates can be added by the source linker had nothing to do with the fact that a Marriage event is connected to a couple relationship (rather than an individual), not is it any problem with the source linker.
Family Tree has some conclusions which can only have one instance for a person or relationship. These include the main vital conclusions Birth, Christening, Death, Burial, as well as some others like Bar Mitzvah. There are other conclusions that can have multiple instances; these include Residence, Occupation, Military Service, and many others.
This explains why the source linker can only update a Birth conclusion from a source record when a person in Family Tree has an existing birth conclusion -- a Birth can only have one value. But the source linker will add a new Residence or Marriage event from a source record, because these conclusion types allow for multiple values.
That is the reason that multiple Marriage or Residence events can be added by the source linker. It's a necessary result of the fact that multiple values are allowed for those conclusion types.
2 -
Thank you for your response to my comments, particularly with regards to the ability to carry across the Marriage event not being connected to the fact it is connected to a couple relationship.
However, I stand by my main argument that this is one item that can cause a negative affect when carried across to profiles during the source linker process. It often causes perfectly detailed, accurate data being "automatically" removed from the profile page and replaced by detail that can be totally incorrect or - at best - far too vague to be of great use.
I have already provided examples above (concerning banns and licence records being indexed as "marriages") and add to this the fact that marriage registrations are now treated in the same way as the marriage ceremony itself. This causes totally misleading data to be carried across, especially as the register office (in England & Wales) is sometimes not even in the same county as where the marriage event actually took place. For example, if my ancestor's marriage took place in a parish in Yorkshire on 21 October 1853 the registration was likely to have been at Stockton in Durham. The consequence of this is that the correct detail of, say, "21 October 1853 Middlesbrough, Yorkshire" will be replaced on the profile page by the detail "1853 Stockton, Durham".
I have directly requested that we should not be able to carry such items across during the source linking process - well, at least for as long as the incorrect categorisation of a marriage registration is treated as an actual marriage event (ceremony).
Of course, this still does not address the main point of the original post that we should be able to edit / choose which item we want to be displayed on the profile page. It is perfectly reasonable, for example, for a user to want to display the event that took place in a church, rather than the event that took place in a register office, Two events (civil and religious) can be common practice in some countries. However, currently (as pointed out) this means one has to delete the "non-preferred" event if it has an earlier date than the event a user might wish to appear on the profile page.
Raising this issue is nothing new - there were threads on the former GetSatisfaction forum that expressed much the same views - so it is frustrating to many of us that the developers cannot come up with an enhancement to address the specific issue being raised by the OP, as well as making a long overdue attempt to improve the whole of the Couple Relationship section.
(N.B. - the example provided above is meant to be illustrative of a general situation, but not necessarily reflects the position affecting north Yorkshire events at that specific time period.)
3 -
I'd be highly in favor of two improvements. One long asked for and one more recently suggested:
- Expand the list of couple event types to include as many types of events as possible and even add a custom event type.
- Since there can be more than one couple event just as there can be more than one residence event, quit hiding them and show all couple events on the profile page just as all residences are shown.
As far as the Source Linker issue, it would be good to be able to edit the event type after the information is moved from left to right rather than being forced to accept an incorrect type and needing to edit that type later.
2 -
@BethAnn7 @Gordon Collett @Alan E. Brown I will attempt to send them to the proper person to review your comments. Hopefully, someone will respond soon.
0 -
Thank you for listing many of the challenges with marriage events and couple relationships. I agree with most of what you said.
Please note, however, that my previous post made no attempt to address all these issues. My only intent was to explain two points on which there seemed to be some confusion:
- Multiple marriage events are allowed per couple relationship (which is necessary, since a couple can be married more than once), and that is the reason that the source linker allows additional events to be added, rather than replacing values (as is the case with single-value events such as birth and death).
- The fact that a marriage event is connected to a relationship and not to an individual has nothing to do with the above behavior.
I had no intention of implying anything about all the other issues, simply because I didn't mention them in in my focused comment. I would love to see many of the improvements that you and others have suggested.
1
