Help talk:Naming conventions


Source Naming Conventions (Capitalization) [16 April 2009]

I really like the idea of having our Naming conventions all in one place!

If you don't mind, I'm copying over some text from the Source portal talk about Source naming conventions. I haven't seen discussion about it on WeRelate yet.

  • Do/should we have a convention for how we capitalize words in a book title?
    • Wikipedia and standard convention capitalize the words in a title see Wiki Books. However, FHLC only capitalizes the first word, names, and locations in their titles.
    • Note, I noticed a user from the Netherlands renaming a source to follow "Dutch typography". This was in line with what FHLC does, not all caps. Is this a more universal standard that we should adopt?--Jennifer (JBS66) 16:31, 14 February 2009 (EST)

Thanks for your words, Jennifer. Edit to your heart's content. As for Book title capitalization, you realize, don't you, that you may be starting WW III? ;-) (Personally I'm for following standard/Chicago manual of style capitalization.) -- jillaine 16:36, 14 February 2009 (EST)

Well, one thought comes to mind from a purely programming point of view. Since a great majority of our sources were gathered from FHLC, I'm going to guess that sticking to their capitalization convention would be handy. Even when Dallan renames the pages in the future (to conform to Author.Title format), it would probably still be in sentence case. Also, does WeRelate want to conform to a more international standard, since sentence case is common in most other countries?--Jennifer (JBS66) 07:58, 15 February 2009 (EST)

Yeah, I figured that might be the direction werelate would take. I won't block consensus (or start WW III). :-) -- jillaine 08:05, 15 February 2009 (EST)
Not to start WWIII, but I and I'm sure many others based in the U.S. have had the 'standard convention' beaten into our heads and naturally do things that way. I've personally renamed probably over 100 sources to capitalize them, not counting the census standard that uses caps. It doesn't seem like it would be that hard to automatically capitalize them if we choose, either, but I suppose that's Dallan's call.--Amelia 11:40, 15 February 2009 (EST)

The standard for capitalizing sources is to capitalize all words except "stop" words (words like the, an, of, etc.). The reason for this is so that the "Add Source" screen can automatically capitalize titles correctly, so that we avoid people creating sources that are identical to existing sources except for capitalization differences. Many of the existing sources don't follow this rule; they will be renamed later this year when the source review project is complete.--Dallan 11:08, 16 February 2009 (EST)

I'm wondering if these "stop" words are going to include foreign language versions of these articles. I've been working with the Dutch sources, and words like van or de should equally not be capitalized.--Jennifer (JBS66) 13:54, 11 April 2009 (EDT)

Another attempt at a GEDCOM upload on the sandbox showed me another reason why I will never be doing updating by GEDCOM upload: because I can't possibly match any of my sources referring to censuses.

Perhaps in my naivete I got started on a bad system. But to me all of the 1880 US census is one source. (I know in WW1 they handled servicemen differently and 1850/1860 they had slave schedules, so perhaps those should be considered separate and distinct. But just single distinct items each.) The census of a given year is sponsored by one agency and collects one set of data. The county and state are items used to locate the desired page, and should be treated like a page number, a locater within a source, not as a separate source title??

In their own software at home, does everybody make a different source for each county, within the same census? Because if they don't, a source like "1880 US Census" can't possibly be matched to the WeRelate census sources when they upload their GEDCOM, because it may be used in their GEDCOM for multiple different counties and states.

Maybe people use county-level, maybe not. But 1) you can match your source to the 1880 census source page, and 2) it's useful to have county level pages because free transcriptions generally exist at the county level, meaning it's useful to have county-level pages both as a finding aid and to discuss issues with a particular enumerator or transcription. I'm going to ignore the rest of the comments, since I'm done justifying a decision made two years ago.--Amelia 19:49, 12 April 2009 (EDT)
When the Find/Add function searched for my source name which happens to be "1880 U.S. Census" nothing like this was anywhere to be seen. Most of the entries were for specific counties, and if I had to wade through an entry for each of the counties in the country to find the general-purpose entry, that's not going to happen. Besides which, I figured there was no such entry.
DALLAN: JRich is, I believe, citing the same problem I had with the search of sources in the sandbox. jillaine 22:07, 12 April 2009 (EDT)
As far as the other comments, I know the decision was made a long time ago. I was not involved in WeRelate when it happened. I'm sure there was some particular problem that was being addressed that this approach solves. I am guessing it was unique page titles. I am also guessing that was less software in place when the decision was made, so I wonder if the same decision would be made now. Further I think things are working now, even though the vast majority of titles don't follow this scheme, so wonder if everybody still wants to swim against the current so badly.
It's not just what's easy to use, it about what will be intuitive to new users, and that would be the thing that other sites do. That is why I mentioned the way FHL handles their catalog. Or any library for that matter. --Jrich 21:06, 12 April 2009 (EDT)

I can't resist stating again that I also dislike putting the author's name in the title. It is non-intuitive. Notice that none of the Titles coming in from FHL are arranged this way. So recently I complained that in trying to match sources during a sandbox GEDCOM upload, that no authors were displayed. Dallan's response was that the author was supposed to be in the title. But in the example I had, that wasn't true of a single existing title of the couple of pages of WeRelate sources I was given a choice of. Since that is still so, there may still be time to avoid this mistake?

It is a bad idea because:

  • There is a separate area for authors. Having redundant data is always bad in computer applications. Sooner or later it causes maintenance problems.
  • Which author do you use when there are more than one? Different editions of some works have been known to list the authors in different order. So depending on which edition one refers to, they could create different page titles for the same work.
  • Having author names in the author field, only, could allow simple processing to convert the name to given lastname, first, automatically. Since the field is a list, the order the authors are given could be sorted alphabetically for predictability, or not as is desired. Empty or incomplete author lists could be filled in, initials could be expanded to full names, etc., without affecting the page title.
  • The search results do not come back sorted anyway so what's the point? Nor does search work based on beginning strings (for example, searching for a title "Cutter" would not bring back an alphabetical list of the titles by William R.Cutter (and searching for "Cutter, William" would probably miss anything that choose to specify the author as Cutter, W.R.? Anyway, there already is a way to build a search criteria for the Author's name so this isn't needed anyway.)
  • Bibliographies handle uniqueness by giving each book a code, such as author's initial and year of publication, or even just a keyword and sequence number. That unique code is immune to changes to the book's title and author field. It doesn't even need to have any association with the source's title or author, the way the tag "S1" attached to a fact has no association with what that source citation is. Why doesn't WeRelate do something like that to keep the name of the page unique, while allowing the title field to hold the title, the subtitle field to hold the subtitle, and the author field to hold the author. Selecting a source from search results means the computer needs to be the only one cognizant of the exact code and it could even be as ugly as the ISBN or similar.
  • The source titles aren't long enough to handle the subtitle and/or the author, and making them longer will reduce the number of entries that fit on a screen.
  • When I search for a title with keyword XXX, I don't want to get a bunch of extraneous results for no other reason than because the author's name happens to be XXX.

