Initial People app scaffold

[brylie]

Closes #2

Todo

• Add localization to model field choices
• add date field/model for Name model

Related upstream issues

Two issues on the GEDCOM X issue tracker inform decisions about this data model:

• Change 'gender' to 'sex' to align with contemporary usage FamilySearch/gedcomx#318
• Add 'Intersex' as allowed value for gender/sex FamilySearch/gedcomx#319

[brylie]

Woohoo! Codacy is working ;-)

[brylie]

I will make an initial db table structure during this PR, but won't replicate the exact or full Gramps structure during the initial work.

[brylie]

I am thinking of localization here too. Since Gramps Online is, by virtue of being a web app, a multi-tenancy project, we will need to allow UI strings to be localized. So, in the case of user-generated content, we will need to set up content localization process. Whereas a pre-defined enum can also be localized, as part of a software release process.

[brylie]

@Nick-Hall want to have a voice chat sometime?

[jpek-m]

We have experienced geneological database using Neo4j for a few years. We are quite happy about oOur database design, but project is'n very mature yet :-) See our short documentation: https://docs.google.com/document/d/1YqaYHDPtaeduw8h2duCuBfhElXHSrDoaIG765j6-Szc/edit?usp=sharing - Juha Mäkeläinen - Genealogical Society of Finland

On 3.2.2019 0.45, Nick Hall wrote: ***@***.**** commented on this pull request. ------------------------------------------------------------------------ Whereas connected models, like graphs, would be more appropriate for the types of relationships that emerge in genealogical research (people relating with one another, places, events, etc. all sounds like a rich graph to me). Yes, parts of the Gramps model do resemble graphs. At the same time I wrote the MongoDB backend, I also considered writing a neo4j backend. Unfortunately, I couldn't come up with a workable design. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIqnhSxKb3fZ3N8YEl05n7SWOFk6v8jzks5vJhT7gaJpZM4Z78Rm>.

-- -- Juha ~ /Linux Ubuntu 18.04 LTS/

[brylie]

Thanks for the comment @jpek-m. I am also based in Finland, and commute to Helsinki about three days a week. Perhaps we can meet to discuss how we can collaborate?

[jralls]

I am thinking of localization here too. Since Gramps Online is, by virtue of being a web app, a multi-tenancy project, we will need to allow UI strings to be localized. So, in the case of user-generated content, we will need to set up content localization process. Whereas a pre-defined enum can also be localized, as part of a software release process.

Gramps itself is localized by gettext. If possible you'll save a lot of time and translator effort by reusing those strings and message catalogs as much as you can.

Enums can't be localized: They're mappings between compile-time tokens and ints. Using strings where one should use enums is a code smell, but when done the strings shouldn't be localized as it only introduces extra cost with no benefit as those strings shouldn't be presented to the user; they might select strings that are presented to the user but it's important to separate the logic from the presentation.

[brylie]

Gramps itself is localized by gettext. If possible you'll save a lot of time and translator effort by reusing those strings and message catalogs as much as you can.

Django also uses gettext, so we can probably share localization strings across projects, as you suggest.

Enums can't be localized: They're mappings between compile-time tokens and ints

The localization strings (TODO) specifically apply to model field choices. See for example:

gramps-online/people/models.py

Lines 31 to 41 in e2e4be3

	SEX_FEMALE = "female"
	SEX_INTERSEX = "intersex"
	SEX_MALE = "male"
	SEX_UNKNOWN = "unknown"
	SEX_CHOICES = (
	(SEX_FEMALE, "Female"),
	(SEX_INTERSEX, "Intersex"),
	(SEX_MALE, "Male"),
	(SEX_UNKNOWN, "Unknown")
	)

[brylie]

Using strings where one should use enums is a code smell, but when done the strings shouldn't be localized as it only introduces extra cost with no benefit as those strings shouldn't be presented to the user; they might select strings that are presented to the user but it's important to separate the logic from the presentation.

There is an article called Using Enum as Model Field Choice in Django that might align more closely with what you mention.

What I am trying to do here is to follow documented guidelines/recommendations for Django/Python projects. I don't have deep expertise in any language, and want to align closely with best practices in the Python/Django communities in order to fill in gaps in my knowledge.

[jralls]

The first half, where the symbols are defined as strings, is bad practice. Naughty Django documenter. The "Using Enum..." article presents the correct approach.

Note that for localization you'll need to mark the display strings for translation in the enum definition but actually translate them at use:

class SexChoices(enum):
    FEMALE = N_('Female')
    #...

class sex_model (model.MODEL):
    sex = models.CharField(
         max_length = 8
         choices = [(tag, tag.value) for tag in SexChoices]
    )

 print(_("Sex Choice %s") % _(sex_model.sex))

[jralls]

@jpek-m Interesting document. Is this still in the proposal stage or has someone begun writing code?

[Nick-Hall]

I am thinking of localization here too.

Excellent. Just a couple of points. Our translators portal gives a list a translations. Although it is clearly out of date because Matti Niemelä is our current Finnish translator.

You will notice that some use non-latin character sets and a couple are right-to-left (Arabic and Hebrew).

Punctuation will need to be translated where sometimes this can be overlooked. For example, the Arabic comma or the cultural requirement for a space (or not) after a colon.

[jpek-m]

On 3.2.2019 16.58, John Ralls wrote: @jpek-m <https://github.com/jpek-m> Interesting document. Is this still in the proposal stage or has someone begun writing code?

Yes, we have done coding for few years. The work contains a lot of experimental code, and needs a lot refactoring. For example the business classes Person, Event, Family etc contain duplicate parameters for different approaches of combining data for listings.

…

-- -- Juha ~ /Linux Ubuntu 18.04 LTS/

[Nick-Hall]

We have experienced geneological database using Neo4j for a few years.

@jpek-m Thanks. I was aware of this because of a post to our mailing list. You probably know Pekka and Anders.

Just to illustrate some of the complexity, on page 1, you show an individual "I0232" linked to an event "Birth" by a link with the role "Primary". In Gramps, this link corresponds to an event reference object which contains not only the role, but also a privacy flag, a list of attributes and a list of notes. For a Gramps backend, I would probably create an event reference (or role) node in between the individual and event. I expect that you are using a well-defined subset of the full Gramps functionality.

Would you be interested in a neo4j backend to Gramps?

[Nick-Hall]

want to have a voice chat sometime?

@brylie Good idea. What chat software do you use?

[brylie]

What chat software do you use?

I try to use WebRTC, so participants don't need a dedicated software or account. E.g.

https://meet.jit.si/Gramps