Hi,
Let me try to make clear how I think it can be handled, following the
guidelines
of Brian and the bug report.
I do not like everything being of event type Marriage. This is just not
logical,
and users will not do this from themselves. I suggest to go the whole
line, and
have a default event for every relationship type.
So my proposition would be:
1/Try to do everything with the standard relationship types:
Married, Unmarried, Civil Union, Unknown
Are there relationships which are not of the above types? All religious
bindings are type married, all legal bindings of type civil union, people just
living together are Unmarried and people who are parents of the same child
without ever living together are Unmarried too. If you don't know it's unknown
2/Couple to for every type the event marking the start and the end of the
relationship A small tab in the preferences could in theory be made for this,
but I would think that once we decide here, this is not needed (or it
should be
that custom types are common in different countries)
I suggest:
rel type | event type start | event type stop | priority
--------------------------------------------------------------------
Married Marriage Divorce 1
Civil Union Civil Marriage (??) Annulment (???) 2
Unmarried Cohabitation (??) Split (???) 3
That is, I suggest here 4 new event types to indicate start and stop of a the
relationship type. Perhaps Alternate Marriage can be used for civil
union (??).
3/Use the description field to further distinguish between types of Marriages,
Civil Union, or unmarried. So in description: Buddhist coupling of Jane and
Joe, but event type Marriage, Or: Living together contract of Jane and
Joe, but
event type Civil Marriage
4/Adapt the report functions. On reports priority is used to know what
to print.
With the above, reports can be adapted (like bug #1121 patch):
No more:
'He married %(spouse)s on %(full_date)s in %(place)s%(endnotes)s.'
but instead :
'He %(reltype)s %(spouse)s on %(full_date)s in %(place)s%(endnotes)s.')
5/A tool can be made checking if the relationship type corresponds with the
events, eg type unmarried, but event Marriage would then be shown in the tool.
Does this cover what is needed for users?
It does for me I think. Let me take a real life example:
Jane and Joe family
Living together: 2000: event cohabitation
child 1 : 2001
Split : 2002: event Split
Living together: 2003: event cohabitation
child 2 : 2003
Civil Union: 2006 (may): event civil marriage
Marriage with a service ('rented priest'): 2006 (june) : event marriage,
description: religious garden ceremony of Jane and Joe
So the present relationship type would be married.
In report it would appear: "He married Jane on june 2006 in Berlare"
In detailed report, one could make
"He lived together with Jane from 2000 untill 2002. He lives together
with Jane
since 2003. He did a civil union with Jane on may 2006. He married Jane
on June
2006.
Benny
PS: clearly the english event types I suggest are not the best, I'm no native
speaker
Quoting Brian Matherly <brian@...>:
> All,
>
>> Second, make custom events. Eg, in Belgium we have 'Samenlevingscontract'
>> (Living together contract), which is legally different from a marriage.
>> However, do not make too much events, that looses meaning!
>> Eg, in most countries you have a civil marriage and a religious marriage
>> (boeddhist, muslim, ..., all with different names). The idea is the same
>> however, this is a marriage event in the meaning, and you should use the
>> description of the event to write eg 'civil marriage', not create a
>> new event
>> for this (in my opinion).
>
> This is probably an issue that we should come to an agreement on
> soon. There is a feature request here:
>
> http://bugs.gramps-project.org/view.php?id=1121
>
> This request suggests that we honor the relationship types as Benny
> describes, but it suggests that the EVENT should always be a
> "Marriage" event - not an event with a custom type.
>
> Please feel free to add your opinions on the issue tracker and come
> to an agreement.
>
> ~Brian
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Gramps-users mailing list
> Gramps-users@...
> https://lists.sourceforge.net/lists/listinfo/gramps-users
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
|