--Jrich 19:19, 12 April 2009 (EDT)

My question loosely relates to one of Jrich's points above - the title field. In sources that are geographic in nature, why are we putting the full place name in the title field? One example is Source:United States, Alabama, Greene. 1850 U.S. Census Population Schedule. Is this being done automatically from Add Source, or is this user confusion? My understanding is that this field is just the source's title, otherwise, as Jrich said, searches could get really muddied.--Jennifer (JBS66) 11:10, 14 April 2009 (EDT)

Because the rule is that geographic sources start with the place name so they are easily identifiable, there is one rule controlling the names, and they all show up together when you sort/use the drop-down. The place is actually crucial for usability -- census or vital record sources without a place would be a disaster (the FHL versions often do not included it, and it's a mess). For those curious about why these rules exist, see Help:Source page titles, Help talk:Source page titles, WeRelate talk:Source page titles, WeRelate talk:Source Committee/Archive, WeRelate talk:Source Committee and others I'm sure. --Amelia 00:47, 15 April 2009 (EDT)

Amelia - sorry for the confusion, but this isn't what I meant. I understand the necessity of having the place in the page title. What I'm speaking of is the title field (comes after Authors), which does not necessarily need to be identical to the page title. From a programming standpoint, it doesn't make sense to me to include combined info. in any field (ie. place and document title). For the purposes you are speaking of (such as sorting), the page title could serve this purpose. The title field, however, should solely be the title of the document.--Jennifer (JBS66) 07:24, 15 April 2009 (EDT)

Oh. (Sorry, questioning page titles has been a common thing lately.) Well, I don't know, but since I can't think of any use of the title field for anything other than display purposes, I haven't paid any attention to how it's populated. It's at least partially default to the page title, which I suppose could be changed.--Amelia 10:57, 15 April 2009 (EDT)
[Taking my inspiration from Winston Churchill who described writing his 7th letter to FDR in support of the Lend-Lease program.] Well, I think this is the exact same question I am asking, just about Author's Name, instead of Place.
I think my primary complaint with these conventions has to do with how search works. In citing a source on a page, I agree that "Marriage Records" would not be as useful as "United States, Texas, Guadalupe. Marriage Records 1846-1893". But since the location and years covered are stored in separate fields, cannot the source citation just display a dynamically-built compound title without storing it in the title field that way (doesn't it already do the lookup in order to color the link blue or red? So it should have that all those subfields available?)
If somebody wants to search for Government Records in a given location, they will just select the type of Government Records, put the location into the Place field, and do the search. It should bring back a list of sources that pertain to that place. So putting the location into the title doesn't seem like it adds any value to searching. In fact, it makes searching somewhat less useful. If I am searching for titles containing the surname Wilson, I don't want to see all the sources from Wilson County (several states). A few miscellaneous works on the History of Wilson, TX wouldn't be bad, but the avalanche of government and census records is going to make this search useless.
I think this issue has come back to the forefront because of the new GEDCOM upload which requires matching to existing sources. Some related questions:
Sorting the results from a source search should be done whether it is an exact match search or not. I would suggest that some order that is obvious when looking at the list, like alphabetical by title, so I can predict how far to go through the list before I can give up. Right now, I cannot tell why one source comes before another. It is not alphabetical and it is not based on the number of keywords matched. If my result is not in the first couple of pages, I tend to give up. Possibly a box to jump directly to page 100 if I know my result is way down the list.
As a suggestion it might be nice if in addition to the "Exact match only" (which usually returns zero results when I try to use it), there were other radio buttons for "Begins with", "Exact phrase" "All keywords", or some similar enriched set of options. (I am assuming case insensitive searches is already planned, otherwise add that as an option.)
Are there additional tools that can be added to help refine the searches? When I get 43000 results, I need help paring down this list. If I can't control the sort order, or add additional criteria to select from that subset, or some other mechanism to find the one entry I want quickly, I am probably going to create a duplicate entry. Seeing that message xxx of 43000 results gets very discouraging after a few pages. --Jrich 12:41, 15 April 2009 (EDT)

Oh dear me! I'm DIZZY with DEJA VU!!!
I got myself into such a snit about this a few months ago, and part of it was related to the following distinctions, which really need to be understood:
  1. The TITLE field vs. the PAGE TITLE
  2. What fields the search engine SEARCHES vs. what fields the search engine DISPLAYS in its results
    Dallan's answer from elsewhere:
    The search engine SEARCHES not the PAGE TITLE, but the individual FIELDS. However, the search engine uses the PAGE TITLE in a couple of ways: a) it's the large, clickable line displayed; b) its contents help bring some results to the top more than others. As mentioned the SEARCH RESULTS DISPLAY highlights the PAGE TITLE, not the information in the individual fields.
  3. What fields populate the DROP-DOWN menus when you are entering something into the TITLE FIELD at the time of editing or creating a page.
I made a zillion posts before realizing/learning that the Title field (of a source, for example) was different than the Title of the Page. And what I now cannot remember is what fields (Title field or Page Title) is used for #2 and #3 above. So before we get back into this horrendous debate again, we need to be clear about the distinctions. Dallan posted them somewhere. Let me see if I can find them.
-- jillaine 17:18, 15 April 2009 (EDT)

Thanks, Jillaine, for pointing out my mistake. I think you are right, and I may even have to rethink my whole attitude about page titles versus source title. I will try to go find the discussion you refer to.

Leaving still, some dissatisfaction with searching of sources because too many results get returned, I was wondering if some of the suggestions might still be useful: adding more types of searches, like exact phrase, all keywords, etc., and making the result list easier to work with when there are lots of entries.

--Jrich 08:55, 16 April 2009 (EDT)

Person Page Naming Conventions [13 April 2009]

I have a challenge and could use some advice. I have a set of German ancestors. The naming convention for them at that period of time was frequently:

  • Johann [Something] Surname
  • Anna [Something] Surname

When the emigrated to the States, they dropped the first name (Johann or Anna) and subsequent records identify them as [Something] Surname.

In my genealogy software, I use the formal name found on their birth record, which was usually:

  • Johann [Something] Surname
  • Anna [Something] Surname

But upon uploading the GEDCOM, WeRelate treats the Johann/Anna as a first name both for the Name field as well as the Page title. This makes searching a major drag because I end up with a whole slew of "Johann" Surnames that actually mean nothing and make searching very difficult. It's also misleading on the person and family pages, because even in Germany they usually went by their "middle" name when they had a Johann-[Something] combo name.

How would YOU deal with this once the file is uploaded?


-- jillaine 18:00, 13 April 2009 (EDT)

Might be a good use of the alternate name type "Birth Name". Set up the page as George Schneider, but enter a Birth name of Johan Georg Schneider, for example. Just a thought.

Actually, in many of those families, there is a generation where the name tended to get Americanized, i.e., Schneider to Snyder. That might be handled similarly so that the generation where it changed can show some connection to the old name of the generation before and also to the new name of the generation after?

--Jrich 18:32, 13 April 2009 (EDT)

birth name vs primary name [21 December 2016]

Herein lies the issue! If the primary name is defined as the birth name, what is the birth name? The primary name, therefore, can easily be something OTHER than the birth name (or even the married name for that matter).--Jrm03063 17:18, 14 February 2009 (EST)

We'll have to wait for Dallan to get back from celebrating a romantic Valentine's Day with Solveig for the answer to the purpose of the "birth name". -- jillaine 18:55, 14 February 2009 (EST)

Here's an example of how I would use the birth name and primary name: My great-great-grandmother was christened Anna Sophia Weand. Her tombstone reads Annie Sophia Hauck. Every other reference to her, including her marriage, her civil war widow pension file, the 1850, 1860, 1870, 1880, and 1900 censuses, and other misc. sources refer to her as "Sophia". I've chosen to make "Sophia Weand" her primary name and "Anna Sophia Weand" her birth name.

Another example from my genealogy would be a certain guy wikipedia refers to as "Bill Clinton". In my files his primary name is "William Jefferson Clinton" not "Bill Clinton" and his birth name is recorded as "William Jefferson Blythe". And for genealogical purposes his wife will always be entered in my files as "Hillary Diane Rodham" even if wikipedia prefers to refer to her as "Hillary Rodham Clinton".--Lauren 19:29, 14 February 2009 (EST)

And Jrich mentioned over at the Watercooler another use for birth name: used for what's on the original birth certificate of adopted folks. jillaine 21:13, 14 February 2009 (EST)

My theory is that the primary name ought to be the name under which records on that person would generally be found. This is a genealogy site, after all. Bill Clinton is legally William Clinton, not William Blythe. Since stage names are generally stage names, they wouldn't meet that standard. In cases like Clinton's, the primary name is different than the birth name, and that ought to be recognized. Women's maiden names don't entirely fit into that standard, but again, this being a genealogy site, we can't have women referred to using their married names. It makes us look like newbies who don't know any better.--Amelia 11:48, 15 February 2009 (EST)

I think that Amelia's got the right idea on the primary name - but I don't think we should be afraid to follow that through to the present day. To use the Cary Grant analogy again, by this standard his stage name SHOULD be his primary name. There is nothing to prevent adding his birth name and tagging it as such. As I keep saying, if the appearance of a birth/maiden name in the originating family is something we really want, it seems like Dallan could extract birth-type names, in preference to the "primary" name, for that purpose (or both with one of them in parens or some such).

Stage names, pen names, names containing ranks of nobility, etc., etc. - any of these can be the name by which someone is "primarily" known. People won't think we don't know what we're doing if we have the different forms and have them appropriately labeled.

On the separate, but related, question of the page name - I still prefer that the page name be the same as the preferred name - but would probably be just as happy with the convention as currently implemented. Nobility and people living prior to modern naming conventions may use the English wikipedia name or name as it appears somewhere in wikipedia.--Jrm03063 16:13, 15 February 2009 (EST)

I agree with Amelia -- a person's "primary name" is the name under which genealogical records about them would most-likely be found. It seems like following this rule makes it easier for someone who found records about a person named X to search WeRelate for X and check the results. A woman's primary name is her maiden name; this seems ingrained in most genealogists. For most people, the primary name is the name they were born with. Birth name is available for exceptions like adoptions. So if Cary Grant appears on his marriage certificate, census records, etc., then we should list Cary Grant as his primary name. But I think we're talking about exceptional cases; the general rule should be that the primary name should agree with the birth name.

Regarding how to title Person pages, at some point I'd like to rename the page automatically when the primary name changes, or at least ask the user if the page should be renamed when they change the primary name. In order to do this, we would need to have a simple rule for how to title a page, like: the page title agrees with the primary name for people born after 1500; page titles for people born before 1500 will not be renamed automatically. If we use this rule, then the page title for Bill Clinton would be William Clinton and the page title for Mary Lincoln would be Mary Todd. For medieval people, we have the rule that the page title should follow the Wikipedia title. I could go either way on whether the page title for a medieval person with a maiden name should follow the Wikipedia title or if there should be an exception in this case to use the maiden name in the title.

I'm not sure if we ever use the label "Primary name" in the system. If you add an alternate name to someone, we label the primary name as "Preferred name". I'm happy to change this label to "Primary name" or something that more-clearly relays our intent. And we'll need to clarify the help pages.--Dallan 11:08, 16 February 2009 (EST)

I am going to submit a request on the Suggestions page to do just that. I will look after the Help pages (I have already updated the Glossary).--DataAnalyst 18:06, 21 December 2016 (UTC)

Perhaps skimming the wikipedia guide for person naming would help folks see that there is a general method at least - see it at: Wikipedia:Naming conventions (people).

To again describe why I've done the things I've done, I'm working through the medieval space in a couple of different ways. One way, is simply to appropriately merge and source the people who already exist for werelate person and family pages. Another way, is to CREATE additional people who are named in wikipedia but who do not, seemingly, yet appear on werelate. If wikipedia has parent pages for a person, named "A" and "B" respectively, then I directly create a parent page named "A" + "and" + "B". I then go create the page, and I immediately create the people using the strings "A" and "B" (along with the appropriate wikipedia source references). If I'm lucky, one or both of the people were already created as a side effect of work I did elsewhere. Even if I'm not lucky, a search for duplicates on the newly created pages will often yield results that I would not easily find using the existing tools.

It's not that I LIKE these names, I just don't want to spend time on the question when there's already a decision available on wikipedia.

BTW, if I use the "proper" page creation steps, I have to try to put in strings like "Fred II, Earl of Bedrock". This gets turned into "Fred Unknown (847)", or something similarly helpful, which I then have to immediately redirect. I'm not suggesting that the existing tools be tuned to deal with irrational/antiquated naming systems, but I do want to explain why they really aren't as helpful in the older spaces. Back there, it's just a lot simpler to use the wikipedia name and move on.--Jrm03063 17:21, 19 February 2009 (EST)

I have a problem with this fixation on wikipedia and hence, wikipedia is far down my list of reasons why should do something or not. Wikipedia is a very valuable site, but has a different purpose. They title a page so people can find it and recognize it, probably as the result of an isolated search. They can name their pages how they want, and it doesn't matter to WeRelate since it can be linked to regardless. So WeRelate should adopt its own conventions.

Werelate is about connections. Pages are titled following a convention that makes sense when looking at how people relate (in fact people are often distinguished from others of the same name solely by how they relate). While for wikipedia, the Personal History is essentially the primary purpose of their pages, for, the people and dates on the left margin, and the ability to follow those links is just as important.

WeRelate is a genealogy website. It should be that a person familiar with genealogy can come to werelate and find somebody. I think it is great to link the Personal History to wikipedia. But werelate must reserve the right to name things differently when it makes sense according to its different purpose, i.e., to show how that person fits in their family and relates to their spouses, siblings and children. I do not want to see Mary Lincoln as a child in the middle of the Todd family or Cary Grant in the middle of the Leach family.

Since the purpose is collaboration, the naming of pages should involve as little individual judgment as possible, since as we all know, one individual's judgment is another person's anathema. I talk about Rev. Solomon Reed of Petersham when I want to distinguish him from his father Rev. Solomon Reed of Framingham? Titicut? (multiple choices here, which takes precedence?), but is that a distinction that makes sense to a researcher of Solomon's wife Susanna Willard? So, if the conventions can be followed, they should be. An exception was made for people with one names. As few exceptions as possible should be tolerated.

If we are going to embellish titles, I think it would make sense to use birth and death years. This seems to be slight less subject to personal opinion, and is used by many genealogical books to make their index more useful when it lists references to umpteen John Smiths, for example. --Jrich 09:50, 20 February 2009 (EST)

  • I reject logic that says, werelate is different than wikipedia in one or more ways, therefore, werelate is different than wikipedia in any sense I find convenient.
  • I also refuse to gratuitously re-invent peer-reviewed open-source documents, practice, review groups, etc.
  • I know from actual dilligent practice, that the techniques I propose work, and work well.

To give this debate a more concrete form, I suggest that folks search the werelate "Person" space, with a keyword of "wikipedia-notice". Scan the list and suggest which pages are wrong - how and why.--Jrm03063 11:42, 20 February 2009 (EST)

I've been trying to avoid commenting, because there are others ably carrying the debate. But Jrm, I feel the need to point out that no one is challenging the idea that the Wikipedia naming idea works for people with no last name. And that you do good work. And that you you have a method that has allowed you to make lots of progress. But what you haven't explained is that where there's a confllct between the rules because someone does have a last name, which everybody seems to think is rare, why it's a problem for you to use people's proper names? I don't understand. Is this case not rare? Does it cause some actual problem for you? Since you are the one proposing a change to the general rule, you have to justify it -- the exception, not the rule.--Amelia 22:01, 20 February 2009 (EST)

Delijim, at the very least you will need to carefully define most commonly accepted spelling, and at the worse, I think your addition may be a bad rule, at least in some cases.

I think most commonly accepted spelling tends to be based on which particular sources you rely on, and few people have access to all the sources to make an absolute judgment about which spelling is the most common. So with several people, each with limited horizons, each may be justified in thinking their spelling is the correct one. There have been myriad discussions about the flakiness of colonial spelling, and any reference to this or that colonial source is not particularly authoritative. Finally, I think an understanding that one spelling is better than the rest is likely to lead to arguments that don't advance the genealogy, whereas an attitude that these are all alternatives and one just happens to have been entered first, is a less challenging position.

I think a better answer is to 1) be flexible about spellings as long as it is clear the page represents the same person, 2) make sure Surname pages reflect common spelling variations, 3) add alternate names so that other researchers who have selected different spellings still get directed to this page. --Jrich 09:45, 26 February 2010 (EST)

