Help talk:Style guide

Other date modifiers [22 March 2011]

Should we add cal, calc, estimated, and est be added to the list of "approved" date modifiers? Currently these can be entered, but since the system doesn't understand what they mean, they're ignored in date calculations made by the system. So what I'm really asking is does the system need to treat these as synonyms for "about" in date calculations. Similarly, should between, bet, and btw be added to the list of approved date modifiers?--Dallan 17:59, 21 March 2011 (EDT)

Help:Date Conventions tried to establish different meanings for cal, est and abt but in practice this is just not done. If people explain how they arrive at estimates, it is not needed, so I think the point to emphasize is to explain where estimates came from.

In adding my suggestions to the date section I thought it best to guide people towards one preferred form, so that there is less variability on pages, even if the software supports much more flexibility than is recommended. I imagine some flexibility is needed to deal with vagaries of non-standard GEDCOM data, but I don't think rarer forms need to be advertised. --Jrich 10:42, 22 March 2011 (EDT)

Date conventions page [29 March 2011]

I came across a Help:Date Conventions page, which should probably be merged into this page. Would anyone be up to doing this?--Dallan 18:06, 21 March 2011 (EDT)

Dallan: I may be too new at this to make a suggestion (but will anyway). The Help page you referenced seems more comprehensive than the section in the Style Guide and they should certainly be reconciled and merged. But would it be best to have one central Style Guide, or separate sections for Name, Date, etc.?--Kirsten 19:14, 23 March 2011 (EDT)

I think my personal preference would be to have one central style guide with the most-important points, which references help pages as needed for additional detail. From a quick read of this style guide and the date conventions page, it looks like most/all of the important points from the date conventions page have been summarized in the style guide, so I think that's great.--Dallan 19:42, 29 March 2011 (EDT)

Jr. / Sr. / Roman Numerals [24 March 2011]

This is a tricky topic. Is this excluding the colonial use of these terms, which were applied transiently, as older namesakes died? In the case of Roman numerals, does this require entering all the way back to a different name to ensure the whole sequence is studied, and the counting is not based on some arbitrary boundary? In modern times, it almost seems like these are part of the name, i.e., Orel Hershiser IV. But it used to be that people would drop the Junior when their father died, etc. I just worry about people using these based on the scope of their research, as opposed to the big picture. In any event, WeRelate users have to be prepared to deal with unrelated people having the same name. --Jrich 00:34, 22 March 2011 (EDT)

I agree, and it's a problem that extends beyond colonial research. I've had instances in mid-19th century Ohio research where a man was a "Jr." growing up, but a "Sr." in his elder years. In addition, just because a father and son have the same name does not mean that they were known as John, Sr. and John, Jr. -- one might have had a nickname or gone by his middle name, even in the records. I am very hesitant to instruct people to include suffixes that might not even have been used. Wouldn't it be better just to instruct people to include any suffixes, such as Jr., Sr., and roman numerals in the suffix field and not in the surname field? That way we can accomodate any suffixes that change over time, as they can be entered as an Alt name. -- Amy (Ajcrow) 07:40, 22 March 2011 (EDT)

Good points. There's a "social standard" from Emily Post or Miss Manners where, when the eldest dies, everyone is supposed to move up a notch. Then there's the separate matter of describing what genealogical records say. Like others, I have men who were not father and son but have the same name and are shown in records as "Jr." or "Sr." Probably the easiest way to handle this would be simply to change the instructions to say that such designations, if used, should go in the Title Suffix field rather than in the name field.--Kirsten 12:54, 23 March 2011 (EDT)

