gramps

Josip,

> Hi,
> 
> KinshipReport works with strings returned from 
> get_plural_relationship_string() in
> RelationshipCalculator.
> Can it be extended to work with tuples of string instead
> just string, so 
> "spouses of %s" type of concatenation can be avoided.
> If anyone care to check http://www.gramps-project.org/bugs/view.php?id=2384

I see that your patch would technically solve the problem. But I'm not too excited about a function that sometimes returns a single value and some times returns two. This forces everyone who uses the function to check the return type.

I suggest the following solution:
Let's add a parameter to the get_plural_relationship_string so that it takes three parameters:
  Ga - The number of generations between the main person and the 
        common ancestor.
  Gb - The number of generations between the group of people and the
        common ancestor
  spouse - (new) whether the group is related to the person, or the
        person's spouse.

So for example, calling:
   get_plural_relationship_string( 1, 1, False)
would return "Siblings"

but calling: 
   get_plural_relationship_string( 1, 1, True)
would return "Spouses of Siblings"

If this change will work for you, I can probably make it for you in the next couple of days.

~Brian

P.S. I wonder if for some languages it would also help to know the gender of the main person. If anyone ever asks for that, we can add it later.

Benny Malengier wrote:
> 
> For my research seeing the changes that will be done before having
> them applied is also a must.
> Several tools already follow this approach. I know I can first backup,
> ...., but I find that too cumbersome.
> 

To give a feedback as a user: I would never use such a tool that alters my
data. I can identify all I need using the filters and edit the found entries
by hand. In my opinion it would be more useful to enhance the relationship
calculator (and the display in the status line) to show married
relationships. So if I select the wife of my uncle it should show "Aunt (by
marriage)" and not "not related".

Heinz

-- 
View this message in context: http://old.nabble.com/Re%3A-Probably-alive-tp27046516p27079061.html
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.

Hi,

2010/1/8 derHeinzi <heinzbrinker@...>:

> To give a feedback as a user: I would never use such a tool that alters my
> data.

This is why it is a good thing it is a Tool, and not something that is
part of the main dialogs. That way people who do not want a tool that
calculates estimated dates of events can simply not use it al all,
while others who do want such a tool (like me) know where to find it
and use it exactly because it does what it says it does.... which is
why one of my previous comments hinted that there are several
different issues here, but one which I would oppose would be to change
the CED tool to make it more in line with the (legitimate) desires of
users who do not want to have batch changes made on their data. This
would be IMO *another* different tool, since removing this ability
would destroy the reason why *I* use it.

Or, as said above, some kind of configuration for the tool to make it
behave in different ways, on of which being more or less the way it
works now in what regards the actual adding of the events.

Regards,

Frederico

> to enhance the relationship calculator (and the display in the status line) to show married relationships. So if I select the wife of my uncle it should show "Aunt (by marriage)" and not "not related".

Maybe one needs to add a rule on your localized Relationship calculator 
? Does main english calculator returns something ?

> To give a feedback as a user: I would never use such a tool that alters my data.

Maybe by providing dialogs like :
http://www.gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Tools#Find_Possible_Duplicate_People...
http://www.gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Tools#Extract_Information_from_Names
http://www.gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Tools#Fix_Capitalization_of_Family_Names...
http://www.gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Tools#Rename_Event_Types
or
http://www.gramps-project.org/wiki/index.php?title=Gramps_3.1_Wiki_Manual_-_Tools#Compare_Individual_Events...
(which is not a batch modification tool, just for illustrate)

So, Gramps does not need to warn the user anymore ?
He makes the choice modify data or not and he knows what has been done.


Jérôme


derHeinzi a écrit :
> 
> 
> Benny Malengier wrote:
>> For my research seeing the changes that will be done before having
>> them applied is also a must.
>> Several tools already follow this approach. I know I can first backup,
>> ...., but I find that too cumbersome.
>>
> 
> To give a feedback as a user: I would never use such a tool that alters my
> data. I can identify all I need using the filters and edit the found entries
> by hand. In my opinion it would be more useful to enhance the relationship
> calculator (and the display in the status line) to show married
> relationships. So if I select the wife of my uncle it should show "Aunt (by
> marriage)" and not "not related".
> 
> Heinz
>