I agree that "the most commonly accepted spelling" should be the primary surname, and I realize that this is impossible to define. But listing alternate spellings that the person has been listed under is also great advice.--Dallan 20:12, 27 February 2010 (EST)

Msg for Solveig [14 February 2009]

Hi Solveig!

I see that you edited the Family Page sub-section of this page. You included instructions for how to make a Family page, but this page is about Naming Conventions for pages. Do you mind if I take your instructions out? -- jillaine 21:22, 14 February 2009 (EST)

That's fine.--Dallan 11:08, 16 February 2009 (EST)

Suggestion - Examples [21 February 2009]


I would like to suggest on this page we have an area that has Source examples. Sometimes we agree to a example, but it is in the conversation. I sometimes have a hard time re-finding the agreed to example when I look for it, i.e. it gets lost in all the text.

Debbie Freeman --DFree 09:58, 15 February 2009 (EST)

Debbie, please feel free to add such an example. -- jillaine 08:47, 21 February 2009 (EST)

Question [27 February 2010]

Would Muhammed Ali be the preferred name and Cassius Clay the birth name? Or would Cassius Clay be the preferred name and Muhammed Ali the religious name? Probably would be good to list a few of these kind of examples. --Jrich 00:35, 16 February 2009 (EST)

I think we should tell people that in general they should follow the naming rules. So if we go with primary name is birth name as a general rule, then his primary name would be Cassius Clay. In cases like this where a person is listed under multiple names in genealogical records, I hope we can generally leave it up to the people who have Muhammed/Cassius in their family tree to decide which name to use as the primary name.--Dallan 11:28, 16 February 2009 (EST)

