2013/5/23 Nick Hall <nick__hall@hotmail.com>

I introduced translations into the xml very soon after I made the census addons public.  They work the same way as the tips and holidays files.

Tags are marked for translation by prefixing them with a leading underscore.  The make script then uses intltool to extract the translatable strings.  I'm don't understand why you want to use a different approach for certificates.

I don't like values that have two meanings. In this case, a key is first a key, second the English string to be used for that key. I rather have those two meanings split, as a matter of principal. I won't leave sleep though if that is not done :-)

Eg, a person could write
Name: Nick Hal
if it appears like that in the census, but then connect this to person Nick Hall.

Yes, this is what the census editor does.  The name is just stored as another attribute.  The name column is actually populated with the name of the person by default, but it can be change to the actual text.

Ok, that was not clear to me.
So a censusline would actually probably be: column, value, handle 
where handle is the object where data of that censusline is stored after generation. Perhaps even a bit more complex, as a line can lead to a person object, or an attribute of a person.


I think we should consider a Persona object, with a name, type/role, handle and key/value pairs.  A Certificate would contain an ordered list of Personas and headings as key/value pairs.  The Persona would contain a person handle when linked to a person.

The data stored after generation can be located through back links from the citation object.

It will be nice to have the ability to create a persona without having to link it to a person.

Hmm, but then I'm afraid again of two meanings in one thing. On one hand an entry in a record (thanks for that Enno !). In the other a 'Persona'. A marriage record concerns a family by the way, and babtize record will create person if needed, and birth event, and baptize. All that in Persona? I suppose I should read up on the Persona discussion to understand the implication.
 
For census we have census event, so logical to store there values. For birth certificate, we normally only store source and birth event, but birth event is not when the certificate is actually written, so it makes no sense there to add what is stored in a birth certificate in the birth event.

I have had requests to create extra objects from census entries, such as Occupation and Residence events.  I prefer to review the Occupation attributes in the censuses and create an Occupation attribute.  Residence events are not really useful for censuses, but will be for birth, marriage and death certificates.
Is anyone actually thinking of doing this?

I'm itching, but I estimate more work than I have time for :-(

Let me know if you need any help.

I suppose point one is to update the GEP. My personal approach though is always to consider things technical first, not abstract, which is an approach not liked by many people. I'm a mathematician though, I can only reason within a space with defined axioms :-)

Benny