The idea is that no logic is in the translation but the bare necessity needed by the language.
Now the rel_xx have an implementation of get_relationship
That code calls the actual algorithm (get_relationship_distance ), and does some preinit stuff.
I removed a bug and added a feature to the english get_relationship method, no way I will do all rel_xx.py code !
That means, the rel_xx.py modules should _not_ do any logic, they should only return strings after code from Relationship.py has calculated the path between two individuals.
Hence, they should only contain of the functions in Relationship.py (with help functions if needed of course):
def get_cousin(self, level, removed):
def get_parents(self, level):
def get_father(self, level):
def get_son(self, level):
def get_mother(self, level):
def get_daughter(self, level):
def get_aunt(self, level):
def get_uncle(self, level):
def get_nephew(self, level):
def get_niece(self, level):
def is_spouse(self, db, orig, other):
def get_plural_relationship_string(self, Ga, Gb)
def get_single_relationship_string(self, Ga, Gb, gender_a, gender_b,
I'd like to cut out the logic of is_spouse, it should be possible to do that better. I will still add to get_single_relationship_string the complete path to arrive at common ancestor as some languages need that for their translation.
I do not see in the rel_xx modules any reason we need some logic in get_relationship that get_single_relationship_string could not handle.
I'll try to do rel_nl.py as an example tonight and tomorrow. You can use that as example for rewrite of rel_fr.py.
If you wonder why change this? First is bug fixes, if the bug is logic, then it should only be fixed in Relationship.py, if translation, in rel_xx.py. Next, new functionality. I can easily hack in to also check the in-law family when checking for relationship (brother in law ....), but not with the present way of rel_xx.py.
I can have the code in place to check for stepbrothers and such easily (look at rel_pl.py of how this is hacked in by Piotr), ... . By going this way, we encourage translators to submit patches that all languages benefit from, instead of things hacked into one language only.
I have the same issue ...
"Relationships to home" quick report seems to use the same code as status
bar ("Relationships to home" on display preferences)
Both do not return (or use) local relationships calculator and we get
english strings (father, mother, (up) once removed, etc ...)
I do not know if there is an .ini value who should be activated or/and we
need an installation for getting translated strings. But current code ignore
localized relationships calculator.
Status bar was "english-only" for many months ...
Seems you call the same function, which don't translate strings yet.
Also, for having a full translation on "kinship report", you need to add new
get_relationships_ on rel_xx. But what is about this report ? Should we use
plural or single get_relationships ?
I agree, gramps may ignore (old) code : both retrieve the same data. But I
cannot say which one is the most easy or user-friendly !!! I don't see any
wrong method on old code, I adapt to both (rel_fr).
Seems I can remove definition who is now using translation strings
_(undefined) ;) but I don't understand what should be done on rel_xx ?
Could we remove (old) code, should we still play with get_plural
Peter Landgren wrote:
>> You could go into the po directory of trunk, and do make install there.
>> Then when finished, go into the po directory of branch22 and do make
>> install there to again have the translation for 2.2.x
> OK, But as I run trunk on another system, this is not a problem.
>> Note that relationships are in a separate file, here rel_sv.py, which
>> inherits from src/Relationship.py.
> Ues, I know.
>> With the change I did, rel_sv.py should still work as before and show
>> correct translation inthose modules using get_relationship.
> No, rel_sv.py does not work. I always get the English relationship words
> trunk? (The file excists.)
> 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-devel mailing list
View this message in context: http://www.nabble.com/relationship-changes-tf4680545.html#a13406444
Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
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-devel mailing list