I would think that the name at birth would in almost all cases be the primary name. Since he changed his name as an adult, it should be an alternate name... just my $.02.--Delijim 10:08, 26 February 2010 (EST)

Then you have the question of names of popular actors and musicians: Is the actress's primary name Marilyn Monroe, Norma Jeane Mortenson (birth name), or Norma Jeane Baker (baptismal name)? Is the singer's primary name Sir Tom Jones or Thomas Jones Woodward (birth name)? Is the primary name of the movie star born as Archibald Alexander Leach identified by his screen name Cary Grant or his birth name? Is the singer's primary name Engelbert Humperdinck or by his birth name, Arnold George Dorsey? I see this same topic of exceptions for notable people was discussed earlier, but not sure concensus was reached. --BobC 00:31, 27 February 2010 (EST)

I can't think of cases when the primary name wouldn't be the birth name. I believe actors' stage names should be listed as alternate names.--Dallan 20:02, 27 February 2010 (EST)

Unknown name [27 April 2011]

Why would you leave unknown given name blank instead of "Unknown". It seems like the display on Family pages, etc would look funny to see "Jones and Sally Smith" instead of "Unknown Jones and Sally Smith". --Jrich 21:00, 27 April 2011 (EDT)

From the Add Family or Person page, when the field is left blank, the system automatically puts the word Unknown in the title. However, in the rare instance that a user enters Unknown Unknown (for given and surname), the system will create an Unknown Unknown (#) page instead of an Unknown (#) one. I was trying to avoid instances like this when I was writing the help blurb, but feel free to edit it if you have a better way to phrase it. --Jennifer (JBS66) 21:07, 27 April 2011 (EDT)
Well, personally, I don't have a problem with Unknown Unknown since it is very explicit. It says to me precisely that the given name is unknown and the surname is unknown. It's ugly but there is no ambiguity with what is unknown when "Unknown Unknown and Sally Smith" is displayed. But, to address the issue, I know the section starts with "When ADDING or creating a brand new person page", but the page is titled Naming Conventions and this section is on People, meaning people will refer to this to see the rules for naming people, whether they are creating a new Person page, or checking whether an existing one is valid, or seeing if their preferred name is okay. So assuming the rules embedded in the create process always apply seems to me to be a bad idea. On top of that, sometimes the surname is known and the given name is not, such as when the wife's married name is given in her father's will, showing she married a Mr. Doe. What then? Leave the given name blank? --Jrich 22:42, 27 April 2011 (EDT)

Scandinavian Names [22 February 2014]

Scandinavia = Denmark, Norway and Sweden

In Norse custom patronyms and matronyms were formed by using the ending -son (later -søn and -sen in Danish and Norwegian) to indicate "son of", and -dóttir (Icelandic -dóttir, Swedish and Norwegian -dotter, Danish and Norwegian -datter) for "daughter of". This name was generally used as a last name although a third name, a name based on location or personal characteristic was often added to differentiate people and could eventually develop into a kind of family name. Some Early Modern examples of the latter practice, where the patronymic was placed after the given name and was followed by the surname, are Norwegian Peder Claussøn Friis, the son of Nicolas Thorolfsen Friis (Claus in Claussøn being short for Nicolas) and Danish Thomas Hansen Kingo, the son of Hans Thomsen Kingo.

Eventually, most Nordic countries replaced or complemented this system with the prevailing "international" standard of inherited family names. In Norway, for example, the parliament passed a family name act in 1923, citing the rising population and the need to avoid the confusion of new last names in every generation. The law does allow a person to retain a patronymic as a middle name in addition to the surname, as was common in Early Modern times; this is not a common practice, but does occur, a modern example being Audhild Gregoriusdotter Rotevatn). In Iceland, however, patronymics are still used as last names and this is in fact compulsory by law, with a handful of exceptions.

