From: Benny M. <ben...@gm...> - 2007-11-21 23:34:43
|
Hi, A call for localization of the rel_xx modules. I wrapped up the changes to the relationship module. I personally did new English, Dutch and Italian relationship module. This should give a good example for german and latin languages. If people want to adapt the other modules to the new calling methods, at the moment all is fresh in my mind, so I could give some help. The methods that needs localization: -/ get_single_relationship_string : the core module -/ get_sibling_relationship_string: only needed if English logic cannot be reused -/get_partner_relationship_string: normally not needed to translate. The gettext translation of English method should work ok in most languages -/get_plural_relationship_string: used in one tool. You find it in the Relationship.py module only at the moment. I'll adapt the wiki explanation in the following week. Important is that all rel_xx modules remove the get_relationship_distance(...) method. Note the test code in eg rel_it.py and rel_nl.py, which allows for easy checking the changes. Benny |
From: <rom...@ya...> - 2007-11-23 13:33:11
|
Benny, I try to improve custom sibling_relationship on rel_fr because we don't (really) use STEP and have words for mother/father/both side, something like that: def mother_birth(self, path): """ given a path to common ancestor. Return True if mother birth relations, False otherwise """ mother_birth = True for str in path: mother_birth = mother_birth and (str not in [self.REL_FAM_NONBIRTH, self.REL_FATHER_NOTBIRTH]) return mother_birth def father_birth(self, path): """ given a path to common ancestor. Return True if father birth relations, False otherwise """ father_birth = True for str in path: father_birth = father_birth and (str not in [self.REL_FAM_NONBIRTH, self.REL_MOTHER_NOTBIRTH]) return father_birth def get_sibling_relationship_string(self, sib_type, gender_a, gender_b, in_law_a=False, in_law_b=False): if self.only_birth: if gender_b == gen.lib.Person.MALE: rel_str = "le frère germain" elif gender_b == gen.lib.Person.FEMALE: rel_str = "la sœur germaine" else: return "..." if self.mother_birth: if gender_b == gen.lib.Person.MALE and sib_type == self.HALF_SIB: rel_str = "le demi-frère utérin" elif gender_b == gen.lib.Person.FEMALE and sid_type == self.HALF_SIB: rel_str = "la demi-sœur utérine" else: rel_str = "..." if self.father_birth: if gender_b == gen.lib.Person.MALE and sid_type == self.HALF_SIB: rel_str = "le demi-frère consanguin" elif gender_b == gen.lib.Person.FEMALE and sid_type == self.HALF_SIB: rel_str = "la demi-sœur consanguine" else: rel_str = "..." if sid_type == self.STEP_SIB: if gender_b == gen.lib.Person.MALE: rel_str = "le beau-frère" elif gender_b == gen.lib.Person.FEMALE: rel_str = "la belle-sœur" else: rel_str = "..." this is a draft but I get returns which could be related to relationship.py ... File "plugins/rel_fr.py", line 606, in <module> test(rc, True) File "/home/jerome/gramps-3.0/share/gramps/Relationship.py", line 2081, in test _testsibling(rc) File "/home/jerome/gramps-3.0/share/gramps/Relationship.py", line 2034, in _testsibling in_law_a = inlaw) + ' |info:', str, strgen File "plugins/rel_fr.py", line 542, in get_sibling_relationship_string if gender_b == gen.lib.Person.MALE and sid_type == self.HALF_SIB: NameError: global name 'sid_type' is not defined Should I use "typestr" instead of "sid_type" for testing ? Or I will not be able to make this custom relationships with this code above. Also : 12318: ERROR: gramps.py: line 165: Unhandled exception Traceback (most recent call last): File "/home/jerome/gramps-3.0/share/gramps/DataViews/_PersonView.py", line 708, in row_changed self.uistate.modify_statusbar(self.dbstate) File "/home/jerome/gramps-3.0/share/gramps/DisplayState.py", line 436, in modify_statusbar msg = self.display_relationship(dbstate) File "/home/jerome/gramps-3.0/share/gramps/DisplayState.py", line 374, in display_relationship dbstate.db, default_person, active) File "/home/jerome/gramps-3.0/share/gramps/Relationship.py", line 1243, in get_one_relationship other_person.get_gender()) File "/home/jerome/gramps-3.0/share/gramps/plugins/rel_fr.py", line 542, in get_sibling_relationship_string if gender_b == gen.lib.Person.MALE and sid_type == self.HALF_SIB: NameError: global name 'sid_type' is not defined I don't really understand, "sid_type" was call/find on rel_xx.py. You made a great framework for relationships, I will be happy to follow your examples but French speaker have many specific relations, which need to be checked. I know that current rel_fr.py look a little bit basic (if, elif, else). But seems to be a good solution for checking multiples relations ... Jerome Benny Malengier a écrit : > Hi, > > A call for localization of the rel_xx modules. > > I wrapped up the changes to the relationship module. I personally did > new English, Dutch and Italian relationship module. This should give a > good example for german and latin languages. > > If people want to adapt the other modules to the new calling methods, at > the moment all is fresh in my mind, so I could give some help. > The methods that needs localization: > > -/ get_single_relationship_string : the core module > -/ get_sibling_relationship_string: only needed if English logic cannot > be reused > -/get_partner_relationship_string: normally not needed to translate. The > gettext translation of English method should work ok in most languages > -/get_plural_relationship_string: used in one tool. You find it in the > Relationship.py module only at the moment. > > I'll adapt the wiki explanation in the following week. Important is that > all rel_xx modules remove the get_relationship_distance(...) method. > Note the test code in eg rel_it.py and rel_nl.py, which allows for easy > checking the changes. > > Benny > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Douglas S. B. <db...@cs...> - 2007-11-23 13:47:38
|
Shouldn't that be "sib_type" rather than "sid_type"? -Doug On Fri, November 23, 2007 5:36 am, Jérôme wrote: > Benny, > > > I try to improve custom sibling_relationship on rel_fr because we don't > (really) use STEP and have words for mother/father/both side, something > like that: > > > def mother_birth(self, path): > """ given a path to common ancestor. Return True if mother birth > relations, False otherwise > """ > mother_birth = True > for str in path: > mother_birth = mother_birth and (str not in > [self.REL_FAM_NONBIRTH, > self.REL_FATHER_NOTBIRTH]) > return mother_birth > > def father_birth(self, path): > """ given a path to common ancestor. Return True if father birth > relations, False otherwise > """ > father_birth = True > for str in path: > father_birth = father_birth and (str not in > [self.REL_FAM_NONBIRTH, > self.REL_MOTHER_NOTBIRTH]) > return father_birth > > > def get_sibling_relationship_string(self, sib_type, gender_a, gender_b, > in_law_a=False, in_law_b=False): > > if self.only_birth: > if gender_b == gen.lib.Person.MALE: > rel_str = "le frère germain" > elif gender_b == gen.lib.Person.FEMALE: > rel_str = "la sÅur germaine" > else: > return "..." > > if self.mother_birth: > if gender_b == gen.lib.Person.MALE and sib_type == > self.HALF_SIB: > rel_str = "le demi-frère utérin" > elif gender_b == gen.lib.Person.FEMALE and sid_type == > self.HALF_SIB: > rel_str = "la demi-sÅur utérine" > else: > rel_str = "..." > > if self.father_birth: > if gender_b == gen.lib.Person.MALE and sid_type == > self.HALF_SIB: > rel_str = "le demi-frère consanguin" > elif gender_b == gen.lib.Person.FEMALE and sid_type == > self.HALF_SIB: > rel_str = "la demi-sÅur consanguine" > else: > rel_str = "..." > > if sid_type == self.STEP_SIB: > if gender_b == gen.lib.Person.MALE: > rel_str = "le beau-frère" > elif gender_b == gen.lib.Person.FEMALE: > rel_str = "la belle-sÅur" > else: > rel_str = "..." > > > this is a draft but I get returns which could be related to > relationship.py ... > > > File "plugins/rel_fr.py", line 606, in <module> > test(rc, True) > File "/home/jerome/gramps-3.0/share/gramps/Relationship.py", line > 2081, in test > _testsibling(rc) > File "/home/jerome/gramps-3.0/share/gramps/Relationship.py", line > 2034, in _testsibling > in_law_a = inlaw) + ' |info:', str, strgen > File "plugins/rel_fr.py", line 542, in get_sibling_relationship_string > if gender_b == gen.lib.Person.MALE and sid_type == self.HALF_SIB: > NameError: global name 'sid_type' is not defined > > > Should I use "typestr" instead of "sid_type" for testing ? Or I will not > be able to make this custom relationships with this code above. > > > Also : > > 12318: ERROR: gramps.py: line 165: Unhandled exception > Traceback (most recent call last): > File "/home/jerome/gramps-3.0/share/gramps/DataViews/_PersonView.py", > line 708, in row_changed > self.uistate.modify_statusbar(self.dbstate) > File "/home/jerome/gramps-3.0/share/gramps/DisplayState.py", line 436, > in modify_statusbar > msg = self.display_relationship(dbstate) > File "/home/jerome/gramps-3.0/share/gramps/DisplayState.py", line 374, > in display_relationship > dbstate.db, default_person, active) > File "/home/jerome/gramps-3.0/share/gramps/Relationship.py", line > 1243, in get_one_relationship > other_person.get_gender()) > File "/home/jerome/gramps-3.0/share/gramps/plugins/rel_fr.py", line > 542, in get_sibling_relationship_string > if gender_b == gen.lib.Person.MALE and sid_type == self.HALF_SIB: > NameError: global name 'sid_type' is not defined > > > I don't really understand, "sid_type" was call/find on rel_xx.py. > > You made a great framework for relationships, I will be happy to follow > your examples but French speaker have many specific relations, which > need to be checked. I know that current rel_fr.py look a little bit > basic (if, elif, else). But seems to be a good solution for checking > multiples relations ... > > > Jerome > > > > Benny Malengier a écrit : >> Hi, >> >> A call for localization of the rel_xx modules. >> >> I wrapped up the changes to the relationship module. I personally did >> new English, Dutch and Italian relationship module. This should give a >> good example for german and latin languages. >> >> If people want to adapt the other modules to the new calling methods, at >> the moment all is fresh in my mind, so I could give some help. >> The methods that needs localization: >> >> -/ get_single_relationship_string : the core module >> -/ get_sibling_relationship_string: only needed if English logic cannot >> be reused >> -/get_partner_relationship_string: normally not needed to translate. The >> gettext translation of English method should work ok in most languages >> -/get_plural_relationship_string: used in one tool. You find it in the >> Relationship.py module only at the moment. >> >> I'll adapt the wiki explanation in the following week. Important is that >> all rel_xx modules remove the get_relationship_distance(...) method. >> Note the test code in eg rel_it.py and rel_nl.py, which allows for easy >> checking the changes. >> >> Benny >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Gramps-devel mailing list >> Gra...@li... >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Douglas S. Blank Associate Professor, Bryn Mawr College http://cs.brynmawr.edu/~dblank/ Office: 610 526 6501 |
From: Benny M. <ben...@gm...> - 2007-11-23 14:41:25
|
QXMgdGhvdWdoIHNhaWQsIHlvdSB3cm90ZSBzaWQgaW5zdGVhZCBvZiBzaWIgKGZyb20gc2libGlu ZykuCgpBYm91dCB5b3VyIGNvZGU6CgoyMDA3LzExLzIzLCBKw6lyw7RtZSA8cm9tamVyb21lQHlh aG9vLmZyPjoKPgo+IEJlbm55LAo+Cj4KPiBJIHRyeSB0byBpbXByb3ZlIGN1c3RvbSBzaWJsaW5n X3JlbGF0aW9uc2hpcCBvbiByZWxfZnIgYmVjYXVzZSB3ZSBkb24ndAo+IChyZWFsbHkpIHVzZSBT VEVQIGFuZCBoYXZlIHdvcmRzIGZvciBtb3RoZXIvZmF0aGVyL2JvdGggc2lkZSwgc29tZXRoaW5n Cj4gbGlrZSB0aGF0Ogo+Cj4KPiAgICBkZWYgbW90aGVyX2JpcnRoKHNlbGYsIHBhdGgpOgo+ICAg ICAgICAgIiIiIGdpdmVuIGEgcGF0aCB0byBjb21tb24gYW5jZXN0b3IuIFJldHVybiBUcnVlIGlm IG1vdGhlciBiaXJ0aAo+ICAgICAgICAgICAgIHJlbGF0aW9ucywgRmFsc2Ugb3RoZXJ3aXNlCj4g ICAgICAgICAiIiIKPiAgICAgICAgIG1vdGhlcl9iaXJ0aCA9IFRydWUKPiAgICAgICAgIGZvciBz dHIgaW4gcGF0aDoKPiAgICAgICAgICAgICBtb3RoZXJfYmlydGggPSBtb3RoZXJfYmlydGggYW5k IChzdHIgbm90IGluCj4gW3NlbGYuUkVMX0ZBTV9OT05CSVJUSCwKPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBzZWxmLlJFTF9GQVRIRVJfTk9UQklSVEhdKQo+ICAgICAgICAgcmV0dXJuIG1v dGhlcl9iaXJ0aAoKCgoKICAgIGRlZiBmYXRoZXJfYmlydGgoc2VsZiwgcGF0aCk6Cj4gICAgICAg ICAiIiIgZ2l2ZW4gYSBwYXRoIHRvIGNvbW1vbiBhbmNlc3Rvci4gUmV0dXJuIFRydWUgaWYgZmF0 aGVyIGJpcnRoCj4gICAgICAgICAgICAgcmVsYXRpb25zLCBGYWxzZSBvdGhlcndpc2UKPiAgICAg ICAgICIiIgo+ICAgICAgICAgZmF0aGVyX2JpcnRoID0gVHJ1ZQo+ICAgICAgICAgZm9yIHN0ciBp biBwYXRoOgo+ICAgICAgICAgICAgIGZhdGhlcl9iaXJ0aCA9IGZhdGhlcl9iaXJ0aCBhbmQgKHN0 ciBub3QgaW4KPiBbc2VsZi5SRUxfRkFNX05PTkJJUlRILAo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHNlbGYuUkVMX01PVEhFUl9OT1RCSVJUSF0pCj4gICAgICAgICByZXR1cm4gZmF0aGVy X2JpcnRoCj4KPgo+IGRlZiBnZXRfc2libGluZ19yZWxhdGlvbnNoaXBfc3RyaW5nKHNlbGYsIHNp Yl90eXBlLCBnZW5kZXJfYSwgZ2VuZGVyX2IsCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGluX2xhd19hPUZhbHNlLCBpbl9sYXdfYj1GYWxzZSk6Cj4KPiAgICAgICAg IGlmIHNlbGYub25seV9iaXJ0aDoKPiAgICAgICAgICAgICBpZiBnZW5kZXJfYiA9PSBnZW4ubGli LlBlcnNvbi5NQUxFOgo+ICAgICAgICAgICAgICAgICByZWxfc3RyID0gImxlIGZyw6hyZSBnZXJt YWluIgo+ICAgICAgICAgICAgIGVsaWYgZ2VuZGVyX2IgPT0gZ2VuLmxpYi5QZXJzb24uRkVNQUxF Ogo+ICAgICAgICAgICAgICAgICByZWxfc3RyID0gImxhIHPFk3VyIGdlcm1haW5lIgo+ICAgICAg ICAgICAgIGVsc2U6Cj4gICAgICAgICAgICAgICAgIHJldHVybiAiLi4uIgoKClRoaXMgaXMgd3Jv bmcuIFlvdSBtYXkgbm90IGNoZWNrIG9uIHNlbGYub25seV9iaXJ0aC4gWW91IG11c3QgdXNlIHNp Yl90eXBlCmFuZCBkZXRlcm1pbmUgcmVsYXRpb24gZnJvbSB0aGF0LgoKICAgICAgICBpZiBzZWxm Lm1vdGhlcl9iaXJ0aDoKPiAgICAgICAgICAgICBpZiBnZW5kZXJfYiA9PSBnZW4ubGliLlBlcnNv bi5NQUxFIGFuZCBzaWJfdHlwZSA9PQo+IHNlbGYuSEFMRl9TSUI6Cj4gICAgICAgICAgICAgICAg IHJlbF9zdHIgPSAibGUgZGVtaS1mcsOocmUgdXTDqXJpbiIKPiAgICAgICAgICAgICBlbGlmIGdl bmRlcl9iID09IGdlbi5saWIuUGVyc29uLkZFTUFMRSBhbmQgc2lkX3R5cGUgPT0KPiBzZWxmLkhB TEZfU0lCOgo+ICAgICAgICAgICAgICAgICByZWxfc3RyID0gImxhIGRlbWktc8WTdXIgdXTDqXJp bmUiCj4gICAgICAgICAgICAgZWxzZToKPiAgICAgICAgICAgICAgICAgcmVsX3N0ciA9ICIuLi4i CgoKc2VsZi5tb3RoZXJfYmlydGggZG9lcyBub3QgZXhpc3QuCgogICAgICAgIGlmIHNlbGYuZmF0 aGVyX2JpcnRoOgo+ICAgICAgICAgICAgIGlmIGdlbmRlcl9iID09IGdlbi5saWIuUGVyc29uLk1B TEUgYW5kIHNpZF90eXBlID09Cj4gc2VsZi5IQUxGX1NJQjoKPiAgICAgICAgICAgICAgICAgcmVs X3N0ciA9ICJsZSBkZW1pLWZyw6hyZSBjb25zYW5ndWluIgo+ICAgICAgICAgICAgIGVsaWYgZ2Vu ZGVyX2IgPT0gZ2VuLmxpYi5QZXJzb24uRkVNQUxFIGFuZCBzaWRfdHlwZSA9PQo+IHNlbGYuSEFM Rl9TSUI6Cj4gICAgICAgICAgICAgICAgIHJlbF9zdHIgPSAibGEgZGVtaS1zxZN1ciBjb25zYW5n dWluZSIKPiAgICAgICAgICAgICBlbHNlOgo+ICAgICAgICAgICAgICAgICByZWxfc3RyID0gIi4u LiIKPgo+ICAgICAgICAgaWYgc2lkX3R5cGUgPT0gc2VsZi5TVEVQX1NJQjoKPiAgICAgICAgICAg ICBpZiBnZW5kZXJfYiA9PSBnZW4ubGliLlBlcnNvbi5NQUxFOgo+ICAgICAgICAgICAgICAgICBy ZWxfc3RyID0gImxlIGJlYXUtZnLDqHJlIgo+ICAgICAgICAgICAgIGVsaWYgZ2VuZGVyX2IgPT0g Z2VuLmxpYi5QZXJzb24uRkVNQUxFOgo+ICAgICAgICAgICAgICAgICByZWxfc3RyID0gImxhIGJl bGxlLXPFk3VyIgo+ICAgICAgICAgICAgIGVsc2U6Cj4gICAgICAgICAgICAgICAgIHJlbF9zdHIg PSAiLi4uIgo+Cj4KPiB0aGlzIGlzIGEgZHJhZnQgYnV0IEkgZ2V0IHJldHVybnMgd2hpY2ggY291 bGQgYmUgcmVsYXRlZCB0bwo+IHJlbGF0aW9uc2hpcC5weSAuLi4KPgo+Cj4gWW91IG1hZGUgYSBn cmVhdCBmcmFtZXdvcmsgZm9yIHJlbGF0aW9uc2hpcHMsIEkgd2lsbCBiZSBoYXBweSB0byBmb2xs b3cKPiB5b3VyIGV4YW1wbGVzIGJ1dCBGcmVuY2ggc3BlYWtlciBoYXZlIG1hbnkgc3BlY2lmaWMg cmVsYXRpb25zLCB3aGljaAo+IG5lZWQgdG8gYmUgY2hlY2tlZC4gSSBrbm93IHRoYXQgY3VycmVu dCByZWxfZnIucHkgbG9vayBhIGxpdHRsZSBiaXQKPiBiYXNpYyAoaWYsIGVsaWYsIGVsc2UpLiBC dXQgc2VlbXMgdG8gYmUgYSBnb29kIHNvbHV0aW9uIGZvciBjaGVja2luZwo+IG11bHRpcGxlcyBy ZWxhdGlvbnMgLi4uCgoKSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgZm9yIGZyZW5jaCB5b3Ug bmVlZCB0byBrbm93IGlmIGJpcnRoIHJlbGF0aW9uIGlzCndpdGggZmF0aGVyIG9yIG1vdGhlci4K ClRoZSBsb2dpYyB3b3VsZCBoZW5jZSBiZToKMS8gaWYgc2liX3R5cGUgPT0gc2VsZi5OT1JNX1NJ QiBvciBzaWJfdHlwZSA9PSBzZWxmLlVOS05PV05fU0lCOgogICAgLS0+IHJldHVybiBmcmVuY2gg Zm9yIGZ1bGwgc2libGluZ3MgZGVwZW5kaW5nIG9uIGdlbmRlciBvciBwZXJzb24KMi8gaWYgc2li X3R5cGUgPT0gc2VsZi5TVEVQX1NJQgogICAtLT4gcmV0dXJuIGZyZW5jaCBmb3Igc2libGluZ3Mg d2hpY2ggaGF2ZSBubyBjb21tb24gYW5jZXN0b3IKMy8gaWYgc2liX3R5cGUgPT0gc2VsZi5IQUxG X1NJQgogICAtLT4gb25lIHBhcmVudCBpcyB0aGUgc2FtZSBvbmUgaXMgZGlmZmVyZW50LCB5b3Ug bmVlZCB0byBrbm93IHdoaWNoIG9uZQoobW90aGVyIGFuZCBmYXRoZXIpClRoaXMgaXMgbm90IHBv c3NpYmxlIHdpdGggcHJlc2VudCBjb2RlCiA9PT4gSSB3aWxsIGNoYW5nZSB0aGUgdHlwZXMgdG8g SEFMRl9TSUJfTU9USEVSIGFuZCBIQUxGX1NJQl9GQVRIRVIgc28gYXMgdG8KYWNjb21tb2RhdGUg dGhpcy4KCkJlbm55Cg== |
From: Benny M. <ben...@gm...> - 2007-11-23 15:03:32
|
SmVyb21lLCBzdm4gdXAuCgpIYWxmIHNpYmxpbmcgdHlwZSBub3cgaW5kaWNhdGVzIHRoZSBzaWRl IG9mIGJsb29kIHRvby4KCkJlbm55CgoyMDA3LzExLzIzLCBCZW5ueSBNYWxlbmdpZXIgPGJlbm55 Lm1hbGVuZ2llckBnbWFpbC5jb20+Ogo+Cj4gQXMgdGhvdWdoIHNhaWQsIHlvdSB3cm90ZSBzaWQg aW5zdGVhZCBvZiBzaWIgKGZyb20gc2libGluZykuCj4KPiBBYm91dCB5b3VyIGNvZGU6Cj4KPiAy MDA3LzExLzIzLCBKw6lyw7RtZSA8cm9tamVyb21lQHlhaG9vLmZyPjoKPiA+Cj4gPiBCZW5ueSwK PiA+Cj4gPgo+ID4gSSB0cnkgdG8gaW1wcm92ZSBjdXN0b20gc2libGluZ19yZWxhdGlvbnNoaXAg b24gcmVsX2ZyIGJlY2F1c2Ugd2UgZG9uJ3QKPiA+IChyZWFsbHkpIHVzZSBTVEVQIGFuZCBoYXZl IHdvcmRzIGZvciBtb3RoZXIvZmF0aGVyL2JvdGggc2lkZSwgc29tZXRoaW5nCj4gPiBsaWtlIHRo YXQ6Cj4gPgo+ID4KPiA+ICAgIGRlZiBtb3RoZXJfYmlydGgoc2VsZiwgcGF0aCk6Cj4gPiAgICAg ICAgICIiIiBnaXZlbiBhIHBhdGggdG8gY29tbW9uIGFuY2VzdG9yLiBSZXR1cm4gVHJ1ZSBpZiBt b3RoZXIgYmlydGgKPiA+ICAgICAgICAgICAgIHJlbGF0aW9ucywgRmFsc2Ugb3RoZXJ3aXNlCj4g PiAgICAgICAgICIiIgo+ID4gICAgICAgICBtb3RoZXJfYmlydGggPSBUcnVlCj4gPiAgICAgICAg IGZvciBzdHIgaW4gcGF0aDoKPiA+ICAgICAgICAgICAgIG1vdGhlcl9iaXJ0aCA9IG1vdGhlcl9i aXJ0aCBhbmQgKHN0ciBub3QgaW4KPiA+IFtzZWxmLlJFTF9GQU1fTk9OQklSVEgsCj4gPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBzZWxmLlJFTF9GQVRIRVJfTk9UQklSVEhdKQo+ID4gICAg ICAgICByZXR1cm4gbW90aGVyX2JpcnRoCj4KPgo+Cj4KPiAgICAgZGVmIGZhdGhlcl9iaXJ0aChz ZWxmLCBwYXRoKToKPiA+ICAgICAgICAgIiIiIGdpdmVuIGEgcGF0aCB0byBjb21tb24gYW5jZXN0 b3IuIFJldHVybiBUcnVlIGlmIGZhdGhlciBiaXJ0aAo+ID4gICAgICAgICAgICAgcmVsYXRpb25z LCBGYWxzZSBvdGhlcndpc2UKPiA+ICAgICAgICAgIiIiCj4gPiAgICAgICAgIGZhdGhlcl9iaXJ0 aCA9IFRydWUKPiA+ICAgICAgICAgZm9yIHN0ciBpbiBwYXRoOgo+ID4gICAgICAgICAgICAgZmF0 aGVyX2JpcnRoID0gZmF0aGVyX2JpcnRoIGFuZCAoc3RyIG5vdCBpbgo+ID4gW3NlbGYuUkVMX0ZB TV9OT05CSVJUSCwKPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlbGYuUkVMX01PVEhF Ul9OT1RCSVJUSF0pCj4gPiAgICAgICAgIHJldHVybiBmYXRoZXJfYmlydGgKPiA+Cj4gPgo+ID4g ZGVmIGdldF9zaWJsaW5nX3JlbGF0aW9uc2hpcF9zdHJpbmcoc2VsZiwgc2liX3R5cGUsIGdlbmRl cl9hLCBnZW5kZXJfYiwKPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBpbl9sYXdfYT1GYWxzZSwgaW5fbGF3X2I9RmFsc2UpOgo+ID4KPiA+ICAgICAgICAgaWYgc2Vs Zi5vbmx5X2JpcnRoOgo+ID4gICAgICAgICAgICAgaWYgZ2VuZGVyX2IgPT0gZ2VuLmxpYi5QZXJz b24uTUFMRToKPiA+ICAgICAgICAgICAgICAgICByZWxfc3RyID0gImxlIGZyw6hyZSBnZXJtYWlu Igo+ID4gICAgICAgICAgICAgZWxpZiBnZW5kZXJfYiA9PSBnZW4ubGliLlBlcnNvbi5GRU1BTEU6 Cj4gPiAgICAgICAgICAgICAgICAgcmVsX3N0ciA9ICJsYSBzxZN1ciBnZXJtYWluZSIKPiA+ICAg ICAgICAgICAgIGVsc2U6Cj4gPiAgICAgICAgICAgICAgICAgcmV0dXJuICIuLi4iCj4KPgo+IFRo aXMgaXMgd3JvbmcuIFlvdSBtYXkgbm90IGNoZWNrIG9uIHNlbGYub25seV9iaXJ0aC4gWW91IG11 c3QgdXNlIHNpYl90eXBlCj4gYW5kIGRldGVybWluZSByZWxhdGlvbiBmcm9tIHRoYXQuCj4KPiAg ICAgICAgIGlmIHNlbGYubW90aGVyX2JpcnRoOgo+ID4gICAgICAgICAgICAgaWYgZ2VuZGVyX2Ig PT0gZ2VuLmxpYi5QZXJzb24uTUFMRSBhbmQgc2liX3R5cGUgPT0KPiA+IHNlbGYuSEFMRl9TSUI6 Cj4gPiAgICAgICAgICAgICAgICAgcmVsX3N0ciA9ICJsZSBkZW1pLWZyw6hyZSB1dMOpcmluIgo+ ID4gICAgICAgICAgICAgZWxpZiBnZW5kZXJfYiA9PSBnZW4ubGliLlBlcnNvbi5GRU1BTEUgYW5k IHNpZF90eXBlID09Cj4gPiBzZWxmLkhBTEZfU0lCOgo+ID4gICAgICAgICAgICAgICAgIHJlbF9z dHIgPSAibGEgZGVtaS1zxZN1ciB1dMOpcmluZSIKPiA+ICAgICAgICAgICAgIGVsc2U6Cj4gPiAg ICAgICAgICAgICAgICAgcmVsX3N0ciA9ICIuLi4iCj4KPgo+IHNlbGYubW90aGVyX2JpcnRoIGRv ZXMgbm90IGV4aXN0Lgo+Cj4gICAgICAgICBpZiBzZWxmLmZhdGhlcl9iaXJ0aDoKPiA+ICAgICAg ICAgICAgIGlmIGdlbmRlcl9iID09IGdlbi5saWIuUGVyc29uLk1BTEUgYW5kIHNpZF90eXBlID09 Cj4gPiBzZWxmLkhBTEZfU0lCOgo+ID4gICAgICAgICAgICAgICAgIHJlbF9zdHIgPSAibGUgZGVt aS1mcsOocmUgY29uc2FuZ3VpbiIKPiA+ICAgICAgICAgICAgIGVsaWYgZ2VuZGVyX2IgPT0gZ2Vu LmxpYi5QZXJzb24uRkVNQUxFIGFuZCBzaWRfdHlwZSA9PQo+ID4gc2VsZi5IQUxGX1NJQjoKPiA+ ICAgICAgICAgICAgICAgICByZWxfc3RyID0gImxhIGRlbWktc8WTdXIgY29uc2FuZ3VpbmUiCj4g PiAgICAgICAgICAgICBlbHNlOgo+ID4gICAgICAgICAgICAgICAgIHJlbF9zdHIgPSAiLi4uIgo+ ID4KPiA+ICAgICAgICAgaWYgc2lkX3R5cGUgPT0gc2VsZi5TVEVQX1NJQjoKPiA+ICAgICAgICAg ICAgIGlmIGdlbmRlcl9iID09IGdlbi5saWIuUGVyc29uLk1BTEU6Cj4gPiAgICAgICAgICAgICAg ICAgcmVsX3N0ciA9ICJsZSBiZWF1LWZyw6hyZSIKPiA+ICAgICAgICAgICAgIGVsaWYgZ2VuZGVy X2IgPT0gZ2VuLmxpYi5QZXJzb24uRkVNQUxFOgo+ID4gICAgICAgICAgICAgICAgIHJlbF9zdHIg PSAibGEgYmVsbGUtc8WTdXIiCj4gPiAgICAgICAgICAgICBlbHNlOgo+ID4gICAgICAgICAgICAg ICAgIHJlbF9zdHIgPSAiLi4uIgo+ID4KPiA+Cj4gPiB0aGlzIGlzIGEgZHJhZnQgYnV0IEkgZ2V0 IHJldHVybnMgd2hpY2ggY291bGQgYmUgcmVsYXRlZCB0bwo+ID4gcmVsYXRpb25zaGlwLnB5IC4u Lgo+ID4KPiA+Cj4gPiBZb3UgbWFkZSBhIGdyZWF0IGZyYW1ld29yayBmb3IgcmVsYXRpb25zaGlw cywgSSB3aWxsIGJlIGhhcHB5IHRvIGZvbGxvdwo+ID4geW91ciBleGFtcGxlcyBidXQgRnJlbmNo IHNwZWFrZXIgaGF2ZSBtYW55IHNwZWNpZmljIHJlbGF0aW9ucywgd2hpY2gKPiA+IG5lZWQgdG8g YmUgY2hlY2tlZC4gSSBrbm93IHRoYXQgY3VycmVudCByZWxfZnIucHkgbG9vayBhIGxpdHRsZSBi aXQKPiA+IGJhc2ljIChpZiwgZWxpZiwgZWxzZSkuIEJ1dCBzZWVtcyB0byBiZSBhIGdvb2Qgc29s dXRpb24gZm9yIGNoZWNraW5nCj4gPiBtdWx0aXBsZXMgcmVsYXRpb25zIC4uLgo+Cj4KPiBJZiBJ IHVuZGVyc3RhbmQgY29ycmVjdGx5LCBmb3IgZnJlbmNoIHlvdSBuZWVkIHRvIGtub3cgaWYgYmly dGggcmVsYXRpb24KPiBpcyB3aXRoIGZhdGhlciBvciBtb3RoZXIuCj4KPiBUaGUgbG9naWMgd291 bGQgaGVuY2UgYmU6Cj4gMS8gaWYgc2liX3R5cGUgPT0gc2VsZi5OT1JNX1NJQiBvciBzaWJfdHlw ZSA9PSBzZWxmLlVOS05PV05fU0lCOgo+ICAgICAtLT4gcmV0dXJuIGZyZW5jaCBmb3IgZnVsbCBz aWJsaW5ncyBkZXBlbmRpbmcgb24gZ2VuZGVyIG9yIHBlcnNvbgo+IDIvIGlmIHNpYl90eXBlID09 IHNlbGYuU1RFUF9TSUIKPiAgICAtLT4gcmV0dXJuIGZyZW5jaCBmb3Igc2libGluZ3Mgd2hpY2gg aGF2ZSBubyBjb21tb24gYW5jZXN0b3IKPiAzLyBpZiBzaWJfdHlwZSA9PSBzZWxmLkhBTEZfU0lC Cj4gICAgLS0+IG9uZSBwYXJlbnQgaXMgdGhlIHNhbWUgb25lIGlzIGRpZmZlcmVudCwgeW91IG5l ZWQgdG8ga25vdyB3aGljaCBvbmUKPiAobW90aGVyIGFuZCBmYXRoZXIpCj4gVGhpcyBpcyBub3Qg cG9zc2libGUgd2l0aCBwcmVzZW50IGNvZGUKPiAgPT0+IEkgd2lsbCBjaGFuZ2UgdGhlIHR5cGVz IHRvIEhBTEZfU0lCX01PVEhFUiBhbmQgSEFMRl9TSUJfRkFUSEVSIHNvIGFzCj4gdG8gYWNjb21t b2RhdGUgdGhpcy4KPgo+IEJlbm55Cj4K |
From: <rom...@ya...> - 2007-11-23 16:13:03
|
> As though said, you wrote sid instead of sib (from sibling). you are right :-[ thanks > If I understand correctly, for french you need to know if birth relation > is with father or mother. Yes, it is just used for half-siblings and sometimes first cousins (mother/father side) http://sourdaine.org/06_Degr2.jpg Maybe I will ignore some relations !!! * birth - parents not married (enfant légitime-naturel-adoptif-adultérin) * child from second marriage (du second lit) * child after the first child (Cadet, cadette) > This is not possible with present code > ==> I will change the types to HALF_SIB_MOTHER and HALF_SIB_FATHER so as to accommodate this. > Half sibling type now indicates the side of blood too. thanks, I will try :) Benny Malengier a écrit : > As though said, you wrote sid instead of sib (from sibling). > > About your code: > > 2007/11/23, Jérôme <rom...@ya... <mailto:rom...@ya...>>: > > Benny, > > > I try to improve custom sibling_relationship on rel_fr because we don't > (really) use STEP and have words for mother/father/both side, something > like that: > > > def mother_birth(self, path): > """ given a path to common ancestor. Return True if mother birth > relations, False otherwise > """ > mother_birth = True > for str in path: > mother_birth = mother_birth and (str not in > [self.REL_FAM_NONBIRTH, > self.REL_FATHER_NOTBIRTH]) > return mother_birth > > > > > def father_birth(self, path): > """ given a path to common ancestor. Return True if father birth > relations, False otherwise > """ > father_birth = True > for str in path: > father_birth = father_birth and (str not in > [self.REL_FAM_NONBIRTH, > self.REL_MOTHER_NOTBIRTH]) > return father_birth > > > def get_sibling_relationship_string(self, sib_type, gender_a, gender_b, > in_law_a=False, in_law_b=False): > > if self.only_birth: > if gender_b == gen.lib.Person.MALE: > rel_str = "le frère germain" > elif gender_b == gen.lib.Person.FEMALE: > rel_str = "la sœur germaine" > else: > return "..." > > > This is wrong. You may not check on self.only_birth. You must use > sib_type and determine relation from that. > > if self.mother_birth: > if gender_b == gen.lib.Person.MALE and sib_type == > self.HALF_SIB: > rel_str = "le demi-frère utérin" > elif gender_b == gen.lib.Person.FEMALE and sid_type == > self.HALF_SIB: > rel_str = "la demi-sœur utérine" > else: > rel_str = "..." > > > self.mother_birth does not exist. > > if self.father_birth: > if gender_b == gen.lib.Person.MALE and sid_type == > self.HALF_SIB: > rel_str = "le demi-frère consanguin" > elif gender_b == gen.lib.Person.FEMALE and sid_type == > self.HALF_SIB: > rel_str = "la demi-sœur consanguine" > else: > rel_str = "..." > > if sid_type == self.STEP_SIB: > if gender_b == gen.lib.Person.MALE: > rel_str = "le beau-frère" > elif gender_b == gen.lib.Person.FEMALE: > rel_str = "la belle-sœur" > else: > rel_str = "..." > > > this is a draft but I get returns which could be related to > relationship.py ... > > > You made a great framework for relationships, I will be happy to follow > your examples but French speaker have many specific relations, which > need to be checked. I know that current rel_fr.py look a little bit > basic (if, elif, else). But seems to be a good solution for checking > multiples relations ... > > > If I understand correctly, for french you need to know if birth relation > is with father or mother. > > The logic would hence be: > 1/ if sib_type == self.NORM_SIB or sib_type == self.UNKNOWN_SIB: > --> return french for full siblings depending on gender or person > 2/ if sib_type == self.STEP_SIB > --> return french for siblings which have no common ancestor > 3/ if sib_type == self.HALF_SIB > --> one parent is the same one is different, you need to know which > one (mother and father) > This is not possible with present code > ==> I will change the types to HALF_SIB_MOTHER and HALF_SIB_FATHER so > as to accommodate this. > > Benny |
From: Benny M. <ben...@gm...> - 2007-11-23 16:40:38
|
MjAwNy8xMS8yMywgSsOpcsO0bWUgPHJvbWplcm9tZUB5YWhvby5mcj46Cj4KPiA+IEFzIHRob3Vn aCBzYWlkLCB5b3Ugd3JvdGUgc2lkIGluc3RlYWQgb2Ygc2liIChmcm9tIHNpYmxpbmcpLgo+Cj4g eW91IGFyZSByaWdodCA6LVsKPiB0aGFua3MKPgo+ID4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3Rs eSwgZm9yIGZyZW5jaCB5b3UgbmVlZCB0byBrbm93IGlmIGJpcnRoIHJlbGF0aW9uCj4gPiBpcyB3 aXRoIGZhdGhlciBvciBtb3RoZXIuCj4KPiBZZXMsIGl0IGlzIGp1c3QgdXNlZCBmb3IgaGFsZi1z aWJsaW5ncyBhbmQgc29tZXRpbWVzIGZpcnN0IGNvdXNpbnMKPiAobW90aGVyL2ZhdGhlciBzaWRl KQo+Cj4gaHR0cDovL3NvdXJkYWluZS5vcmcvMDZfRGVncjIuanBnCj4KPiBNYXliZSBJIHdpbGwg aWdub3JlIHNvbWUgcmVsYXRpb25zICEhIQo+Cj4gKiBiaXJ0aCAtIHBhcmVudHMgbm90IG1hcnJp ZWQgKGVuZmFudCBsw6lnaXRpbWUtbmF0dXJlbC1hZG9wdGlmLWFkdWx0w6lyaW4pCj4gKiBjaGls ZCBmcm9tIHNlY29uZCBtYXJyaWFnZSAoZHUgc2Vjb25kIGxpdCkKPiAqIGNoaWxkIGFmdGVyIHRo ZSBmaXJzdCBjaGlsZCAoQ2FkZXQsIGNhZGV0dGUpCgoKRG9uJ3QgdHJ5IHRvIGtub3cgZm9yIG5v bi1zaWJsaW5ncyBob3cgbXVjaCBiaXJ0aCByZWxhdGlvbiB0aGV5IGhhdmUuCkZvciBzaWJsaW5n cyB0aGlzIG1ha2VzIHNlbnNlLCBhbmQgaXMgc3RpbGwgZWFzeSB0byBkZXRlcm1pbmUgaG93IHRo ZXkgYXJlCmhhbGYgcmVsYXRlZC4KQWRkIG9uZSBnZW5lcmF0aW9uLCBhbmQgdGhpcyBiZWNvbWVz IHJlYWxseSBoYXJkIChtdWx0aXBsZSBmYW1pbGllcywKcmVtYXJyeSwgLi4uKS4gVGhhdCBpcyB3 aHkgdGhlcmUgaXMgc3BlY2lhbCBjb2RlIGZvciBzaWJsaW5ncywgYnV0IGZvciBvdGhlcgpyZWxh dGlvbnMgaXQgaXMgb25seSBwYXNzZWQgaWYgYmlydGggcmVsYXRpb24gb3Igbm90IG92ZXIgdGhl IHBhdGggdGhhdCBoYXMKYmVlbiBzZWFyY2hlZC4gU28gZG9uJ3QgbWFrZSB0aGF0IGRpc3RpbmN0 aW9uIGJldHdlZW4gdXRlcmluIGFuZCBjb25zYWd1aW4KZnVydGhlciB1cC4KCkJlbm55Cg== |
From: Josip <jo...@pi...> - 2007-11-23 18:21:29
|
Benny Malengier wrote: > > If people want to adapt the other modules to the new calling methods, at > the moment all is fresh in my mind, so I could give some help. > Hi! Can you explain what sort of relationship is when both in_law_a and in_law_b is True? -- Josip |
From: Benny M. <ben...@gm...> - 2007-11-23 20:45:20
|
Both true means you have person A and person B. The partner of person A is related to the partner of person B. I guess in most languages this will not have a different wording than the case of only one of the two being a partner. Note that in most languages the terminology does not really exist outside the direct family. However, for genealogy reasons it is interesting to see a relationship, and use the same rules of close family to family many generations away. For performance reasons in-law relationships are only visible in the quick report 'relationship to home person'. Also note that it is not needed to have different words for everything if that does not exist in you language. Eg, in Italian one does not distinguish between half-brother and stepbrother. That is a pity from the point of view of conveying information, but cannot be helped without sounding unnatural. Benny 2007/11/24, Josip <jo...@pi...>: > > Benny Malengier wrote: > > > > > If people want to adapt the other modules to the new calling methods, at > > the moment all is fresh in my mind, so I could give some help. > > > > Hi! > Can you explain what sort of relationship is when both in_law_a and > in_law_b is True? > > -- > Josip > |
From: <rom...@ya...> - 2007-11-24 10:25:55
|
Benny, > guess in most languages this will not have a different wording than the case of only one of the two being a partner. We don't care of inlaw_b on single_relationships, no ? Should I add "inlaw_b" to avoid mistakes with partner or UNKNOW gender ? Should I remove inlaw_a on this code ? (gendre = spouse of daughter, beau-père = father of spouse) Ga == 0: if Gb == 0: .... elif gender_b == gen.lib.Person.MALE if in_law_a and Gb == 1: rel_str = "le gendre" else: rel_str = self.get_son(Gb) elif gender_b == gen.lib.Person.FEMALE if in_law_a and Gb == 1: rel_str = "la bru" else: rel_str = self.get_daughter(Gb) elif gender_b == gen.lib.Person.MALE if in_law_a and Ga == 1: rel_str = "le beau-père" else: rel_str = self.get_father(Ga, inlaw) elif gender_b == gen.lib.Person.FEMALE and Ga < len(_mother_level): if in_law_a and Ga == 1: rel_str = "la belle-mère" else: rel_str = self.get_mother(Ga, inlaw) Maybe like in english (without STEP or INLAW) : "father of spouse" have the same wording as "second spouse of one parent". Benny Malengier a écrit : > Both true means you have person A and person B. The partner of person A > is related to the partner of person B. > I guess in most languages this will not have a different wording than > the case of only one of the two being a partner. > > Note that in most languages the terminology does not really exist > outside the direct family. However, for genealogy reasons it is > interesting to see a relationship, and use the same rules of close > family to family many generations away. For performance reasons in-law > relationships are only visible in the quick report 'relationship to home > person'. > > Also note that it is not needed to have different words for everything > if that does not exist in you language. Eg, in Italian one does not > distinguish between half-brother and stepbrother. That is a pity from > the point of view of conveying information, but cannot be helped without > sounding unnatural. > > Benny > > 2007/11/24, Josip <jo...@pi... <mailto:jo...@pi...>>: > > Benny Malengier wrote: > > > > > If people want to adapt the other modules to the new calling > methods, at > > the moment all is fresh in my mind, so I could give some help. > > > > Hi! > Can you explain what sort of relationship is when both in_law_a and > in_law_b is True? > > -- > Josip > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Benny M. <ben...@gm...> - 2007-11-24 12:54:25
|
Pgo+Cj4gPiBndWVzcyBpbiBtb3N0IGxhbmd1YWdlcyB0aGlzIHdpbGwgbm90IGhhdmUgYSBkaWZm ZXJlbnQgd29yZGluZyB0aGFuIHRoZQo+IGNhc2Ugb2Ygb25seSBvbmUgb2YgdGhlIHR3byBiZWlu ZyBhIHBhcnRuZXIuCj4KPiBXZSBkb24ndCBjYXJlIG9mIGlubGF3X2Igb24gc2luZ2xlX3JlbGF0 aW9uc2hpcHMsIG5vID8KCgpkZXBlbmRzIG9mIHlvdXIgbGFuZ3VhZ2UuIEluIGVuZ2xpc2gvZHV0 Y2gvaXRhbGlhbiB3ZSBoYXZlCmlubGF3ID0gaW5sYXdfYiBvciBpbmxhd19hCgphbmQgdGhlbiB3 b3JrIHdpdGggaW5sYXcsIHNvIGlubGF3X2IgbWF0dGVycy4KClNob3VsZCBJIGFkZCAiaW5sYXdf YiIgdG8gYXZvaWQgbWlzdGFrZXMgd2l0aCBwYXJ0bmVyIG9yIFVOS05PVyBnZW5kZXIgPwo+IFNo b3VsZCBJIHJlbW92ZSBpbmxhd19hIG9uIHRoaXMgY29kZSA/CgoKSSB3b3VsZCB1c2UgaW5sYXcg YXMgY29uc3RydWN0ZWQgYWJvdmUuIFRoZSBzcG91c2Ugb2YgeW91ciB3aWZlcyBkYXVnaHRlciBp bgphbm90aGVyIHJlbGF0aW9uIHdvdWxkIGFsc28gYmUgeW91ciAnZ2VuZHJlJyBubz8gU2VlIHJl bF9pdC5weSB3aG8gYWxzbyBoYXZlCnNwZWNpZmljIHdvcmRzIGZvciB0aGF0LgoKKGdlbmRyZSA9 IHNwb3VzZSBvZiBkYXVnaHRlciwgYmVhdS1ww6hyZSA9IGZhdGhlciBvZiBzcG91c2UpCj4KPiAg ICAgICBHYSA9PSAwOgo+ICAgICAgICAgICBpZiBHYiA9PSAwOgo+ICAgICAgICAgICAgICAgICAu Li4uCj4gICAgICAgICAgIGVsaWYgZ2VuZGVyX2IgPT0gZ2VuLmxpYi5QZXJzb24uTUFMRQo+ICAg ICAgICAgICAgICAgICBpZiBpbl9sYXdfYSBhbmQgR2IgPT0gMToKPiAgICAgICAgICAgICAgICAg ICAgIHJlbF9zdHIgPSAibGUgZ2VuZHJlIgo+ICAgICAgICAgICAgICAgICBlbHNlOgo+ICAgICAg ICAgICAgICAgICAgICAgcmVsX3N0ciA9IHNlbGYuZ2V0X3NvbihHYikKPiAgICAgICAgICAgZWxp ZiBnZW5kZXJfYiA9PSBnZW4ubGliLlBlcnNvbi5GRU1BTEUKPiAgICAgICAgICAgICAgICBpZiBp bl9sYXdfYSBhbmQgR2IgPT0gMToKPiAgICAgICAgICAgICAgICAgICAgIHJlbF9zdHIgPSAibGEg YnJ1Igo+ICAgICAgICAgICAgICAgICBlbHNlOgo+ICAgICAgICAgICAgICAgICAgICAgcmVsX3N0 ciA9IHNlbGYuZ2V0X2RhdWdodGVyKEdiKQo+ICAgICAgICAgICBlbGlmIGdlbmRlcl9iID09IGdl bi5saWIuUGVyc29uLk1BTEUKPiAgICAgICAgICAgICAgICAgaWYgaW5fbGF3X2EgYW5kIEdhID09 IDE6Cj4gICAgICAgICAgICAgICAgICAgICByZWxfc3RyID0gImxlIGJlYXUtcMOocmUiCj4gICAg ICAgICAgICAgICAgIGVsc2U6Cj4gICAgICAgICAgICAgICAgICAgICByZWxfc3RyID0gc2VsZi5n ZXRfZmF0aGVyKEdhLCBpbmxhdykKPiAgICAgICAgICAgZWxpZiBnZW5kZXJfYiA9PSBnZW4ubGli LlBlcnNvbi5GRU1BTEUgYW5kIEdhIDwKPiBsZW4oX21vdGhlcl9sZXZlbCk6Cj4gICAgICAgICAg ICAgICAgIGlmIGluX2xhd19hIGFuZCBHYSA9PSAxOgo+ICAgICAgICAgICAgICAgICAgICAgcmVs X3N0ciA9ICJsYSBiZWxsZS1tw6hyZSIKPiAgICAgICAgICAgICAgICAgZWxzZToKPiAgICAgICAg ICAgICAgICAgICAgIHJlbF9zdHIgPSBzZWxmLmdldF9tb3RoZXIoR2EsIGlubGF3KQo+Cj4KPiBN YXliZSBsaWtlIGluIGVuZ2xpc2ggKHdpdGhvdXQgU1RFUCBvciBJTkxBVykgOiAiZmF0aGVyIG9m IHNwb3VzZSIgaGF2ZQo+IHRoZSBzYW1lIHdvcmRpbmcgYXMgInNlY29uZCBzcG91c2Ugb2Ygb25l IHBhcmVudCIuCj4KCgpCZW5ueQo= |
From: <rom...@ya...> - 2007-11-24 15:11:48
|
> See rel_it.py who also have specific words for that. Yes, thanks. I made changes on rel_fr :) I just have a minor "STEP family" issue on all_relations informations: UNKNOWN relation type between FATHER and (STEP-MOTHER) returns the same value as inlaw=True and step=False !!! I try to use: elif gender_b == gen.lib.Person.FEMALE and Ga < len(_mother_level): if inlaw and Ga == 1 and not step: rel_str = "la mère du conjoint" elif step and Ga == 1 and not inlaw: rel_str = "la belle-mère" else: rel_str = self.get_mother(Ga, inlaw) I agree, it is not a second marriage, just an other spouse/partner. > Traditionally, a stepfamily is the family one acquires when a parent enters a new marriage, whether the parent was widowed or divorced. http://en.wikipedia.org/wiki/Stepfamily Does it mean that STEP is only for family_type = MARRIED and we ignore UNMARRIED, CIVIL_UNION, UNKNOWN, CUSTOM ? Maybe it is a new special case, which might be tested on STEP relationship.py ? I know that STEP is important for english speaker. Currently, I just try to make the difference between STEP-parents and parents inlaw on parents/children level. If STEP is just for second marriage, maybe I will ignore STEP and I will try to find an alternative ... Benny Malengier a écrit : > > > guess in most languages this will not have a different wording > than the case of only one of the two being a partner. > > We don't care of inlaw_b on single_relationships, no ? > > > depends of your language. In english/dutch/italian we have > inlaw = inlaw_b or inlaw_a > > and then work with inlaw, so inlaw_b matters. > > Should I add "inlaw_b" to avoid mistakes with partner or UNKNOW > gender ? > Should I remove inlaw_a on this code ? > > > I would use inlaw as constructed above. The spouse of your wifes > daughter in another relation would also be your 'gendre' no? See > rel_it.py who also have specific words for that. > > (gendre = spouse of daughter, beau-père = father of spouse) > > Ga == 0: > if Gb == 0: > .... > elif gender_b == gen.lib.Person.MALE > if in_law_a and Gb == 1: > rel_str = "le gendre" > else: > rel_str = self.get_son(Gb) > elif gender_b == gen.lib.Person.FEMALE > if in_law_a and Gb == 1: > rel_str = "la bru" > else: > rel_str = self.get_daughter(Gb) > elif gender_b == gen.lib.Person.MALE > if in_law_a and Ga == 1: > rel_str = "le beau-père" > else: > rel_str = self.get_father(Ga, inlaw) > elif gender_b == gen.lib.Person.FEMALE and Ga < > len(_mother_level): > if in_law_a and Ga == 1: > rel_str = "la belle-mère" > else: > rel_str = self.get_mother(Ga, inlaw) > > > Maybe like in english (without STEP or INLAW) : "father of spouse" have > the same wording as "second spouse of one parent". > > > > Benny |
From: Benny M. <ben...@gm...> - 2007-11-24 15:51:55
|
MjAwNy8xMS8yNCwgSsOpcsO0bWUgPHJvbWplcm9tZUB5YWhvby5mcj46Cj4KPgo+IEkganVzdCBo YXZlIGEgbWlub3IgIlNURVAgZmFtaWx5IiBpc3N1ZSBvbiBhbGxfcmVsYXRpb25zIGluZm9ybWF0 aW9uczoKPgo+IFVOS05PV04gcmVsYXRpb24gdHlwZSBiZXR3ZWVuIEZBVEhFUiBhbmQgKFNURVAt TU9USEVSKSByZXR1cm5zIHRoZSBzYW1lCj4gdmFsdWUgYXMgaW5sYXc9VHJ1ZSBhbmQgc3RlcD1G YWxzZSAhISEKPgo+IEkgdHJ5IHRvIHVzZToKPgo+IGVsaWYgZ2VuZGVyX2IgPT0gZ2VuLmxpYi5Q ZXJzb24uRkVNQUxFIGFuZCBHYSA8IGxlbihfbW90aGVyX2xldmVsKToKPiAgICAgICAgICAgICAg ICAgaWYgaW5sYXcgYW5kIEdhID09IDEgYW5kIG5vdCBzdGVwOgo+ICAgICAgICAgICAgICAgICAg ICAgcmVsX3N0ciA9ICJsYSBtw6hyZSBkdSBjb25qb2ludCIKPiAgICAgICAgICAgICAgICAgZWxp ZiBzdGVwIGFuZCBHYSA9PSAxIGFuZCBub3QgaW5sYXc6Cj4gICAgICAgICAgICAgICAgICAgICBy ZWxfc3RyID0gImxhIGJlbGxlLW3DqHJlIgo+ICAgICAgICAgICAgICAgICBlbHNlOgo+ICAgICAg ICAgICAgICAgICAgICAgcmVsX3N0ciA9IHNlbGYuZ2V0X21vdGhlcihHYSwgaW5sYXcpCgoKWWVz LCBmb3Igc2libGluZ3MgeW91IHdpbGwgc2VlIHRoZSBjb3JyZWN0IHN0ZXAgdmFsdWUuCkZvciBw ZW9wbGUgd2hvIGFyZSBmdXJ0aGVyIGF3YXkgKG5lcGhld3MsIC4uLiksIEkgaGF2ZSBjaG9zZW4g b24gdGhlIGFsbApyZWxhdGlvbnNoaXBzIHRvIGNvbGxhcHNlIGZhbWlsaWVzIHNvIGZhdGhlciBh bmQgc3RlcG1vdGhlciBpcyBhIGZhbWlseS4gSWYKYSBwZXJzb24gaGFzIGEgYmlydGggcmVsYXRp b24gdG8gb25lIG9mIHRoZSB0d28sIHRoaXMgaXMgaW50ZXJwcmV0ZWQgYXMgYQpiaXJ0aCByZWxh dGlvbiB0byB0aGUgZmFtaWx5LCBhbmQgeW91IG9idGFpbiBoZW5jZSBzdGVwID0gRmFsc2UuCgpO b3RlIHRoYXQgc3RlcCBpcyBmYWxzZSBpcyBvbmx5IHJldHVybmVkIGZvciBwZW9wbGUgd2hvIGhh dmUgdGhhdCBmYW1pbHkgYXMKY29tbW9uIGFuY2VzdG9ycy4gSSBiZWxpZXZlIHRoYXQgaXMgYWNj ZXB0YWJsZSB0cmFkZW9mZiBzbyBhcyBub3QgdG8gYWRkCm1vcmUgY29tcGxleGl0eSBpbiB0aGUg YWxnb3JpdGhtcy4gVGhhdCBpcyB0aGUgc2libGluZ3MgYXQgdG9wIGxldmVsIHVuZGVyCmNvbW1v biBhbmNlc3RvcnMgY2FuIGJlIGhhbGYgc2libGluZ3Mgb3Igc3RlcCBzaWJsaW5ncy4gVGhlIGhh bGYgc2libGluZ3MKd291bGQgY2F1c2UgZWcgbmVwaGV3cyAoYW5kIG5vdCAzLzQgbmVwaGV3cyA7 LSkgKSwgdGhlIHN0ZXAgc2libGluZ3Mgd291bGQKY2F1c2Ugc3RlcCBzaWJsaW5ncy4KSXQgd291 bGQgYmUgY29tcGxpY2F0ZWQuIE5vdGUgZnVydGhlciB0aGF0IGFsbCByZWxhdGlvbnNoaXBzIGdp dmVzIGluIHRoZQpkZXRhaWxzOiBQYXJlbnRzLCBiaXJ0aCBZZXMuIFNvIHRoaXMgbWVhbnMgbWVh bnMgYmlydGggdG8gYXQgbGVhc3Qgb25lCnBhcmVudC4KCkkgYWdyZWUsIGl0IGlzIG5vdCBhIHNl Y29uZCBtYXJyaWFnZSwganVzdCBhbiBvdGhlciBzcG91c2UvcGFydG5lci4KPiA+IFRyYWRpdGlv bmFsbHksIGEgc3RlcGZhbWlseSBpcyB0aGUgZmFtaWx5IG9uZSBhY3F1aXJlcyB3aGVuIGEgcGFy ZW50Cj4gZW50ZXJzIGEgbmV3IG1hcnJpYWdlLCB3aGV0aGVyIHRoZSBwYXJlbnQgd2FzIHdpZG93 ZWQgb3IgZGl2b3JjZWQuCj4gaHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9TdGVwZmFtaWx5 Cj4KPiBEb2VzIGl0IG1lYW4gdGhhdCBTVEVQIGlzIG9ubHkgZm9yIGZhbWlseV90eXBlID0gTUFS UklFRCBhbmQgd2UgaWdub3JlCj4gVU5NQVJSSUVELCBDSVZJTF9VTklPTiwgVU5LTk9XTiwgQ1VT VE9NID8KCgpTVEVQIGlzIGZvciBhbGwgcmVsYXRpb24gdHlwZXMuICBJdCBkZXBlbmRzIG9ubHkg b24gdGhlIGNvbW1vbiBhbmNlc3RvcnMgb2YKYSBmYW1pbHkgaWYgaXQgaXMgZ2l2ZW4uCgoKQmVu bnkK |
From: <rom...@ya...> - 2007-11-29 18:43:56
|
Benny, There is an issue with all_relation and inlaw. It is a particular relation/situation. I don't have a testcase database yet, but i could try to explain: a. I would like to display inlaw informations between my mother and my great-father (father side). My parents are married. b. all_relations quick report just displays normal relation : common ancestors 13th degree for my mother and 10th degree my great-father (father side). c. but inlaw relation is ignored !!! (and only between this two persons) I found a solution by cutting a branch of my family tree !!! After that, I get my inlaw relation. Maybe I know why : My great-father have two number 3, which means there is collapse (inbreeding) on his ancestor tree ... shame that ancestors_path was with the same common ancestors as my mother. Why should I remove a branch on active person, collapse are on home person ? Also, maybe we might try to display paths like EndOfLine reports (two or tree lines and data with a separator). I have difficulties to navigate with multiples common relations (height too large) And seems that dictionary/lists wasn't refreshed on all_relations. Without parents data my mother should not keep common ancestors with my great-father (except inlaw). Normal relation is still displayed after broken branch. True, it was during test (not standard use) and maybe for saving memory. PS: I will try to generate a testcase database Benny Malengier a écrit : > > > 2007/11/24, Jérôme <rom...@ya... <mailto:rom...@ya...>>: > > > I just have a minor "STEP family" issue on all_relations informations: > > UNKNOWN relation type between FATHER and (STEP-MOTHER) returns the same > value as inlaw=True and step=False !!! > > I try to use: > > elif gender_b == gen.lib.Person.FEMALE and Ga < len(_mother_level): > if inlaw and Ga == 1 and not step: > rel_str = "la mère du conjoint" > elif step and Ga == 1 and not inlaw: > rel_str = "la belle-mère" > else: > rel_str = self.get_mother(Ga, inlaw) > > > Yes, for siblings you will see the correct step value. > For people who are further away (nephews, ...), I have chosen on the all > relationships to collapse families so father and stepmother is a family. > If a person has a birth relation to one of the two, this is interpreted > as a birth relation to the family, and you obtain hence step = False. > > Note that step is false is only returned for people who have that family > as common ancestors. I believe that is acceptable tradeoff so as not to > add more complexity in the algorithms. That is the siblings at top level > under common ancestors can be half siblings or step siblings. The half > siblings would cause eg nephews (and not 3/4 nephews ;-) ), the step > siblings would cause step siblings. > It would be complicated. Note further that all relationships gives in > the details: Parents, birth Yes. So this means means birth to at least > one parent. > > I agree, it is not a second marriage, just an other spouse/partner. > > Traditionally, a stepfamily is the family one acquires when a > parent enters a new marriage, whether the parent was widowed or > divorced. > http://en.wikipedia.org/wiki/Stepfamily > > Does it mean that STEP is only for family_type = MARRIED and we ignore > UNMARRIED, CIVIL_UNION, UNKNOWN, CUSTOM ? > > > STEP is for all relation types. It depends only on the common ancestors > of a family if it is given. > > > Benny |
From: Josip <jo...@pi...> - 2007-11-23 21:27:15
|
Benny Malengier wrote: > Both true means you have person A and person B. The partner of person A > is related to the partner of person B. > I guess in most languages this will not have a different wording than > the case of only one of the two being a partner. > Sorry still don't understand, how they are related. For example rel_str is: 0,1,1,1,,f,True,False,False that is my son, 0,1,1,0,,f,True,False,True is my son's wife, 0,1,1,0,,m,True,True,True who is that person, thats what all_relationship QR show as another inlaw when checking son's wife? > Note that in most languages the terminology does not really exist > outside the direct family. However, for genealogy reasons it is > interesting to see a relationship, and use the same rules of close > family to family many generations away. For performance reasons in-law > relationships are only visible in the quick report 'relationship to home > person'. > Performance reasons? Is it slow, really slow or really really slow? If not the third it would be nice to be included in RelCalc. > Also note that it is not needed to have different words for everything > if that does not exist in you language. Kinship system of my language is descriptive one and i would like to include as much relationship as possible. Eg, in Italian one does not > distinguish between half-brother and stepbrother. That is a pity from > the point of view of conveying information, but cannot be helped without > sounding unnatural. > -- Josip |
From: Benny M. <ben...@gm...> - 2007-11-23 21:44:21
|
2007/11/24, Josip <jo...@pi...>: > > Benny Malengier wrote: > > Both true means you have person A and person B. The partner of person A > > is related to the partner of person B. > > I guess in most languages this will not have a different wording than > > the case of only one of the two being a partner. > > > > Sorry still don't understand, how they are related. > For example rel_str is: > 0,1,1,1,,f,True,False,False that is my son, > 0,1,1,0,,f,True,False,True is my son's wife, > 0,1,1,0,,m,True,True,True who is that person, thats what If your wife has a son in another relation that is not part of a family with you as father, it would be the wife of the son of your wife. That is, there is no link from you to that person. So it would be a daughter-in-law because for you wife it is a full son. all_relationship QR show as another inlaw when checking son's wife? > > > Note that in most languages the terminology does not really exist > > outside the direct family. However, for genealogy reasons it is > > interesting to see a relationship, and use the same rules of close > > family to family many generations away. For performance reasons in-law > > relationships are only visible in the quick report 'relationship to home > > > person'. > > > > Performance reasons? > Is it slow, really slow or really really slow? If not the third it would > be nice to be included in RelCalc. You need to search 3 extra branches, for people who had several wifes even more. The optimization code and cashing code no longer work with a simple implementation, so it must be designed somewhat so as not to loose the speedup of simple caching. I was thinking of perhaps a checkbox on relcalc tool. However, I want to concentrate on other parts of the code now. If nobody else does it, I can do it in the future. I think Rob already made a feature request for it. Benny |
From: Rob G. H. <rob...@gm...> - 2007-11-24 01:45:11
|
Hello Josip: I agree with you unless it is really really slow, I would like to see as much of Relationships as I can....on all parts of Gramps....... Sincerely, Rob On Fri, 2007-11-23 at 23:28 -0800, Josip wrote: > Benny Malengier wrote: > > Both true means you have person A and person B. The partner of person A= =20 > > is related to the partner of person B. > > I guess in most languages this will not have a different wording than=20 > > the case of only one of the two being a partner. > >=20 >=20 > Sorry still don't understand, how they are related. > For example rel_str is: > 0,1,1,1,,f,True,False,False that is my son, > 0,1,1,0,,f,True,False,True is my son's wife, > 0,1,1,0,,m,True,True,True who is that person, thats what=20 > all_relationship QR show as another inlaw when checking son's wife? >=20 > > Note that in most languages the terminology does not really exist=20 > > outside the direct family. However, for genealogy reasons it is=20 > > interesting to see a relationship, and use the same rules of close=20 > > family to family many generations away. For performance reasons in-law=20 > > relationships are only visible in the quick report 'relationship to hom= e=20 > > person'. > >=20 >=20 > Performance reasons? > Is it slow, really slow or really really slow? If not the third it would=20 > be nice to be included in RelCalc. >=20 > > Also note that it is not needed to have different words for everything=20 > > if that does not exist in you language. >=20 > Kinship system of my language is descriptive one and i would like to=20 > include as much relationship as possible. >=20 > Eg, in Italian one does not > > distinguish between half-brother and stepbrother. That is a pity from=20 > > the point of view of conveying information, but cannot be helped withou= t=20 > > sounding unnatural. > >=20 >=20 --=20 Sincerely Yours, Rob G. Healey .... _ ... (0)> ... / / \ .. / / . ) .. V_/_ Linux Powered! ********************************************* "If you read the same things as others and say the same things they say, then you're perceived as intelligent. I'm a bit more independent and radical and consider intelligence the ability to think about matters on your own and=20 ask a lot of skeptical questions to=20 get at the real truth, not just what you're told it is." Apple's Inventor - Steve Wozniak 2006 ********************************************* |
From: Josip <jo...@pi...> - 2007-11-23 22:12:10
|
Benny Malengier wrote: > I was thinking of perhaps a checkbox on relcalc tool. However, I want to > concentrate on other parts of the code now. If nobody else does it, I > can do it in the future. I think Rob already made a feature request for it. > When talking about feature request is it possible to have two different p1 and p2 variables depending on if is relationship found or not in on_apply_clicked() which will be accessible to user to modify name (do declination on name and surname) -- Josip |
From: Benny M. <ben...@gm...> - 2007-11-24 09:08:31
|
Josip, this is unclear to me. Can you elaborate? We have: p1 = name_displayer.display(self.person) p2 = name_displayer.display(other_person) Do you mean the name displayer should be able to do declination? Is it not possible to do that in the not related sentence: str = _("%(person)s and %(active_person)s are not related.") % { 'person' : p2, 'active_person' : p1 } Please, do you feature request, but perhaps first give an example here in your language about what the problem is, so we understand each other. Benny 2007/11/24, Josip <jo...@pi...>: > > Benny Malengier wrote: > > > I was thinking of perhaps a checkbox on relcalc tool. However, I want to > > concentrate on other parts of the code now. If nobody else does it, I > > can do it in the future. I think Rob already made a feature request for > it. > > > > When talking about feature request is it possible to have two different > p1 and p2 variables depending on if is relationship found or not in > on_apply_clicked() which will be accessible to user to modify name (do > declination on name and surname) > > -- > Josip > |
From: Josip <jo...@pi...> - 2007-11-24 09:58:26
|
Benny Malengier wrote: > Josip, this is unclear to me. Can you elaborate? > We have: > > p1 = name_displayer.display(self.person) > p2 = name_displayer.display(other_person) > > Do you mean the name displayer should be able to do declination? > Is it not possible to do that in the not related sentence: > > str = _("%(person)s and %(active_person)s are not related.") % { > 'person' : p2, 'active_person' : p1 } > > Please, do you feature request, but perhaps first give an example here > in your language about what the problem is, so we understand each other. > > If A not related to B: "PersonA i Josip nisu u srodstvu" name case not change If A is grandfather of B: "PersonA je djed Josipa" name change from nominative case to genitive In this two sentence name have different form so i would like to their named variable also to be different. And possibility to somehow access them and change males name and surname with rules for males, change only female names with rule for female names. In my language we do declination of person names, place names and ordinal numbers. -- Josip |
From: Benny M. <ben...@gm...> - 2007-11-24 12:58:54
|
Josip, what you ask is very advanced and not included. Feel free to suggest something but no ideas come to my mind on how to do it. I would suggest you make the sentence such that genetive is not needed. That is, name_display routine gives the name as in gramps. It is not capable of constructing a genetive. Futhermore, relcalc is a tool which we don't want to localize with different versions. So the rel_xx.py should contain the code to do that depending on the language. Is it really not possible to give a different sentence construction so that the problem does not arise. Eg ' person a, person b: not related' It is a very different translation, but would be correct and not require some complicated programming from our part. Benny > No it wouldn't work with gettext like that, declination rules are much > more complicated. I need to somehow override those p1 and p2 like > overriding get_single_relationship_string() take those two person or > their handle and extract their names and surnames and passed it to > function which will do declination magic. > > -- Josip > |
From: Josip <jo...@pi...> - 2007-11-24 14:11:41
|
Benny Malengier wrote: > Josip, > > what you ask is very advanced and not included. > Feel free to suggest something but no ideas come to my mind on how to do it. > Thanks for your effort! My knowledge of English and Python is insufficient to properly explain it. But discovered how to create new class in my rel_xx.py which inherit from RelCalc, then put original on_apply_clicked() fuction in it and have access to that p1 and p2 variables when this new class is registered with register_tool. Now will tray to extract name and surnames from it and write function for their declination. Problem is it will not reflect any change in original on_apply_clicked() fuction but when i finish maybe will be more understandable what i wont. > I would suggest you make the sentence such that genetive is not needed. > That is, name_display routine gives the name as in gramps. It is not > capable of constructing a genetive. > Futhermore, relcalc is a tool which we don't want to localize with > different versions. So the rel_xx.py should contain the code to do that > depending on the language. > > Is it really not possible to give a different sentence construction so > that the problem does not arise. Eg > ' person a, person b: not related' Problem is when they are related. Sentence like "personA, personB: grandfather" is ugly and unnatural. Order of words in sentence is irrelevant in my language because logic depends on declination of those words. > It is a very different translation, but would be correct and not require > some complicated programming from our part. > Did not mean to give developers lot of extra work but probably wrongly explained it. -- Josip |
From: Benny M. <ben...@gm...> - 2007-11-24 15:37:27
|
Josip, we want to keep localization minimized, so RelCacl should be one module, using rel_xx.py to do language specific things. For what you you want I see two needs: 1/name displayer must be able to take a name and return conjugated form. So that would mean we can give an extra parameter to name displayer with the 'form'. If form = genetive, it returns the name different, depending on the language. This is a complicated thing. 2/Less complicated is using this then in the rel_xx modules and tools. Eg, we now have: _("%(person)s is the %(relation) of %(active_person_male)s") % { 'person' : p2, 'active_person' : p1 } We can change that to: _("Use in next person or person_genitive, and active_person or active_person_genetive |%(person)s is the %(relation) of %(active_person_male)s") % { 'person' : p2, 'active_person' : p1, 'person'_genitive : p2_gen, 'active_person_genetive' : p1_gen } which in English would eg still show 'Martha is the aunt of Ben' We could even only calculate p1_gen and p2_gen if in rel_xx.py a flag is set to reduce impact of this on languages not needing it, eg: def use_genetive_names(self): return False which in your language would be made True to make the magic work. As you see, 2/ is not that hard, the hard part is to do 1/, so to rewrite the name displayer to return the genitive form for a language. See src/BasicUtils/_NameDisplay.py to see this is complicated code already. Benny . 2007/11/25, Josip <jo...@pi...>: > > Benny Malengier wrote: > > Josip, > > > > what you ask is very advanced and not included. > > Feel free to suggest something but no ideas come to my mind on how to do > it. > > > Thanks for your effort! > > My knowledge of English and Python is insufficient to properly explain > it. But discovered how to create new class in my rel_xx.py which inherit > from RelCalc, then put original on_apply_clicked() fuction in it and > have access to that p1 and p2 variables when this new class is > registered with register_tool. Now will tray to extract name and > surnames from it and write function for their declination. > > Problem is it will not reflect any change in original on_apply_clicked() > fuction but when i finish maybe will be more understandable what i wont. > > > I would suggest you make the sentence such that genetive is not needed. > > That is, name_display routine gives the name as in gramps. It is not > > capable of constructing a genetive. > > Futhermore, relcalc is a tool which we don't want to localize with > > different versions. So the rel_xx.py should contain the code to do that > > depending on the language. > > > > Is it really not possible to give a different sentence construction so > > that the problem does not arise. Eg > > ' person a, person b: not related' > > Problem is when they are related. > Sentence like "personA, personB: grandfather" is ugly and unnatural. > Order of words in sentence is irrelevant in my language because logic > depends on declination of those words. > > > It is a very different translation, but would be correct and not require > > some complicated programming from our part. > > > > Did not mean to give developers lot of extra work but probably wrongly > explained it. > > -- > Josip > |
From: Benny M. <ben...@gm...> - 2007-11-29 22:36:10
|
SmVyb21lLAoKSSBoYXZlIHdyaXR0ZW4gdGhlIHF1aWNrIHJlcG9ydCBzbyB0aGF0IGlubGF3IHJl bGF0aW9ucyBhcmUgbm90IHNlYXJjaGVkIGlmCmEgbm9ybWFsIHJlbGF0aW9uIGlzIGZvdW5kLgpT byB3aGF0IHlvdSBkZXNjcmliZSBpcyB0byBiZSBleHBlY3RlZC4KClRvIHNlZSBpZiBhbGwgd29y a3MsIGluIGFsbF9yZWxhdGlvbnMucHksIGdvIHRvIGxpbmUgMTE3IGFuZCByZW1vdmUgdGhlCnN0 b3A6CgogICAgICAgZWxzZToKICAgICAgICAgICAgI3N0b3AKICAgICAgICAgICAgcmV0dXJuCgpB ZnRlciB5b3UgcmVtb3ZlZCB0aGlzIGVsc2UgYnJhbmNoLCBub3JtYWwgYW5kIGlubGF3IHJlbGF0 aW9ucyBzaG91bGQgYWx3YXlzCmJlIGNhbGN1bGF0ZWQuCkFtIEkgY29ycmVjdD8KCkJlbm55Cgoy MDA3LzExLzI5LCBKw6lyw7RtZSA8cm9tamVyb21lQHlhaG9vLmZyPjoKPgo+IEJlbm55LAo+Cj4K PiBUaGVyZSBpcyBhbiBpc3N1ZSB3aXRoIGFsbF9yZWxhdGlvbiBhbmQgaW5sYXcuIEl0IGlzIGEg cGFydGljdWxhcgo+IHJlbGF0aW9uL3NpdHVhdGlvbi4gSSBkb24ndCBoYXZlIGEgdGVzdGNhc2Ug ZGF0YWJhc2UgeWV0LCBidXQgaSBjb3VsZAo+IHRyeSB0byBleHBsYWluOgo+Cj4gYS4gSSB3b3Vs ZCBsaWtlIHRvIGRpc3BsYXkgaW5sYXcgaW5mb3JtYXRpb25zIGJldHdlZW4gbXkgbW90aGVyIGFu ZCBteQo+IGdyZWF0LWZhdGhlciAoZmF0aGVyIHNpZGUpLiBNeSBwYXJlbnRzIGFyZSBtYXJyaWVk Lgo+Cj4gYi4gYWxsX3JlbGF0aW9ucyBxdWljayByZXBvcnQganVzdCBkaXNwbGF5cyBub3JtYWwg cmVsYXRpb24gOiBjb21tb24KPiBhbmNlc3RvcnMgMTN0aCBkZWdyZWUgZm9yIG15IG1vdGhlciBh bmQgMTB0aCBkZWdyZWUgbXkgZ3JlYXQtZmF0aGVyCj4gKGZhdGhlciBzaWRlKS4KPgo+IGMuIGJ1 dCBpbmxhdyByZWxhdGlvbiBpcyBpZ25vcmVkICEhIQo+IChhbmQgb25seSBiZXR3ZWVuIHRoaXMg dHdvIHBlcnNvbnMpCj4KPgo+IEkgZm91bmQgYSBzb2x1dGlvbiBieSBjdXR0aW5nIGEgYnJhbmNo IG9mIG15IGZhbWlseSB0cmVlICEhIQo+IEFmdGVyIHRoYXQsIEkgZ2V0IG15IGlubGF3IHJlbGF0 aW9uLiBNYXliZSBJIGtub3cgd2h5IDoKPgo+IE15IGdyZWF0LWZhdGhlciBoYXZlIHR3byBudW1i ZXIgMywgd2hpY2ggbWVhbnMgdGhlcmUgaXMgY29sbGFwc2UKPiAoaW5icmVlZGluZykgb24gaGlz IGFuY2VzdG9yIHRyZWUgLi4uIHNoYW1lIHRoYXQgYW5jZXN0b3JzX3BhdGggd2FzIHdpdGgKPiB0 aGUgc2FtZSBjb21tb24gYW5jZXN0b3JzIGFzIG15IG1vdGhlci4KPgo+Cj4gV2h5IHNob3VsZCBJ IHJlbW92ZSBhIGJyYW5jaCBvbiBhY3RpdmUgcGVyc29uLCBjb2xsYXBzZSBhcmUgb24gaG9tZSBw ZXJzb24KPiA/Cj4KPiBBbHNvLCBtYXliZSB3ZSBtaWdodCB0cnkgdG8gZGlzcGxheSBwYXRocyBs aWtlIEVuZE9mTGluZSByZXBvcnRzICh0d28gb3IKPiB0cmVlIGxpbmVzIGFuZCBkYXRhIHdpdGgg YSBzZXBhcmF0b3IpLiBJIGhhdmUgZGlmZmljdWx0aWVzIHRvIG5hdmlnYXRlCj4gd2l0aCBtdWx0 aXBsZXMgY29tbW9uIHJlbGF0aW9ucyAoaGVpZ2h0IHRvbyBsYXJnZSkKPgo+IEFuZCBzZWVtcyB0 aGF0IGRpY3Rpb25hcnkvbGlzdHMgd2Fzbid0IHJlZnJlc2hlZCBvbiBhbGxfcmVsYXRpb25zLgo+ IFdpdGhvdXQgcGFyZW50cyBkYXRhIG15IG1vdGhlciBzaG91bGQgbm90IGtlZXAgY29tbW9uIGFu Y2VzdG9ycyB3aXRoIG15Cj4gZ3JlYXQtZmF0aGVyIChleGNlcHQgaW5sYXcpLiBOb3JtYWwgcmVs YXRpb24gaXMgc3RpbGwgZGlzcGxheWVkIGFmdGVyCj4gYnJva2VuIGJyYW5jaC4gVHJ1ZSwgaXQg d2FzIGR1cmluZyB0ZXN0IChub3Qgc3RhbmRhcmQgdXNlKSBhbmQgbWF5YmUgZm9yCj4gc2F2aW5n IG1lbW9yeS4KPgo+Cj4KPiBQUzogSSB3aWxsIHRyeSB0byBnZW5lcmF0ZSBhIHRlc3RjYXNlIGRh dGFiYXNlCj4KPgo+IEJlbm55IE1hbGVuZ2llciBhIMOpY3JpdCA6Cj4gPgo+ID4KPiA+IDIwMDcv MTEvMjQsIErDqXLDtG1lIDxyb21qZXJvbWVAeWFob28uZnIgPG1haWx0bzpyb21qZXJvbWVAeWFo b28uZnI+PjoKPiA+Cj4gPgo+ID4gICAgIEkganVzdCBoYXZlIGEgbWlub3IgIlNURVAgZmFtaWx5 IiBpc3N1ZSBvbiBhbGxfcmVsYXRpb25zCj4gaW5mb3JtYXRpb25zOgo+ID4KPiA+ICAgICBVTktO T1dOIHJlbGF0aW9uIHR5cGUgYmV0d2VlbiBGQVRIRVIgYW5kIChTVEVQLU1PVEhFUikgcmV0dXJu cyB0aGUKPiBzYW1lCj4gPiAgICAgdmFsdWUgYXMgaW5sYXc9VHJ1ZSBhbmQgc3RlcD1GYWxzZSAh ISEKPiA+Cj4gPiAgICAgSSB0cnkgdG8gdXNlOgo+ID4KPiA+ICAgICBlbGlmIGdlbmRlcl9iID09 IGdlbi5saWIuUGVyc29uLkZFTUFMRSBhbmQgR2EgPCBsZW4oX21vdGhlcl9sZXZlbCk6Cj4gPiAg ICAgICAgICAgICAgICAgICAgIGlmIGlubGF3IGFuZCBHYSA9PSAxIGFuZCBub3Qgc3RlcDoKPiA+ ICAgICAgICAgICAgICAgICAgICAgICAgIHJlbF9zdHIgPSAibGEgbcOocmUgZHUgY29uam9pbnQi Cj4gPiAgICAgICAgICAgICAgICAgICAgIGVsaWYgc3RlcCBhbmQgR2EgPT0gMSBhbmQgbm90IGlu bGF3Ogo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgcmVsX3N0ciA9ICJsYSBiZWxsZS1tw6hy ZSIKPiA+ICAgICAgICAgICAgICAgICAgICAgZWxzZToKPiA+ICAgICAgICAgICAgICAgICAgICAg ICAgIHJlbF9zdHIgPSBzZWxmLmdldF9tb3RoZXIoR2EsIGlubGF3KQo+ID4KPiA+Cj4gPiBZZXMs IGZvciBzaWJsaW5ncyB5b3Ugd2lsbCBzZWUgdGhlIGNvcnJlY3Qgc3RlcCB2YWx1ZS4KPiA+IEZv ciBwZW9wbGUgd2hvIGFyZSBmdXJ0aGVyIGF3YXkgKG5lcGhld3MsIC4uLiksIEkgaGF2ZSBjaG9z ZW4gb24gdGhlIGFsbAo+ID4gcmVsYXRpb25zaGlwcyB0byBjb2xsYXBzZSBmYW1pbGllcyBzbyBm YXRoZXIgYW5kIHN0ZXBtb3RoZXIgaXMgYSBmYW1pbHkuCj4gPiBJZiBhIHBlcnNvbiBoYXMgYSBi aXJ0aCByZWxhdGlvbiB0byBvbmUgb2YgdGhlIHR3bywgdGhpcyBpcyBpbnRlcnByZXRlZAo+ID4g YXMgYSBiaXJ0aCByZWxhdGlvbiB0byB0aGUgZmFtaWx5LCBhbmQgeW91IG9idGFpbiBoZW5jZSBz dGVwID0gRmFsc2UuCj4gPgo+ID4gTm90ZSB0aGF0IHN0ZXAgaXMgZmFsc2UgaXMgb25seSByZXR1 cm5lZCBmb3IgcGVvcGxlIHdobyBoYXZlIHRoYXQgZmFtaWx5Cj4gPiBhcyBjb21tb24gYW5jZXN0 b3JzLiBJIGJlbGlldmUgdGhhdCBpcyBhY2NlcHRhYmxlIHRyYWRlb2ZmIHNvIGFzIG5vdCB0bwo+ ID4gYWRkIG1vcmUgY29tcGxleGl0eSBpbiB0aGUgYWxnb3JpdGhtcy4gVGhhdCBpcyB0aGUgc2li bGluZ3MgYXQgdG9wIGxldmVsCj4gPiB1bmRlciBjb21tb24gYW5jZXN0b3JzIGNhbiBiZSBoYWxm IHNpYmxpbmdzIG9yIHN0ZXAgc2libGluZ3MuIFRoZSBoYWxmCj4gPiBzaWJsaW5ncyB3b3VsZCBj YXVzZSBlZyBuZXBoZXdzIChhbmQgbm90IDMvNCBuZXBoZXdzIDstKSApLCB0aGUgc3RlcAo+ID4g c2libGluZ3Mgd291bGQgY2F1c2Ugc3RlcCBzaWJsaW5ncy4KPiA+IEl0IHdvdWxkIGJlIGNvbXBs aWNhdGVkLiBOb3RlIGZ1cnRoZXIgdGhhdCBhbGwgcmVsYXRpb25zaGlwcyBnaXZlcyBpbgo+ID4g dGhlIGRldGFpbHM6IFBhcmVudHMsIGJpcnRoIFllcy4gU28gdGhpcyBtZWFucyBtZWFucyBiaXJ0 aCB0byBhdCBsZWFzdAo+ID4gb25lIHBhcmVudC4KPiA+Cj4gPiAgICAgSSBhZ3JlZSwgaXQgaXMg bm90IGEgc2Vjb25kIG1hcnJpYWdlLCBqdXN0IGFuIG90aGVyIHNwb3VzZS9wYXJ0bmVyLgo+ID4g ICAgID4gVHJhZGl0aW9uYWxseSwgYSBzdGVwZmFtaWx5IGlzIHRoZSBmYW1pbHkgb25lIGFjcXVp cmVzIHdoZW4gYQo+ID4gICAgIHBhcmVudCBlbnRlcnMgYSBuZXcgbWFycmlhZ2UsIHdoZXRoZXIg dGhlIHBhcmVudCB3YXMgd2lkb3dlZCBvcgo+ID4gICAgIGRpdm9yY2VkLgo+ID4gICAgIGh0dHA6 Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvU3RlcGZhbWlseQo+ID4KPiA+ICAgICBEb2VzIGl0IG1l YW4gdGhhdCBTVEVQIGlzIG9ubHkgZm9yIGZhbWlseV90eXBlID0gTUFSUklFRCBhbmQgd2UKPiBp Z25vcmUKPiA+ICAgICBVTk1BUlJJRUQsIENJVklMX1VOSU9OLCBVTktOT1dOLCBDVVNUT00gPwo+ ID4KPiA+Cj4gPiBTVEVQIGlzIGZvciBhbGwgcmVsYXRpb24gdHlwZXMuICBJdCBkZXBlbmRzIG9u bHkgb24gdGhlIGNvbW1vbiBhbmNlc3RvcnMKPiA+IG9mIGEgZmFtaWx5IGlmIGl0IGlzIGdpdmVu Lgo+ID4KPiA+Cj4gPiBCZW5ueQo+Cg== |
From: <rom...@ya...> - 2007-11-30 08:53:44
|
Benny, > I have written the quick report so that inlaw relations are not searched if a normal relation is found. I have an other problem ... Most inlaw relations are not alone on my database, there is normal relations too. Sometimes, "inlaw" are the first number on listing, sometimes the last of the list. (1. or 6.7.) > After you removed this else branch, normal and inlaw relations should > always be calculated. > Am I correct? Not in my case. Same problem :( I cannot get inlaw relation after removing "else" block. I will provide a testcase database. Benny Malengier a écrit : > Jerome, > > I have written the quick report so that inlaw relations are not searched > if a normal relation is found. > So what you describe is to be expected. > > To see if all works, in all_relations.py, go to line 117 and remove the > stop: > > else: > #stop > return > > After you removed this else branch, normal and inlaw relations should > always be calculated. > Am I correct? > > Benny > > 2007/11/29, Jérôme <rom...@ya... <mailto:rom...@ya...>>: > > Benny, > > > There is an issue with all_relation and inlaw. It is a particular > relation/situation. I don't have a testcase database yet, but i could > try to explain: > > a. I would like to display inlaw informations between my mother and my > great-father (father side). My parents are married. > > b. all_relations quick report just displays normal relation : common > ancestors 13th degree for my mother and 10th degree my great-father > (father side). > > c. but inlaw relation is ignored !!! > (and only between this two persons) > > > I found a solution by cutting a branch of my family tree !!! > After that, I get my inlaw relation. Maybe I know why : > > My great-father have two number 3, which means there is collapse > (inbreeding) on his ancestor tree ... shame that ancestors_path was with > the same common ancestors as my mother. > > > Why should I remove a branch on active person, collapse are on home > person ? > > Also, maybe we might try to display paths like EndOfLine reports > (two or > tree lines and data with a separator). I have difficulties to navigate > with multiples common relations (height too large) > > And seems that dictionary/lists wasn't refreshed on all_relations. > Without parents data my mother should not keep common ancestors with my > great-father (except inlaw). Normal relation is still displayed after > broken branch. True, it was during test (not standard use) and maybe for > saving memory. > > > > PS: I will try to generate a testcase database > > > Benny Malengier a écrit : > > > > > > 2007/11/24, Jérôme <rom...@ya... <mailto:rom...@ya...> > <mailto:rom...@ya... <mailto:rom...@ya...>>>: > > > > > > I just have a minor "STEP family" issue on all_relations > informations: > > > > UNKNOWN relation type between FATHER and (STEP-MOTHER) returns > the same > > value as inlaw=True and step=False !!! > > > > I try to use: > > > > elif gender_b == gen.lib.Person.FEMALE and Ga < > len(_mother_level): > > if inlaw and Ga == 1 and not step: > > rel_str = "la mère du conjoint" > > elif step and Ga == 1 and not inlaw: > > rel_str = "la belle-mère" > > else: > > rel_str = self.get_mother (Ga, inlaw) > > > > > > Yes, for siblings you will see the correct step value. > > For people who are further away (nephews, ...), I have chosen on > the all > > relationships to collapse families so father and stepmother is a > family. > > If a person has a birth relation to one of the two, this is > interpreted > > as a birth relation to the family, and you obtain hence step = False. > > > > Note that step is false is only returned for people who have that > family > > as common ancestors. I believe that is acceptable tradeoff so as > not to > > add more complexity in the algorithms. That is the siblings at top > level > > under common ancestors can be half siblings or step siblings. The > half > > siblings would cause eg nephews (and not 3/4 nephews ;-) ), the step > > siblings would cause step siblings. > > It would be complicated. Note further that all relationships gives in > > the details: Parents, birth Yes. So this means means birth to at > least > > one parent. > > > > I agree, it is not a second marriage, just an other > spouse/partner. > > > Traditionally, a stepfamily is the family one acquires when a > > parent enters a new marriage, whether the parent was widowed or > > divorced. > > http://en.wikipedia.org/wiki/Stepfamily > > > > Does it mean that STEP is only for family_type = MARRIED and > we ignore > > UNMARRIED, CIVIL_UNION, UNKNOWN, CUSTOM ? > > > > > > STEP is for all relation types. It depends only on the common > ancestors > > of a family if it is given. > > > > > > Benny > > |