* Census Template Editor: French Census issues

[Gary_G]

Nick;

Unlike many countries, there isn't a list of specific dates for the French census.
The "Census Information: Date" field will not permit using just the year.
AS will not proceed without a full date. Would this field cause issues for AS, if it were left blank or defaulted to the census year?

I've also noticed an "odd" behaviour in the Census Columns list.
If the Column Title and Short Title are both "NOMES DE FAMILLE, PRENOMS", it shows "NOMES DE FAMILLE, PRENOMs". (note case change).
Not a functional issue, but I thought it should be noted.

When I typed "NATIONALITÉ" in the Column Title, the Short Title shows "NATIONALIT" and a triangle in place of the "É".

Hope you don't mind feedback as I work my way through defining my French templates.

[tatewise]

Unlike many countries, there isn't a list of specific dates for the French census.
The "Census Information: Date" field will not permit using just the year.
AS will not proceed without a full date. Would this field cause issues for AS, if it were left blank or defaulted to the census year?

Gary, the Help says the Date does not have to be entered. However, AS allowed me to enter just a year and I could then add Census Column definitions. So in what way did AS not permit just a year and then not proceed?

For example, all of the Electoral Register templates leave the Date blank.

[Gary_G]

Image 1.jpg (104.09 KiB) Viewed 1467 times

While you can put almost anything in the date field and add columns, the issue comes when saving the template.
When one tries to save the template when using just 1901 or blank, it refuses to do so.
However; if one uses a fictitious date of 1 January 1901, it will save.

[tatewise]

Ah, yes! So that is inconsistent with the Help that says it can be left blank.
I wonder how the Electoral Register templates were created. Maybe the XML can be edited after saving?

[Gary_G]

Mike;

I'm not quite sure how the Census record uses that field. Perhaps it is so that it sorts correctly in the list of facts/events? I used to do that in RM9, just to get that to happen.

While I'm waiting to see what Nick says, I'll see if any of the folks on the French forums have a "fictitious" date they use. Perhaps, while there wasn't an official census date, someone may have some empirically derived date one could use.

[Gary_G]

I had look online. There is no published "Census date" for a census year that I could find. However; at the end of each French census, the Mayor of the commune does typically stamp and date the Census return for his commune. I suppose that could be used, but it would be different for each commune. This would mean that having a fixed census date for use in the template definition is not likely possible.

[tatewise]

I'm not quite sure how the Census record uses that field. Perhaps it is so that it sorts correctly in the list of facts/events? I used to do that in RM9, just to get that to happen.

Yes, just like any other Fact (Event/Attribute) the Date is used to present the Census Event in its correct chronological position amongst all the other Facts for the person. That is a standard feature of all genealogy products.

I'll leave it to Nick to discuss how Electoral Register templates manage to leave the Date empty and whether it is feasible for all such templates to allow any form of Date to be accepted in that field.

[NickWalker]

Thanks for reporting these issues.