Hereditary last names were mandatory:

  • Denmark: 1856
  • Sweden: 1900
  • Norway: 1923

The Norwegian Naming System

(This is a copy of an article by Johan I. Borgos, slightly adapted.)

The Norwegian naming patterns have changed through history. There are also regional differences. This text will try to explain the historical changes, and mostly with regard to the basic population.

It is convenient to look upon the first name as the real name. This was given to the child when it was christened. Way back in history only one 'first name' was the rule, but already before 1800 one can find many persons with two such names. Later on a child could be given three or even four 'first names', but only one of them was in use, perhaps two. Hyphenating two 'first names' is a newer custom.

The earlier use of 'last names' often confuses the genealogist of today, but was quite logical. Almost every person had a patronymic or father-name. If a man named Anders (first name) got a son called Jon, then the boy would be called Jon Anderssen, that is: Jon, the son of Anders. In some dialects the patronymic could be Andersson or Anderssøn, but the meaning is the same.

If Anders had a daughter called Anne, she would be called Anne Andersdatter, that is: Anne, the daughter of Anders. The spoken form, however, was more like Anne Anderste or Anderstet. Today Norwegian genealogists often use Andersdtr as an abbreviated form. The women used their patronymic all the life, married or not, but this custom began to change around 1900 or a little earlier.

Genealogists should use the patronymic as a clue for further search. If you find an ancestor named Ingeborg Nilsdtr, then you know for certain that her fathers first name was Nils. This helps to narrow the search. But of course it can be confusing to find a family where the fathers name is Anders Jonsen, the mothers name Ellen Hansdtr, and the children are named Jon Anderssen and Anne Andersdtr.

I should add that the patronymic could be dropped in the upper classes. In certain regions the patronymic was the only last name for most people, but as a rule one more 'last name' was added. They fall in two classes.

The most common pattern was adding the farm name, or 'address'. Let's use the example mentioned above. If Jon Anderssen settled on a farm called Bakken, he would be called Jon Anderssen Bakken, that is: Jon Anderssen, who lives at Bakken. If he moved to a farm called Vik, his full name would change to Jon Anderssen Vik.

Some families had a hereditary last name, a surname, often very old and in most cases of foreign origin. This was often the case in the cities or among high officials elsewhere in the country. If the family had a last name of this type, there was no need for a farm name. The hereditary names were seldom geographical names, as in the case of the farm names.

In the last decades of the 1800s a new pattern emerged, or rather two patterns. One was a radical change: A married woman could take her husband's patronymic. Anne Jonsen, that is: Anne, the son of Jon. Quite illogical! But the common people only copied the naming custom used by the richer people, they with the hereditary last names.

The other new pattern was this: The children got their father's last name instead of a real patronymic. But in a 'transition period' that lasted until 1923, one can find old and new patterns side by side, even inside families.

In 1923 it was ordered by law that each family should have a hereditary last name and only ONE last name. Some families took a patronymic, others a farm name, and of course the old hereditary names lived on. But the result was great amounts of Olsen, Hansen, Nilsen and names like that - old patronymics. Later on many last names of this type has been replaced by constructed names to avoid confusion.

It's not necessary to say that the fathers last name also became the family name. The women lost their last name. Today the wheel has turned again. The women as a rule keep their last names after marriage. Yes, even the old custom with a real patronymic can be seen. Anne Andersdatter lives again!

Norwegian Names on WeRelate [1 August 2014]

For people with a three-part name, that is: most Norwegians born before 1900, excluding some northern Norway fishing families, travellers, and immigrant families with hereditary surnames, we should write the names:

  • first name: all given names
  • middle name: patronymic - must be included in first name field - "last name"-pages for patronymics are normally useless until these were actually adopted as surnames (see above) - ideally a Scandinavian and especially Norwegian genealogy software and websites should have at least three name fields (like The Master Genealogist)
  • last name: farm name at birth, or surname if used - this will let the farm names generate "last name"-pages

If you only have information giving a first name and patronymic:

  • first name: all given names
  • last name: patronymic