Heinz and Frederico, I appreciate both of these points of view, and have a
prototype that should be ready for testing in the next few days. I believe
that it can be used as both a "filter" + report, or as a batch change tool.
First, it goes through the data and finds people for which the old
probably_alive function would have had to guess their status. The tool gives
a summary of the evidence for their birth/death, including how the person is
related to the evidence. You can visit each of these people by clicking on
them, if you wanted to manually add or edit their information. If you want
to go further, you can then select only those people you wish to
automatically add events to. Of course, you will see exactly what it will
do, before it does it.

I would suggest that we can have an option of using the old probably_alive
for use in filters, but it is incomplete and complex. Rather than having
this expensive, recursive algorithm guess, I much prefer using this tool to
at least know what the algorithm is deducing and how. Then you can manually
decide if that is correct, and if not add events to make it more correct.
Even better, you can apply the deduction to make the data explicit.

I very much appreciate the fact that we are using the official Birth and
Death Events to store this information, and some would feel that this is an
improper use of the official events. We could store this in a secondary
place, but then we may have conflicting information. We could ignore dates
on export that were "calculated estimated" as that is an invalid GEDCOM
combination anyway. That way the dates would not go beyond your working
Gramps. Or we could also mark these calculated estimated events as
private...

-Doug

On Fri, Jan 8, 2010 at 12:14 PM, Frederico Muñoz <fsmunoz@...> wrote:

> Hi,
>
> 2010/1/8 derHeinzi <heinzbrinker@...>:
>
> > To give a feedback as a user: I would never use such a tool that alters
> my
> > data.
>
> This is why it is a good thing it is a Tool, and not something that is
> part of the main dialogs. That way people who do not want a tool that
> calculates estimated dates of events can simply not use it al all,
> while others who do want such a tool (like me) know where to find it
> and use it exactly because it does what it says it does.... which is
> why one of my previous comments hinted that there are several
> different issues here, but one which I would oppose would be to change
> the CED tool to make it more in line with the (legitimate) desires of
> users who do not want to have batch changes made on their data. This
> would be IMO *another* different tool, since removing this ability
> would destroy the reason why *I* use it.
>
> Or, as said above, some kind of configuration for the tool to make it
> behave in different ways, on of which being more or less the way it
> works now in what regards the actual adding of the events.
>
> Regards,
>
> Frederico
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Gramps-devel mailing list
> Gramps-devel@...
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>

2010/1/8 Peter Landgren <peter.talken@...>:
> So I should commit:
>
> src/TransUtils.py
> src/BasicUtils/_NameDisplay.py
> src/gen/lib/grampstype.py
> as changed by Benny's path
> and
> src/gui/views/treemodels/peoplemodel.py

yes, and then be on the lookout for issues in reports and such, as
some places might have issues that unicode is now there instead of
str.

My main fear is that some strings in the translation files might have
issues when converted to unicode if the po file was in some strange
encoding. I think we should enforce that po files are written in
Ascii, or in utf-8, and nothing else. But I think that will be the
case at the moment.