I'm confused by the above comments because the page was referring to the "Title Prefix and Suffix fields" already and not advocating putting these in the Surname field directly. My posting above was trying to suggest that these particular designations should be discouraged, or at least, not encouraged, and maybe some guidelines given to try and prevent their use solely to presents one person's narrow research focus which could differ from other researchers viewpoint. For example, the emigrant William Reed of Weymouth might be named Senior by an American researcher, since he had a son William, but by some accounts, he is several deep in a string of William Reeds that stretch back to England, so other researchers might want to call him William Reed III, or something else. (This person is subject to lots of controversy, so these points may not be true, I just remember reading various accounts for him that had differing numbering systems, so hoped it illustrates the point.) At least with titles like Capt, Deacon, etc., there tends to be a much more consistent usage of which ever one ends up on the gravestone, so it is subject to somewhat less subjective choice on the part of the researcher. --Jrich 13:31, 23 March 2011 (EDT)

How would you suggest this be stated? Recommend that designations such as Jr., Sr., etc. be omitted because the names of the spouse and parents would differentiate between the individuals? That could work.--Kirsten 19:08, 23 March 2011 (EDT)

You captured the essence of it. Something like: Use of Jr., Sr., or Roman numeral in the Title Suffix field is possible, but is discouraged as transient, limited in scope, and possibly misleading. In almost every case, there should be other information (spouse, birthdate, etc.) that can be provided that gives a more universal and reliable identification of an individual across the whole community of WeRelate users. --Jrich 11:27, 24 March 2011 (EDT)

When a name is unknown [30 March 2011]

Elsewhere on WR help pages, we instruct users to enter the word Unknown when part of a name is not known. The system also adds that into the title automatically. Also, for international users, the use of NN is quite common to denote unknown. --Jennifer (JBS66) 07:50, 22 March 2011 (EDT)

Sure, but we've been rolling with a local convention of the full word "Unknown" for a while. It seems reasonable as the locally preferred convention. I do think we should say that we use "Unknown" to fill in for a missing surname and - when missing both the given and surname - we only fill in the given name with "Unknown". We don't really need "Unknown Unknown (86)" - though there are such pages... --Jrm03063 10:26, 24 March 2011 (EDT)