I'd like to respectfully challenge the statement "patronymic - must be included in first name field" - which I believe was influenced by the automatic creation of surname pages, which no longer occurs.
First of all, WeRelate calls this field the "given name", and by definition, patronymics are not "given names" - they were not chosen by the parents and given to the child, but were a standard way of identifying family relationships, also useful for distinguishing one person from another with the same given name.
Secondly, everything (or virtually everything) I have read about Scandinavian patronymics (including the article by Johan I. Borgos, cited by the contributor) suggests that patronymics are last names or surnames. Now that WeRelate has stopped automatically creating surname pages from the surname field, there appears to be no reason to avoid putting patronymics in the surname field.
Thirdly, the WeRelate standard for Dutch names is "For pre-1811 people who never took a[n inherited] surname, the patronymic name is put into the surname field." The standard for Scandinavian names should be the same or people will get very confused when searching for people.
I agree with the contributor regarding the importance of farm names, which were an additional surname. These can be put in the surname field after the patronymic.
I am in the process of preparing my Norwegian family tree for uploading to WeRelate. Since this discussion is only on the Talk page and never made it to the Naming Conventions main page, I am going to assume that there is no standard to put the patronymic in the given name field, and that it is appropriate (now that surname pages are not being automatically created) to put both the patronymic and farm name in the surname field. Please reply here if anyone disagrees with this assumption, and we can continue the conversation.--DataAnalyst 02:37, 29 November 2013 (UTC)

Norwegian naming custom should not be lumped in with other Scandinavian names and certainly not Dutch names, as there are differences.

The most important names for family searches are the farm names, which behave quite similar to later last names/surnames - patronymics never do:

Omitting farm names when doing Norwegian genealogy is not good practice.

Annema 02:56, 29 November 2013 (UTC)

I am puzzled by your response, as I never suggested that farm names should be omitted. I agree that they are important in Norwegian genealogy, but that does not make the patronymic a given name. (Nor does it mean that patronymics are unimportant in tracing family lineage - they are actually a great aid that would be nice to have in other cultures where it is often uncertain which of several families in the same area with the same surname a particular person belonged to.)
I see nothing that suggests that patronymics belong in the given name field, and sources that suggest or explicitly call the patronymic a "last name" - which is supported by the fact that many people chose their patronymic when they were required to select a surname. Am I missing something?--DataAnalyst 03:34, 29 November 2013 (UTC)

I'm still interested in dialogue on this topic, and coming to a WeRelate standard for Norwegian names. In reviewing a few internet discussions, my sense is that the consensus among North American genealogy hobbyists has been to put the patronymic in the surname field, with the farm name following it, or in the suffix field, or as the only surname in an alternate name. I have seen at least one Norwegian endorse putting patronymic in the surname field (and farm name only in the place field) RootsWeb Archive - but that was back in 2000 and opinions may have changed since then.

On the other hand, I note two other Norwegians (not on WeRelate) who have put patronymics in the given name field. This makes me wonder if a practice has developed amongst Norwegian genealogists that differs from what North Americans are doing.

I really got the impression that the chief reason for moving the patronymic to the given name field was to avoid creating surname pages for patronymics, which is no longer a problem. In other words (speaking in the language I would use at work), there was a workaround for a software limitation which has since been removed, so the workaround should be discontinued. Now that I see that a couple of other Norwegian genealogists have been putting patronymic in the given name field (not as a workaround), it makes me realize that I may have been mistaken.

Besides the fact that the patronymic is clearly not a "given" name, I'd have to say that using farm name as the chief surname never really occurred to me because of the pattern I see on one side of my husband's family. In that tree, it appears that moving around was quite common. It took me about 10 seconds to find the following example in which siblings did not have the same farm name - Halvor Halvorson Evju (born 1836 in Evju) was the youngest of 7 children - the rest were born in Roteberg. Tracing paternal farm names through his father's line gives Roteberg, Roteberg, Valen, Rønningen, Rønningen, and tracing paternal farm names through his mother's line gives Leikvam, Lindheim, Nordadal, Nordheim, Nordadal, Nordadal. You can maybe see why I would not have thought of the farm name acting like a surname. At least with patronymics, all full siblings have (essentially) the same last name.

I suspect we will never get conformance to a single standard at WeRelate, because people will not be prepared to change what they already have in their own databases, and will want to upload them using GEDCOM (which I highly endorse because it avoids introduction of new data entry errors). But it would still be good to have a recommended way of entering Norwegian names. So I'm interested to know: Has putting patronymics in the given name field and farm name in the surname field become a de facto standard in Norway? Or was this just a way of getting around automatic creation of patronymic surname pages, which is no longer an issue?--DataAnalyst 04:28, 7 December 2013 (UTC)

One of my concerns has been the difficulty in finding duplicates if we don't all follow the same standard. I did some testing in the Sandbox and am no longer worried about this. It appears that the search for duplicates matches on full name, and it does not matter much whether the patronymic is in the given name field or the surname field. I could not test GEDCOM upload (which is not working in Sandbox right now), but I assume it uses essentially the same matching algorithm as "find duplicates".
Even though WeRelate no longer automatically creates surname pages, there seems to still be an advantage of putting the patronymic in the given name field. The "browse" section on the left works better with just a farm name than a patronymic and farm name together. So while my "purist" side still rebels against putting the patronymic in the given name field, I would be willing to switch. I plan to invite others who have contributed Norwegian data to WeRelate in the past year to participate in this discussion. Maybe we can get a bit of a discussion going and then come to a decision.--DataAnalyst 00:08, 11 December 2013 (UTC)

I strongly support the proposal to have three name fields for Scandinavians: first name (given), middle patronymic name, and last name (e.g. farm name) if any. In Denmark, pre-modern naming practice would depend on region. In Northern Jutland where, due to the topography, the settlement structure was dominated by single farms, three-piece names were common (with the farm name in third place). In the Danish isles, on the other hand, the settlement structure was dominated by villages with typically a dozen or two farms and smallholder houses, farms had no names and so most people only had the given name and the patronymic. A side track: Due to relatively few given names used, it wasn't uncommon for two farmers in the same village to bear identical first+surname, e.g. Jørgen Hansen. In that case safe ID was attained through a prefixed byname, such as unge Jørgen Hansen for the younger and gamle Jørgen Hansen for the elder (and the age difference need not be more than a few years). When importing genealogical data to WeRelate, I have refrained from putting patronymic names in the given name field, and instead invariably put them in the surname field. This means that the third name element, when present, should go into the surname field as well, resulting is unrealistic surname constructs like Sørensen Kalmer for Thomas /Sørensen/ Kalmer. Thus, I have put the third name element, when present, in the name suffix field. As this field was intended for something completely different, this solution is far from satisfactory. Hence, I support a three-piece model for Scandinavian names.--Hhbruun 08:47, 11 December 2013 (UTC)