I may well make some changes to the way this works, but if you enter a year in the 'Year or Description' field of the Census Template Editor then it requires you to enter a full date. If you enter a description (something that isn't a year) then the date has to be left blank. AS has until relatively recently always insisted on a date being specified for a census and leaving it blank has only been used so far for Electoral Registers which don't have age columns. It looks like there is an error if just a year is specified when entering the census record itself and there is an age column so I need to look at that too (it is trying to calculate an estimated birth date but a Year isn't a valid date - I think I'll have to assume 1st January in those circumstances). There is a similar error for Marriage Condition too and possibly some other column types so I'll fix those too.

The new accents feature isn't working correctly when entering a long title that is replicated into the short title so I need to look at that.

[Gary_G]

Nick;

Thanks for the explanation. I was just wondering if allowing the date to be blank in the template and then allowing it during data entry would work. That way one could enter the date a mayor of the city signed the census and would act much more like what AS appears to be expecting. Then, if one still can't enter a date, perhaps a fictitious date about halfway through the year could be used to split any error in calculating ages.

By the way; it occurred to me, while entering some data, that much of what I entered into the defined census form was also needed in my user-defined source template. Is there a way to access that data and avoid having to enter it twice? I suppose the same would be true for the BMD-related forms.

[Gary_G]

Just in case I wasn't too clear about the French Census...
The Census always occurred at specific intervals; with the exception of the war years. So the Year of the census is always known. However; the specific date within the year seems to be fluid and determined by the commune/mayor, as evidenced by the mayor stamping and dating the return for the commune.

[NickWalker]

Nick;

Thanks for the explanation. I was just wondering if allowing the date to be blank in the template and then allowing it during data entry would work. That way one could enter the date a mayor of the city signed the census and would act much more like what AS appears to be expecting. Then, if one still can't enter a date, perhaps a fictitious date about halfway through the year could be used to split any error in calculating ages.

By the way; it occurred to me, while entering some data, that much of what I entered into the defined census form was also needed in my user-defined source template. Is there a way to access that data and avoid having to enter it twice? I suppose the same would be true for the BMD-related forms.

You can do this now. For now just enter the year into the template as e.g. 1901 Census (rather than just 1901) it will give you the blank date. As long as you enter a date with at least a month in when you create the entry itself it should work.

As explained before, you need to make use of the keywords in your Source Template definitions. The data in the grid will be specific to each individual so generally won't be relevant to a template. But the fields such as Place, Address, Reference ID, Other Info, Date, Country, SourceType, etc. are all available as keywords. There is also KeyPerson that refers to the 1st entry in the grid.

For reference, these are the settings for the fields in the Essentials Collection Census Template:

ASSourceTemplate.png (14.15 KiB) Viewed 1352 times

[Gary_G]

As explained before, you need to make use of the keywords in your Source Template definitions. The data in the grid will be specific to each individual so generally won't be relevant to a template. But the fields such as Place, Address, Reference ID, Other Info, Date, Country, SourceType, etc. are all available as keywords. There is also KeyPerson that refers to the 1st entry in the grid.

Actually; some of the data common to the family unit shown in the grid can be relevant to a templated citation, but is not currently available to it. This tends to be most evident in citations created to the Evidence Explained standard, since it tends to include more detailed data about the image itself. The following example shows how the family and dwelling numbers are typically included. These are not available in the current AS implementation and are not just used in France, but also in the USA as well.

Footnote:
1901 census of France, canton de Conliège, arrondissement de Lons-le-Saunier, commune de Perrigny, Rue de Montu, dwelling 151, family 186, Liégeois (Jean-Baptiste) household; imaged as France, "Dénombrements de population numérisés (1800-1936)", database with images, Département du Jura, Archives Départementales du Jura (http://archives39.fr/search?view=medias&preset=82 : accessed 17 January 2023) with search terms: "Perrigny, commune" [Commune] + "listes nominatives" [Type de document] + "1901" [Année: Date exacte] > cote "6M/484" > image 78.

[NickWalker]

Columns related to address or place are typically not included in the grid templates but entered into the place or address fields in a standardised format that fits with the way you organise your place and address records. There is little point including that in the source text column transcriptions because they would be the same for every individual and will just take up lots of valuable column space. There is no particular benefit in your case to typing them into the grid, you might as well just type them into the source template fields.

[Gary_G]

Nick;
I put all the census columns in the table, because I use the table as a complete transcription of the record, rather than just an extraction of some of the contained data.

In the case of French BMD-like records, I likely won't use the auto-text feature at all. For those, I usually write out a complete transcription, because French records are never in tabular form and the full text and marginal notes often provide vital information.

The bottom line is that I will manage to get around the constraint.

[NickWalker]

For all records and in particular the non census records, the autotext is only ever meant to create an approximate best guess. You always have to then manually edit the source text to match the original source. There is no point entering data in the census grid for a lot of the columns if you are not using autotext.

[tatewise]

Gary, a screenshot of a typical French Census record may be helpful, together with a description of which information you intend to enter into which fields in AS and then hope to include in Source Template fields.
That would give a clearer understanding of your problem and thus lead to a solution.
Discussing actual examples is often more fruitful than talking in general terms.

[Gary_G]

Mike;

I didn't upload an image for two reasons. One is that they are explicitly copyright protected and the other is that they tend to be too large and don't reduce well.

While I was thinking about what Nick said, I explored using auto-text directly in source-notes and found that the printed results suited my reports better than when I tried to use AS. I also found that my workflow was actually more conceptually comfortable for me when doing it that way. So; I'm going to see if that approach is actually a better solution for me, before prevailing upon Nick for any further changes.

[NickWalker]

While I was thinking about what Nick said, I explored using auto-text directly in source-notes and found that the printed results suited my reports better than when I tried to use AS. I also found that my workflow was actually more conceptually comfortable for me when doing it that way. So; I'm going to see if that approach is actually a better solution for me, before prevailing upon Nick for any further changes.

I'm not trying to persuade you to use AS (it may make my life a lot easier if you don't!), but AS auto-text (FH 7 has annoyingly used the term 'auto-text' despite AS using it for over 10 years) can generate data in any format - users develop their own AS autotext templates to produce exactly the results they want. The reason why hundreds of people use AS is because it speeds up the data entry massively and ensures consistency in the way information is recorded. However, some people are certainly more comfortable to enter their sources, citations, source text, images, etc. manually in FH, if time saving isn't a priority and particularly if things like transcribing their sources is not important to them.

[Gary_G]

Nick;

Transcribing my sources, as I noted recently, is important to me. That is one reason I'm being careful about adopting the first approach I try. However; it appears that AS may not allow me do it in the way that I prefer to work. I'm not interested in how quickly I can enter data, but more in ensuring I fully understand and document what I'm entering. So, I am doing the reasonable thing and looking to see if another method would work better for me. If that method takes more time, then so be it. Your response makes it sound as if there must be something wrong with me for trying to explore various avenues to be sure of whether AS works for me, not others, but for me.

With respect to; "I'm not trying to persuade you to use AS (it may make my life a lot easier if you don't!)". I'm not sure that such a comment was really warranted. In exploring various avenues, I obviously need to ask questions to make sure I'm using the tool correctly and what its limitations are.

[NickWalker]

With respect to; "I'm not trying to persuade you to use AS (it may make my life a lot easier if you don't!)". I'm not sure that such a comment was really warranted. In exploring various avenues, I obviously need to ask questions to make sure I'm using the tool correctly and what its limitations are.

Sorry, sometimes humour doesn't come over in text form and I really didn't mean anything negative in what I said: I should have added a smiley. I just meant that so far you've found a number of bugs/issues with AS (for which I've been very thankful as I've said each time) and so if you're not using AS you won't be giving me as much work to do! - I was responding to the comment you said in your previous post "So; I'm going to see if that approach is actually a better solution for me, before prevailing upon Nick for any further changes"

[NickWalker]

Your response makes it sound as if there must be something wrong with me for trying to explore various avenues to be sure of whether AS works for me, not others, but for me.

And again you've misunderstood me. As I said there are lots of people who don't use AS because they are more comfortable with entering the data into FH themselves. As you've said time saving is not your motivation and in my experience that's the main benefit of using AS. The other people who don't find AS a benefit are those who don't transcribe their sources: I obviously know that doesn't apply to you from the many conversations we've had!

[Gary_G]

Nick;

Don't worry about it. Postings are a terrible way to communicate and one can't use enough words to avoid miscommunication of ones intent to some extent.

When I send comments to anyone, it is always done in the sincere belief that even seemingly silly questions and oddball requests may lead to something that benefits everyone. If one always vehemently agrees, as was the case in the RootsMagic world, then change (even if it is for the better) will never happen.

While I am exploring all avenues, at the moment, I may well end up landing on using AS. I need to conduct my evaluation in this way, as I realize that switching methods later on may result in quite a bit of rework for me. As moving to FH7 is already a quantum leap, evaluating add-ons means I need to be even more careful than usual.