Relationship Calculator

From Gramps
Revision as of 03:17, 3 March 2012 by Romjerome (Talk | contribs)

Jump to: navigation, search

Rationale and requirements for the Relationship Calculator plugin for GRAMPS, and its localisation.

Why have different relationship calculators?

Different cultures and regions tend to view relationships in different ways. In the United States (and probably other English speaking regions), you can encounter a third cousin, twice removed, which in other regions is meaningless. Other cultures have different terms for your mother's grandfather and your father's grandfather, while English speaking regions would refer to both as a great-grandfather.

By providing relationship calculators, several problems are resolved.

  • Meaningful relation descriptions are returned localized for the user's region.
  • The relationship calculator plugin can return the relationship outside of the Relationship Calculator, allowing relationships to be used in reports and other areas.
  • Translators do not have to worry about trying to translate strings such as "third cousin twice removed" into a local phrase that has no equivalent.

How to write a relationship calculator

The relationship calculator changed for version 3.0. Logic has been separated from translation, which will allow code improvements to occur more easily, being available immediately in all translated modules.

Here are the rules the language-specific plugins must obey to be compatible with the framework:

  1. You need to make localized versions of the methods:
  1. get_single_relationship_string (used on quick report)
  2. get_sibling_relationship_string (used on RelCalc tool and on Status Bar)
  3. get_plural_relationship_string (used on kinship report)
  4. get_partner_relationship_string - only make a localized version of this if the gettext translation present in Relationship.py is not sufficient
Note that the signature of the methods must be identical to the ones in Relationship.py

All other methods are unique to the English module, and should not be overwritten. You can however define your own helper functions like present in Relationship.py, eg _get_father(). Helper functions start with a _ and are not used outside of the Relationship class module.

Text strings returned by the function should be in the UNICODE character set. GNOME expects all displayed strings to be UNICODE characters, and most report formats use UNICODE. While it may be tempting to use ISO-8859 or other character sets, these will not display correctly and will cause errors.

The relationship plugin must be registered in the plugin system. In short, you have to edit the file relplugins.grp.py in the directory src/plugins/rel. Follow the model of any of the other languages, and fill in all the possible language identifiers that may possibly be associated with your language: for example, different systems use ru, RU, ru_RU, koi8r, ru_koi8r, russian, Russian, ru_RU.koi8r, etc. to identify the Russian language.

That's it for the requirements. The example relcalc plugins can be found in src/Relationship.py and src/plugins/rel/rel_it.py or src/plugins/rel/rel_nl.py.

Tests

You are further strongly adviced to run the same tests as are present at the bottom of those files. If you have obtained GRAMPS svn in /home/me/grampssvn, then you can run the test for eg. rel_it.py as follows in a terminal:

cd /home/me/grampssvn
export PYTHONPATH=/home/me/grampssvn/src 
python src/plugins/rel/rel_it.py

You could also run pylint as follows in a terminal

cd /home/me/grampssvn
export PYTHONPATH=/home/me/grampssvn/src 
pylint src/plugins/rel/rel_it.py > /home/me/grampssvn/src/plugins/rel/it.txt

How to write a relationship calculator in 2.2.x

The framework for relationship calculator plugins is in place. Here are the rules the language-specific plugins must obey to be compatible with the framework:

  1. The relationship plugins (here and below referred to as rel plugins) must define a class that can be instantiated with the GrampsDbBase instance as its argument and that has a get_relationship() method obeying the following specifications:
    • The get_relationship() method takes two input arguments, which are two instances of the Person class. To be determined is the relationship of the second person to the first person.
    • The get_relationship() method returns a tuple with two values:
      1. The string of the relationship (e.g. "father", or "grandson")
      2. The list of the closest common ancestors of these two persons.
    • For the sake of the following example, assume that the above function is defined in src/plugins/rel_xx.py (where xx is your language code), and it's name is get_relationship(first_person,second_person). Also assume that it returns a pair of values: (rel_string, acnestor_list).
    • Text strings returned by the function should be in the UNICODE character set. GNOME expects all displayed strings to be UNICODE characters, and most report formats use UNICODE. While it may be tempting to use ISO-8859 or other character sets, these will not display correctly and will cause errors.
  2. The relationship plugin must register itself with the plugin system as the relcalc tool. This is done by inserting the following code at the end of your rel_xx.py file:
    from PluginMgr import register_relcalc
    register_relcalc(RelationshipCalculatorClass,["xx","XX","xx_YY","xxxxxx","Xxxxxx","Xxxxxxx_xx"])
where RelationshipCalculatorClass is the class whose method is the get_relationship() and the items in quotes are language identifiers that may possibly be associated with your language. For example, different systems use ru, RU, ru_RU, koi8r, ru_koi8r, russian, Russian, ru_RU.koi8r, etc. to identify the Russian language.


That's it for the requirements. The example relcalc plugins can be found in src/Relationship.py and src/plugins/rel_ru.py.

See also