I thought of requesting Dallan to add a separate patronymic field, but wasn't sure if it would provide sufficient advantage to be worth the effort. The advantages I see would be:
  • a clear standard, encouraging consistent data entry
  • consistent data entry might make GEDCOM matches and "find duplicates" and searching when adding a new individual more reliable, leading to fewer duplicate person/family pages (although my testing indicates that matching/searching works pretty well on the two fields, even without consistent data entry)
  • separate patronymic and surname fields would encourage entry of farm name, which many people miss
  • would not require patronymic (which is considered a "last name") to be put in the given name field in order to avoid a two-part surname (patronymic and farm name) in the browse link on the left-hand side of the person page
  • would (if incorporating the GEDCOM change below) allow people using different standards in their own databases to conform to a WeRelate standard without having to change their own databases (which only the truly committed contributors would do)
  • would support GEDCOM upload from genealogy programs that have a separate patronymic field
The additional effort would be:
  • Adding the patronymic field to entry, display, search and possibly other screens
  • Adding the patronymic field to the search algorithm
  • Adding a transform to the GEDCOM upload so that we don't have to manually move the patronymic to its own field (my software does not have a separate field for it, and I suspect most don't). What I could envision is that this transform would allow me to indicate (for an entire GEDCOM file):
    • patronymic normally in given field - please parse and extract to patronymic field
    • patronymic and farm name in surname field - please parse and extract patronymic to patronymic field
    • patronymic in surname field and farm name in suffix - please move these to patronymic and surname fields respectively
It is the GEDCOM upload I am most leery about - automatic transforms can be a bit tricky because they might not do what you want. On the other hand, this is fairly straight-forward parsing and would likely be pretty reliable (even if some records in the upload did not follow the same pattern as other records - such as patronymic in the surname field when it is normally in the given name field, if the farm name is unknown). The GEDCOM upload allows manual changes of each page, so if an automatic transform works on 90% of the records, you could manually fix the other 10%.
I am not sure that I would want a separate patronymic field unless the GEDCOM upload could do the transform - I'm not keen on having to do it myself, although I would if required.
Dallan, could you give this some thought and provide some advice from a system design point of view? You are in the best position to know how much effort would be involved in making the change and whether it would provide significant advantage in terms of searching/matching. Without a separate patronymic field and automatic GEDCOM transforms, we are unlikely to have people follow a single standard - maybe you can weigh in on your thoughts of the impact of that. (Also, if a single standard is not critical, and a separate field for patronymic is not warranted, how much effort would it be to parse the surname field for the browse links so that there is a separate browse link for each part of the surname (patronymic and farm name), ignoring words such as "van", "von", "de", "la" "le", "of"?) Maybe you can think of other suggestions as well. I'd be interested in your ideas. Thanks.--DataAnalyst 15:23, 13 December 2013 (UTC)
I'm sorry for not responding earlier. I talked with my mother who has done a lot of Norwegian research. She confirmed the importance of including the farm name. Rather than a separate name field, which would not be used for non-scandinavian names, I like the idea of recommending that both patronymic and farm names be included in the surname field. Some genealogy programs have only one surname field or make addding a second surname difficult so this approach is comatible with those pprograms, where people will.likely put both names in the ine surname field. And I will make sure that the browse links are created for each name in the surname field, omitting the various prefixes. How does that sound?--Dallan 19:00, 27 December 2013 (UTC)
Hello All, Dallan if I understand what you suggest would work for me. Some of do not know all the Norwegian farm names yet, or we know both. Having the option to use both, either or, and later having the option to adding an AKA or changing the surname field on WeRelate sounds good. I do admit I need to educate myself more on Norwegian & Swedish genealogy research I admit. Hoping everyone has a successful 2014 and more research success. --DFree 20:15, 27 December 2013 (UTC)
That sounds great, Dallan. Thanks. And I agree with DFree's comments.--DataAnalyst 21:22, 27 December 2013 (UTC)

Notice of Proposed Minor Change to Scandinavian Naming Standard
The standard for Norwegian names on WeRelate (which I proposed earlier this year), includes the following statement (emphasis added):

Where a written record uses the holding (sub-farm) name instead of the farm name (e.g., Kittel Johnsson Sagabukti, where Sagabukti is a holding in Kviteseid farm), the name can be entered this way as an alternate name, but the preferred name should include the farm name (e.g., Kittel Johnsson Kviteseid).

This was proposed based on a small conversation on the Norway talk page regarding the use of bruk names in person names (indicating that they are not commonly used in some areas). It appears that customs vary from place to place within Norway, and at the time I proposed the standard, I did not have a good feel for how often the bruk name (as opposed to the gård name) was used as a surname. I have since done statistics on my own database and discovered that in over 90% of the cases where I know the bruk where someone was born or died, the parish register gives the bruk name as the surname and rarely includes the gård name as well. I also realize now that at least some of the bygdebøker I have used also use the bruk name as the surname.

Therefore, I propose to change the standard by replacing the paragraph above by the following:

The farm name can be either a gård (main farm) name or a bruk (sub-farm/holding) name, depending on the custom in use where the person lived.

The main reason for proposing this change is that I realized, as I was preparing my database for upload, that I was assigning a surname (gård name) to someone that I never saw in either a parish register or a bygdebok - which just didn't seem right to me.

I'll leave this as just a proposal for a while to see if there is any response.--DataAnalyst 18:01, 1 August 2014 (UTC)

Swedish Naming Practices [28 November 2011]

Most people used patronymics, but they could also have additional names. See Hans Högman's overview.

The Names act from 1901 made hereditary last names mandatory, abolishing the patronymic system.

Types of additional or alternative names:

  • Latinized patronymics, typical for clergy
  • Names derived from heraldry, for nobility
  • Crafts names, guild names
  • Nature or topographical names
  • Soldier names
  • Farm names

Danish Naming Practices [5 December 2011]

Quoting Diana Gale Mathiesen: "Surnames became mandatory in Denmark in 1526, but only for the nobility. In 1771, surnames became mandatory in Slesvig-Holsten, DK. In 1828, surnames became mandatory throughout Denmark, but the law was largely ignored. Then, in 1856, the legal mandate to use a surname was strengthened, forcing the holdouts to give in and finally adopt a surname, making Danes among the last in Europe to adopt surnames, though not the very last. Surnames were not commonly used in Sweden until ca. 1900 or in Norway until 1923, and they are still not commonly used in Iceland."

"There is, lastly, the question of how to enter patronyms in your genealogy software. In my opinion, the patronym should be treated as a middle (given) name, not a surname. For those individuals who have only a patronym and no surname, the best course, in my opinion, is to leave the surname field blank, just as I believe that is the best course to take when the surname is simply unknown. [Please, never put the husband's surname in the wife's surname field just because you don't know the wife's maiden name!]