I agree. There are a bunch of "Unknown Unknown" pages out there :-( but the current version of the software now tries to use just a single Unknown for the title when both parts are unknown. I've seen FNU and LNU, but I wasn't aware of the NN convention. I'll add NN to the list of "unknown" synonyms.--Dallan 19:42, 29 March 2011 (EDT)

There are also other variations on this with different punctuation such as N.N. - N.N - N. N. etc --Jennifer (JBS66) 06:40, 30 March 2011 (EDT)

3-letter abbreviation for month [28 March 2011]

Must the abbreviation for the month be in English? We have users whose native language is not English who enter the abbreviation for the month in their language. --Jennifer (JBS66) 10:16, 22 March 2011 (EDT)

I added that because it seems to be what GEDCOM requires for a Gregorian date. GEDCOM also supports French months but only for the revolutionary calendar (Thermidor, etc.) and the 13 Hebrew months which I am totally unfamiliar with. Perhaps WeRelate has some Internationalization features that could help? --Jrich 10:34, 22 March 2011 (EDT)

I don't think this is an actual problem. Not to sound xenophobic, but the user base of WeRelate is overwhelmingly English-speaking. And the chance that a genealogical user whose native language is not English will not be familiar with U.S/British conventions in abbreviations is very, very small -- and that includes Hebrew-speakers. We should just go with the 3-letter English abbreviations and not worry about it.

My own beef is with the pages that were imported with equivocal number-only dates, like "5/10/25". Is that day-first or month-first? Arrrgh. --Mike^Talk 08:29, 28 March 2011 (EDT)

One of these days, we're going to start doing a better job looking for inconsistencies across the data base, and the foundation for a lot of that is going to be unambiguous date representations. Also, dates are a key part of the "look" of WeRelate, so there's a good argument to not prefer too many equivalent forms. But as always - preference isn't the same as absolute legality. I see no problem with someone uploading a GEDCOM using a dialect of the accepted GEDCOM forms, using those while they're doing the initial bashing of their content into shape and getting it tied in to WeRelate - So long as they don't mind that things will evolve toward a more narrowly defined representation. I can easily imagine an agent that would go through and do a lot of that sort of normalization automatically. --Jrm03063 10:26, 28 March 2011 (EDT)

Add explanation at top of page? [24 March 2011]

Can we add an explanation at the top that this style guide is intended for when someone creates a new page via the WR interface or edits page, not for data coming into WR via a GEDCOM import? I'd hate for someone to think that because they've entered their surnames in all caps or spelled out their months in full that they're not supposed to import that data. -- Amy (Ajcrow) 10:49, 22 March 2011 (EDT)

Well, is this really a set of rules, or is it a set of conventions? I think this is really a set of conventions - which means that this is the preferred way to do things if there isn't a compelling reason (perhaps on a temporary basis) to do something different. Perhaps we should title documents of this sort as "Style Conventions" rather than leaving an implication that departure from this is a violation instead of a less generally preferred form?--Jrm03063 10:31, 24 March 2011 (EDT)

Name Conventions [24 March 2011]

I have two comments on the naming suggestions:

• What is the benefit of requiring a period after an initial? I have never encountered a middle - or other name - that was solely an initial. So a capitalized letter standing alone is already understood to be an initial - why require a ".".

• "When two children in a family have the same given name, enter (1), (2), etc. in the Title Suffix field to clarify the birth sequence if you do not otherwise know a birth or christening date.". This just doesn't seem helpful. If you know enough to know that there are two children in a family with the same given name, you really MUST know something about when they were born - at least by estimation.--Jrm03063 10:22, 24 March 2011 (EDT)

"Harry Truman's middle name is S. Since the 'S' is not a middle initial, a period is not required." This is quoted from a website on English usage in Business, but three or four were returned by simply searching for "not a middle initial". I heard a story once about a person who had no middle name, but some official stuck in an X, apparently finding that the computer demanded he entered something. The X stood for nothing, more a symbolic way to say no middle initial? --Jrich 12:37, 24 March 2011 (EDT)

Style versus data entry [25 April 2011]

I am not sure Style Guide is the best title for this page. The content is mostly rules about data entry. I believe there is also a need for a Guide describing the preferred style for presenting various types of information. Maybe it gets added to this, maybe it's separate.

Obviously there are many approaches to presenting information, and one is not necessarily better or mutually exclusive with others. But I believe there is some value to a reader finding things presented similarly on most pages. And that there is some value to presenting examples that illustrate preferred ways of doing things. So, some potential discussion areas:

1. Purpose of the facts and other fields. Is the intent to create a timeline of events or just a short summary of the major ones?

• So every thing can be listed as a fact (see for example the "Other" facts on Person:Jeremiah Vail (9), or minor events can be embedded in the narrative or source citations (e.g., Person:William Clark (191)).
• Standard facts get repeated in the narrative to create a pretty biography, or should the narrative be written assuming the reader can see the summary on the same page, and avoid repeating facts with not additional information, or relisting children who are already listed in the infobox (see for example Person:Dorothy Bowne (3)).
• What is the appropriate way to deal with spelling variations, historical place names, etc. For example, the recent discussion on WeRelate talk:Support about German Surnames.

2. Purpose of page. What type of information should go on each page?

• Should sources proving the connection between child and parent go on child's page or parent's family page? Should sources giving date of marriage go on person's page or family page of marriage or both?
• When should a discussion of alternatives or theories go in the narrative and when on the talk page?
• How should "Disputed Lineages" and erroneous sources be presented to prevent them from being re-entered?
• Would it be useful to have a suggested list of section headers for the narrative, so there are standard places to find certain information if it is present, i.e., "Probate", "Immigration", "Military Service", etc.?

3. Length of information. I have an 80 page biography of my great great grandfather which is probably much more than all but a dozen people in the whole world want to see. Surveys of all the land transactions that a person was involved in can be pretty boring.

• Guidelines for the tone of the narrative. Is the page a scrapbook, full of pictures and decoration, or a detailed biography, giving every time a person was mentioned as a neighbor or witness, or a encyclopedia entry of a person, as short as possible while communicating important facts? Are there guidelines of what material should go into the narrative, and when other information should be put into separate articles?
• What should go in the narrative and what should go into source citations? Should the narrative be a coherent, flowing biography with footnotes to source citations giving the text of primary documents, or does a collection of primary documents itself, or a series of transcripts of secondary sources, make a useful narrative?
• Guidelines for presenting documents. For example, including wills: use an abstract or excerpt not longer than ??? with link to full transcript on separate page if desired, or link to website where it can be found. Or no length limits? (e.g., Person:William Cutter (5)).
• The validity of data is not determined by the number of secondary sources that repeat it, so guidelines on when additional sources are useful, and when they become clutter.
• Focus. Wholesale transcripts that are actually about the parents or grandparents or the original immigrant of the family seem to devalue the individual by implying they are only important because of who they are related to. Similarly, tracts on historical events or the nature of the area settled in probably belong elsewhere?

There are probably many other style issues that can be added. I realize that it is not intended that things only be done one way, but there are probably many people that come to WeRelate and would be happy to do things in a given manner, presumably designed to create some commonality of style, versus some manner that results by accident from their experiments in trying to figure out how the system works. --Jrich 11:08, 13 April 2011 (EDT)

I like this suggestion and agree that some guidance on these issues for those inclined to follow it would be helpful. I don't know what to name the pages, but I think they should be separate. This page is largely objective rules that we are likely to actually enforce, whereas, at least until we get more developed, the issues above are more flexible. At the least creating the page would provide a place to discuss pros and cons of different approaches.

I'll also add how to deal with census information to the list - sources v. narrative, head of household v. family members, person v. family pages. --Amelia 12:22, 13 April 2011 (EDT)

I'm the one who named this page; I called it style guide because nothing else came to mind at the time. But certainly it could (and maybe should) be renamed. Feel free to rename it. As you say, it's more about rules for data entry than about "style".--Dallan 19:05, 14 April 2011 (EDT)

I started a page here based on Jrich's questions. The actual page has some rules where I think there seems to be an uncontroversial best practice or where at least a strawman might be helpful. The questions are on the talk page to discuss what's there, register your opinion in favor of one way or another, or propose a guideline. And please add any other topics that come to mind. --Amelia 23:28, 25 April 2011 (EDT)

Date format [17 September 2011]

The Style Guide said the date format should be dd Mmm yyyy (but Do not use leading zeroes). I thought dd implied using a leading zero (when you format a cell in Excel using dd mmm yyyy, dates are changed to 06 Jan 1900). So, I removed the first d from this text. Is this in line with gedcom standards? If it is, we may want to edit our Help:Date Conventions page as well. --Jennifer (JBS66) 13:03, 15 September 2011 (EDT)

I have been using leading zeros on the year if there are fewer than four digits present. --jrm03063 13:23, 15 September 2011 (EDT)

The only thing I'm aware of regarding gedcom standards is just day-month-year format. So I think we're covered. I personally could go either way on leading zeros for year, but I'm inclined to agree with Jrm that in the very rare cases where you have a 3-digit year, it's best to add a leading zero so that others know you really mean to have a 3-digit year. I don't think we need to make a big deal about that though, since we're discouraging most people from adding those pages in the first place.--Dallan 22:11, 15 September 2011 (EDT)

I hadn't thought of years with leading zeros when I posed my question. I was updating another page, and realized that DD implies using a leading zero (like 06 Jan). Since I thought that we were discouraging that practice, I put d Mmm yyyy, but wanted confirmation so I could make the help pages consistent. --Jennifer (JBS66) 07:01, 16 September 2011 (EDT)

I think the change you made is good. I'd keep yyyy as it is.--Dallan 12:33, 16 September 2011 (EDT)

Not strictly pertinent to this page, but pertinent to this discussion perhaps, since it would make some of it moot. If upon saving, understandable dates got saved into the selected format (presumably, no leading zero on the day, 4 digits in the year, sentence case on the 3 letter month, preferred form of the qualifiers, etc.), then there would be less trivial edits (i.e., containing no genealogical contribution) just to make the date conform, not to mention the educational value that would happen when new users see all dates forced into this format. Understandable dates would be any form the system could convert automatically to the approved format. A date input with leading zeros, e.g., 06 Jan 1834, would be understandable, but would get saved in the preferred format, e.g., 6 Jan 1834. Further I would argue there would be value in turning non-understandable dates red as we do with broken links, etc., so that people would be given feedback that while the system is storing it as a string in the date field, it can't be understood or processed as a date. --Jrich 13:31, 16 September 2011 (EDT)

I like that idea. What do others think? Would we want to to standardize date qualifiers like "About" into "Abt" (or vice-versa) as well? Red-link if a date field contained a valid date but also contained an unknown date qualifier?--Dallan 18:07, 16 September 2011 (EDT)

I'd be tempted to skip standardizing the qualifiers only because there are so many permutations of them. Circa can be expressed as: Circa, circa, C, c, C., c., Ca, ca, Ca., ca., ~ (and probably a few more I haven't thought of). Also, any could be expressed with or without a space between the qualifier and the date. I don't think it's worth the time and effort to try to capture all of the variations just to standardize it. -- Amy (Ajcrow) 07:38, 17 September 2011 (EDT)

Technically, there are not so many legal permutations, there are only lots of personal styles that technically violate the GEDCOM standard which was the basis for the date guidelines. As I read that standard, it lists ABT EST And CAL (case doesn't matter). If, in the interests of outputting compliant GEDCOM, Dallan were to translate all those listed variations into ABT or EST or CAL on output, why not do it on input? Even if the WeRelate community decided they like ca better than abt (is that California?, Canada? oh yeah, it's circa), it would be better to use it consistently, instead of being a slave to every whim and personal preference out there. The second reason is to avoid the issue, which I see every time certain users spend time on WeRelate, of getting notified of changes to pages when the only change made was to change ABT to CA, or change a capitalized month to sentence case, or some other trivial changes unaccompanied by any genealogical contribution. Doesn't ABT communicate the same thing as CA? What makes ABT wrong and CA correct? Certainly not the date guidelines. This is not like writing the narrative where a diverse styles can be useful in communicating different aspects of an individual's life. It adds nothing useful, and only detracts from effective communication of dates, to have widely varying date formats. --Jrich 09:43, 17 September 2011 (EDT)

Dates matter - a lot. We want to export good GEDCOM data, and our date strings go into the GEDCOM file untouched. Standardizing is also important because - I think - we really want to take advantage of well formed dates in order eventually permit better integrity checking (see this document).

Putting in code to discipline dates at save time is a nice thing, but there are already several million pages out there. Maybe we should do that, but maybe we also need to have an agent that recognizes a superset of the GEDCOM date forms and is able to automatically turn them into the standard forms. For example:

• c. 1895 -> abt 1895
• about 1895 -> abt 1895
• ~1895 -> abt 1895
• Between 1775 AND 1780 -> bet 1775 and 1780
• JANUARY 1775 - 1780 -> bet Jan 1775 and 1780

I would also suggest that we narrow the standard and always put the keywords in lowercase and the three letter month abbreviation in mixed case. Lower case uses less screen real estate and mixed case (for month names) helps to visually distinguish them from keywords.--jrm03063 11:34, 17 September 2011 (EDT)

Use of the "Personal Information" Section [27 August 2021]

We should really add the fact that the Personal Information Section does not accept carriage returns and that <br>s are really necessary in lists (such as a census for a household) that may be put there.

Other quicky gripes:

• Including e-mail addresses of informers. Not only is it proof that someone provided the information for the user, but the user may be impinging on that person's privacy.
• Explain what the description box should contain, like street addresses and farm names, occupations reported on censuses. In other words, items that need not be in the databases that the central box can link to.
• Citing a source twice because it is referenced to twice.
• Listing citations from Ancestry as "notes". These urls all get directed to Ancestry's "welcome page".--Goldenoldie 11:02, 27 August 2021 (UTC)