Benny
> /Peter
>
>
>> 2010/1/6 Brian Matherly <brian@...>:
>> > Benny,
>> >
>> >> Brian,
>> >>
>> >> there one issue in this patch:
>> >>
>> >> --- src/gen/lib/grampstype.py    (revision
>> >> 13976)
>> >> +++ src/gen/lib/grampstype.py    (working
>> >> copy)
>> >> @@ -30,7 +30,7 @@
>> >>  # Python modules
>> >>  #
>> >>
>> >> #-----------------------------------------------------------------------
>> >>- -from gettext import gettext as _
>> >> +from TransUtils import gettext as _
>> >>  _UNKNOWN = _('Unknown')
>> >>
>> >>
>> >> This is a mixing outside of src/gen.
>> >> Where would you move TransUtils?
>> >> Alternative is to write in gen.lib instead of
>> >>
>> >> from gettext import gettext as _
>> >>
>> >> do
>> >>
>> >> from gettext import gettext
>> >> def _(msgid):
>> >>    return unicode(gettext(msgid))
>> >>
>> >> But doing that in one place, TransUtils, is to be preferred
>> >> I think.
>> >>
>> >> Benny
>> >>
>> >> 2010/1/5 Benny Malengier <benny.malengier@...>:
>> >> > Peter,
>> >> >
>> >> > attachment patch makes sure using TransUtils always
>> >>
>> >> returns unicode,
>> >>
>> >> > so the conversion must not be written later on in
>> >>
>> >> every module.
>> >>
>> >> > For this, we only need at the top:
>> >> >
>> >> > from TransUtils import gettext as _
>> >> >
>> >> > Could you try this, add in the models the import from
>> >>
>> >> TransUtils, and
>> >>
>> >> > remove the extra unicode call in the models of
>> >>
>> >> translated strings, as
>> >>
>> >> > TransUtils always returns a unicode object now?
>> >> >
>> >> > Doing it like this might be usefull, as python 3.0 is
>> >>
>> >> all unicode, so
>> >>
>> >> > ugettext in the translation class is no longer
>> >>
>> >> present.
>> >>
>> >> > Benny
>> >
>> > Thanks for being sensitive to the GEP008 effort!
>> >
>> > We actually already do this in date.py. So it isn't much of a deviation.
>> > My plan is for TransUtils.py to be moved into src/gen. But it will
>> > probably be renamed and some parts may be moved out.
>> >
>> > For now, I'm ok with using TransUtils in this situation.
>> >
>> > However, I think it would be easier to just change:
>> >   from gettext import gettext as _
>> > to:
>> >   from gettext import ugettext as _
>> >
>> > What I like about that is that when we switch to support Python 3, it is
>> > easy to "find and replace" to put all ugettext  back to gettext. However,
>> > if you use TransUtils, it will probably remain residual long after we
>> > have switched to Python 3.
>>
>> As I understood the documentation, ugettext is only available in the
>> class based gettext api, not in the default functions we are using in
>> Gramps.
>> See http://docs.python.org/library/gettext.html
>> So using ugettext means doing translation differently, which you have
>> some experience with, that is why I wrote earlier in this thread:
>> "Perhaps if Brian has full understanding of the class based translation
>> api, we can change to that completely" :-)
>>
>> I would have to do some study to change our translation to that, but I
>> think the present system still has some translation issues in glade
>> (as Peter is already complaining about for a long time) which are not
>> fixed (first I have other irons in the fire)
>>
>> Benny
>>
>> > I'm OK with either way you go.
>> >
>> > ~Brian
>> >
>> > -------------------------------------------------------------------------
>> >----- This SF.Net email is sponsored by the Verizon Developer Community
>> > Take advantage of Verizon's best-in-class app development support A
>> > streamlined, 14 day to market process makes app distribution fast and
>> > easy Join now and get one step closer to millions of Verizon customers
>> > http://p.sf.net/sfu/verizon-dev2dev
>> > _______________________________________________
>> > Gramps-devel mailing list
>> > Gramps-devel@...
>> > https://lists.sourceforge.net/lists/listinfo/gramps-devel
>>
>> ---------------------------------------------------------------------------
>>--- This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and
>> easy Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Gramps-devel mailing list
>> Gramps-devel@...
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
> --
> Peter Landgren
> Talken Hagen
> 671 94  BRUNSKOG
> 0570-530 21
> 070-345 0964
> peter.talken@...
> Skype: pgl4820.2
>
>

Committed.

I checked the po files. All 28 have have:
 "Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n
set.

/Peter