One advantage to not putting the patronym in the surname field is apparent when viewing an alphabetized index of your database because all those without surnames will be grouped together, in alphabetical order by their call names. If you put the patronym in the surname field, not only will these individuals be scattered throughout the index, it will not be apparent for whom the name is a patronym and for whom it is a surname, not unless you consistently enter patronyms in Initial Caps and surnames in ALL-CAPS, which is at least a viable alternative and one I strongly recommend if you insist on putting the patronym in the surname field."

I think that the lack of a surname is nicely handled by an empty Surname field. When "Unknown" is placed, that indicates that the person presumably has a surname but we just don't know what it was. If the automatic page add creates a page name with "Unknown" parts that I don't want, I just rename to the form that I really want (but usually, I am able to create the name as I like the from the start). This is how I handle pages for medieval folks and nobility.
One thing I havn't figured out is what to do with "<name> of <place>" forms, since "of <place>" has been commonly allowed to operate as a surname by the LDS. In truth "of <place>", "de <place>", "DE <place>" and "von <place>" probably belong in the title field - not in the surname field. --jrm03063 14:26, 28 November 2011 (EST)

I agree that an empty field is the best/correct option when there is no surname. Paragraph on other possibilities removed.--Annema 07:25, 5 December 2011 (EST)

For the Dutch pages on WeRelate, the standard when a surname is unknown is to enter the patronymic name in the surname field. This form is how the majority of gedcoms are submitted as well. In the Netherlands, surnames were primarily adopted in 1811. For pre-1811 people who never took a surname, the patronymic name is put into the surname field. For people who were born without a surname but adopted one during their lifetime, the surname is entered into the surname field. I can speak from experience that working with a lot of Person Unknown pages quickly becomes confusing. --Jennifer (JBS66) 09:42, 5 December 2011 (EST)

Resources on Scandinavian Names and Patronymics


Wikipedia on Patronymics

Proposed Standard

Given the discussion above, particularly on Norwegian names, and Dallan's opinion that it does not make sense to add a separate patronymic field, I propose the following standard for Scandinavian names lacking an inherited (modern) surname.

For regions using the form <given name(s)> <patronymic> <farm name> (e.g., Halvor Hansson Berge):

Given name field: <given names>
Surname field: <patronymic> <farm name>

The main name should include the farm name where the person was born (or the first known farm name if the person’s origin is unknown). Alternate names should be created for subsequent farms where they lived. There should only be one farm name per version of the name – that is, do not include alternate names in the same name.

Where a written record uses the holding (sub-farm) name instead of the farm name (e.g., Kittel Johnsson Sagabukti, where Sagabukti is a holding in Kviteseid farm), the name can be entered this way as an alternate name, but the main name should include the farm name (e.g., Kittel Johnsson Kviteseid).

For regions using the form <optional byname> <given name(s)> <patronymic> (e.g., Jørgen Hansen, unge Jørgen Hansen, or gamle Jørgen Hansen):

Prefix field: <byname> (if applicable)
Given name field: <given names>
Surname field: <patronymic>


  • Patronymic is not a given name, but serves in the original (c. 1300) meaning of the word surname – a “name, title, or epithet added to a person’s name” (Online Etymology Dictionary) to distinguish one person from another.
  • Provides consistent handling of patronymics across Scandinavia and some other cultures (such as the Netherlands). This encourages consistency of data entry, especially for people whose genealogy includes multiple cultures. Note, however, that this might not be consistent with names from cultures (e.g., Russia) in which patronymics are used in conjunction with modern (inherited) surnames.

Other Benefits:

  • Search results on families (e.g., when looking for duplicates) include the patronymic (e.g., Halvor Olavsson Flaatnes and Marie Mikkelsdatter Møgenes), making it easier to select the appropriate result. If patronymic is placed in the given name field, this family name displays as Halvor Flaatnes and Marie Møgenes.
  • Once Dallan adds a parsing function to the “browse by surname” feature, this approach will support more extensive browsing (by patronymic, by patronymic in place, by farm name, and by farm name in place). Browsing “by patronymic in place” can be useful for finding others with the same name to ensure that facts are attributed to the correct person.

Please respond, indicating whether you are aligned to this proposed standard, want to tweak it, or really can't live with it (and why). If there is no further discussion within the next month or two (or objections from WeRelate administrators), I plan to move this to the main Naming Conventions page to be considered a WeRelate standard.--DataAnalyst 22:59, 3 January 2014 (UTC)

Offer to Help Convert

If the above standard is accepted (and once Dallan has made the change to the browse feature), I am willing to help convert existing names that have been entered with patronymic in the given name field.--DataAnalyst 22:59, 3 January 2014 (UTC)

Browse links are now created for each part of the surname [23 February 2014]

Additional browse links are now created for each space-separated part of the surname, excluding prefixes like von, van, etc. as well as the full surname. Please let me know if you find any problems. Thanks--Dallan 20:50, 22 February 2014 (UTC)

Thanks, Dallan. I have added the proposed standard to the naming convention.--DataAnalyst 14:10, 23 February 2014 (UTC)

Dit names - seeking discussion [30 December 2016]


As part of refreshing the Help pages, including data entry conventions, I'd like to get the community's reaction to the following convention, which I extracted from the Help:Style guide.

  • Dit names: Enter the full version in the Surname field: Destroismaisons dit Picard.

A "dit name" is an alias - this article explains the concept.

The current convention has not been followed at WeRelate - in fact, it appears that a few years ago, many dit names were moved from the surname field to the suffix by someone not aware of the style guide. This says 2 things to me - not everyone agrees with the stated convention, and we have nothing to lose by changing it. Therefore, I thought I would open it up to discussion, with the hope of getting feedback from those with expertise in French and/or Quebec genealogy.

My thoughts (based on virtually no experience with French names):

  • Including the "dit name" in the surname field means it is included in the page title and therefore is more visible wherever WeRelate displays only the page title. (Advantage of current convention)
  • When creating a record, the "dit name" might not be known. If one person creates the page with the dit name and another without, the page titles will be different, and this might impact the automated identification of duplicates to be resolved - this has not been verified. (Potential disadvantage of current convention)
  • Putting the "dit name" in the suffix field (as has been done) adds a comma in the display. (Disadvantage of this alternative to the current convention)
  • "Dit names" are aliases - maybe they should be treated as alternate names instead of being added to the primary name. However, it seems that people expect them to be part of the primary name (and visible).
  • Limited testing in the sandbox (see Guyon Chiasson and Jeanne Bernard) shows that if someone searches for the family using the dit name (in this case "chiasson dit lavallee"), only pages with the dit name in the surname field (and thus in the family page title) will be returned. Searching on person pages is not as sensitive. (This seems to be an advantage of the current convention, because we can't control how people will search)--DataAnalyst 23:38, 30 December 2016 (UTC)