> 2010/1/8 Peter Landgren <peter.talken@...>:
> > So I should commit:
> >
> > src/TransUtils.py
> > src/BasicUtils/_NameDisplay.py
> > src/gen/lib/grampstype.py
> > as changed by Benny's path
> > and
> > src/gui/views/treemodels/peoplemodel.py
>
> yes, and then be on the lookout for issues in reports and such, as
> some places might have issues that unicode is now there instead of
> str.
>
> My main fear is that some strings in the translation files might have
> issues when converted to unicode if the po file was in some strange
> encoding. I think we should enforce that po files are written in
> Ascii, or in utf-8, and nothing else. But I think that will be the
> case at the moment.
>
> Benny
>
> > /Peter
> >
> >> 2010/1/6 Brian Matherly <brian@...>:
> >> > Benny,
> >> >
> >> >> Brian,
> >> >>
> >> >> there one issue in this patch:
> >> >>
> >> >> --- src/gen/lib/grampstype.py    (revision
> >> >> 13976)
> >> >> +++ src/gen/lib/grampstype.py    (working
> >> >> copy)
> >> >> @@ -30,7 +30,7 @@
> >> >>  # Python modules
> >> >>  #
> >> >>
> >> >> #--------------------------------------------------------------------
> >> >>--- - -from gettext import gettext as _
> >> >> +from TransUtils import gettext as _
> >> >>  _UNKNOWN = _('Unknown')
> >> >>
> >> >>
> >> >> This is a mixing outside of src/gen.
> >> >> Where would you move TransUtils?
> >> >> Alternative is to write in gen.lib instead of
> >> >>
> >> >> from gettext import gettext as _
> >> >>
> >> >> do
> >> >>
> >> >> from gettext import gettext
> >> >> def _(msgid):
> >> >>    return unicode(gettext(msgid))
> >> >>
> >> >> But doing that in one place, TransUtils, is to be preferred
> >> >> I think.
> >> >>
> >> >> Benny
> >> >>
> >> >> 2010/1/5 Benny Malengier <benny.malengier@...>:
> >> >> > Peter,
> >> >> >
> >> >> > attachment patch makes sure using TransUtils always
> >> >>
> >> >> returns unicode,
> >> >>
> >> >> > so the conversion must not be written later on in
> >> >>
> >> >> every module.
> >> >>
> >> >> > For this, we only need at the top:
> >> >> >
> >> >> > from TransUtils import gettext as _
> >> >> >
> >> >> > Could you try this, add in the models the import from
> >> >>
> >> >> TransUtils, and
> >> >>
> >> >> > remove the extra unicode call in the models of
> >> >>
> >> >> translated strings, as
> >> >>
> >> >> > TransUtils always returns a unicode object now?
> >> >> >
> >> >> > Doing it like this might be usefull, as python 3.0 is
> >> >>
> >> >> all unicode, so
> >> >>
> >> >> > ugettext in the translation class is no longer
> >> >>
> >> >> present.
> >> >>
> >> >> > Benny
> >> >
> >> > Thanks for being sensitive to the GEP008 effort!
> >> >
> >> > We actually already do this in date.py. So it isn't much of a
> >> > deviation. My plan is for TransUtils.py to be moved into src/gen. But
> >> > it will probably be renamed and some parts may be moved out.
> >> >
> >> > For now, I'm ok with using TransUtils in this situation.
> >> >
> >> > However, I think it would be easier to just change:
> >> >   from gettext import gettext as _
> >> > to:
> >> >   from gettext import ugettext as _
> >> >
> >> > What I like about that is that when we switch to support Python 3, it
> >> > is easy to "find and replace" to put all ugettext  back to gettext.
> >> > However, if you use TransUtils, it will probably remain residual long
> >> > after we have switched to Python 3.
> >>
> >> As I understood the documentation, ugettext is only available in the
> >> class based gettext api, not in the default functions we are using in
> >> Gramps.
> >> See http://docs.python.org/library/gettext.html
> >> So using ugettext means doing translation differently, which you have
> >> some experience with, that is why I wrote earlier in this thread:
> >> "Perhaps if Brian has full understanding of the class based translation
> >> api, we can change to that completely" :-)
> >>
> >> I would have to do some study to change our translation to that, but I
> >> think the present system still has some translation issues in glade
> >> (as Peter is already complaining about for a long time) which are not
> >> fixed (first I have other irons in the fire)
> >>
> >> Benny
> >>
> >> > I'm OK with either way you go.
> >> >
> >> > ~Brian