WeRelate talk:Support

Old topics have been archived: 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017 | 2018


Who is WeRelate.org? [15 February 2019]

The about page says "sponsored by" which suggests to me "separate from".

One sponsor is Foundation for On-Line Genealogy, Inc.; but the link points to website that does not exist.

A Whois lookup for both folg.org and WeRelate.org tells us that both of these domain names are registered (owned) by Dallan Quass and does *NOT* include name of any organization.

Registry Registrant ID: CR31178024
Registrant Name: Dallan Quass
Registrant Organization:

I've added a lot of data to this site. What happens to this site when Dallan stops paying the registration fees? Is there a legacy plan in place?--fbax.ca 19:11, 7 January 2019 (UTC)

Good questions. Thanks. --ceyockey 04:08, 8 January 2019 (UTC)

FYI: the 2017 return for the public charity Foundation For On-Line Genealogy Inc is available on this IRS website, and shows 2017 total "support" of $3751, apparently about half from member donations and half from "unrelated business activities" which I presume is from the website adverts.--robert.shaw 20:53, 8 January 2019 (UTC)

These questions come up every year or so, and ttbomk the answer remains the same. WeRelate was started by and still is run by Dallan. He was/is also the leader of the Foundation which recruited ACPL to work on this wiki project in the early stages. They no longer do. The site runs on an older version of code and there is no plan to update the version in the future. There is no legacy plan in place. Eventually the rest of the tech world will move far enough along that the data here will no longer be easily accessible. No one knows exactly when that will be.

In the meantime, it's a personal choice whether or not you wish to continue working here. Most early users have moved on but there is a core group that remains. Different folks have different reasons for sticking around. Dallan has recommended entering into the FamilySearch FamilyTree if you want to have a better guarantee of online data preservation.

Hth, --cos1776 15:15, 10 January 2019 (UTC)

At last, someone is posting here about what ultimately matters: the survival of WeRelate. The coding is out of date and therefore unsuitable for current browsers. The site is overdue for a complete coding re-write, and it is worthy of one. I have personally given up adding to my trees because I anticipate that WeRelate will disappear before long. I purchased a copy of Family Historian to use on my own computer, however I feel discouraged by the impending loss of this facility here, and 'my' lovely pages which I put so much into. Surely something could be done to rescue WeRelate? Dallan should pass it into the hands of people who still have the passion for it which he has apparently lost, (which happens). The data is not HIS personal property. Could it be sold to one of the mainstream genealogical sites? Does any user know of web designers who would tackle it - maybe students? We need to be working together to seek out a solution. --Helen-HWMT 18:00, 11 January 2019 (UTC)

When you say "most early users have moved on", where have they moved to, if you know? What you've said reflects a thought that it's no longer productive to contribute here because the resource could disappear at any time as Dallan is a single point of failure. I've started archiving pages in Internet Archive in a minor way; fortunately, if you archive one member of a family tree, then it appears IA will crawl in time the full family if the members are associated by simple links. --ceyockey 22:46, 10 January 2019 (UTC)

I've seen familiar old usernames working at other genealogy sites, such as Dallan's subsequent project Rootsfinder, FamilySearch FamilyTree, the other wikis, personal sites, etc. For me, personally, I had to cut way down on the amount of time that I spent on genealogy, so the little time that I did have last year was spent on shoring up the pages for my relatives at FSFT. I do think that the longevity prospects there are better. Don't get me wrong, I have been an ardent supporter of WeRelate for many years, and I think it is a terrible shame that the support for the site waned. Believe me, it isn't for lack of trying by the user base. There have been several concerted efforts among small groups of users to revive the mojo over the last 6 years or so, but the decision to stop updating the code sealed the fate.
Given the circumstances, each user has to decide for themselves whether or not they wish to continue to work here. There are still plenty of good reasons to do so. I keep coming back because I think WeRelate has one of the cleanest page designs of all the wikis and the most straight forward method to examine, understand, and handle wiki page revisions. WR still provides a good place to gather and document research and a fairly active community to monitor the information being posted. If longevity is a concern, it is still possible to work on pages here and to transfer that work to other programs for backup.
Lastly, I can say unequivocally that most of those who are still here are genuinely dedicated to posting accurate and thoughtful information. They are usually engaged and helpful, and have spent countless volunteer hours in efforts to improve the site. I am thankful to have had the opportunity to work with them over the years. --cos1776 18:12, 11 January 2019 (UTC)

Years ago a few of us suggested trying to hand WeRelate over to the Wikimedia Foundation (which runs Wikipedia). There was some interest from their end but we got a lot of pushback from folks here who didn't want to lose control. Perhaps it's time to revisit that possibility? --Jdfoote1 18:18, 11 January 2019 (UTC)

I think you are referring to Wikimedia Genealogy Project which states WeRelate was proposed in 2007. --fbax.ca 04:53, 12 January 2019 (UTC)

This is the best description of what has happened to WeRelate that I've seen! And I'm still grieving the eventual demise. I've tried to go to WikiTree which has become very popular, but for ease of use, WeRelate beats them by several miles! I'm not happy with the advise to go to Family Search; I'd much rather there had been some way to pay for the needed code update and then occasional programing updates. Why didn't we start a Go-Fund-Me account and get it done? Or was that option even around at that time? --janiejac 00:49, 12 January 2019 (UTC)

I have over ten years invested in WeRelate.org. Like janiejac I fear one day it will simply stop, and the good data that many have contributed will be lost. So far, we have been assured that this should not happen. Even after ten years, not a week goes by that I don't post 2 or 3 items correcting an error in some published genealogy. Surprisingly, not infrequently, major ones. The fact is that the vast majority of what passes for genealogy is people simply copying the work of others with no clue if it is right, and often, it is wrong. The harder it is to find the answer, the more people copy unvalidated work. The only way to fix this is to have to interact with people that know better.

That is what I hoped WeRelate would be good for: sharing and review of research with the goal of collecting in a single place generally correct genealogy. For people interested in broadcasting and preserving their research, just as they have it, this may not be the best place.

Genealogy is an area where amateurs can contribute. The focus on one's own family, often not of interest to professionals, can motivate the dogged persistance that can uncover new facts, especially as the Internet places vast libraries at our finger tips. A place is needed where such research can be exposed to others, and reviewed.

But the hubris of self-centered research must be controlled for collaboration to occur. Collaboration in genealogy without the computer is two people, each with their own records and their own space, sharing sources, each one having access to something the other has not seen. You don't overwhelm people with useless sources, or twenty copies of the same thing, you share essential sources, the primary sources that must be answered to refute the conclusion. Your goal is always to find the truth, as best as can be known.

In WeRelate, the single unified tree forces collaborators to reach a most-likely consensus (our best guess at what is the truth). One may not be entirely comfortable with the result, but if you can't explain away all the contrary evidence properly, you yield and go hunt for more evidence. An answer without evidence has no value, it cannot stand even the simplest challenge. Only an argument with evidence has value.

Sometimes, you do have enough evidence. Perhaps you contradict every source you have ever seen because you can add one will, one deed, one letter, or one diary entry. This could be valuable to the world and should be shared. And you want it reveiwed to make sure you didn't misinterpret something, didn't use a discredited source, didn't allow some assumption to creep in, didn't miss some fundamental source. This is what WeRelate should be for: sharing of sources and evidence, with feedback.

Unlike janiejac, I do not think funding software changes is the answer. For one thing, I do not think there is consensus about what will make the site better.

The value of this website is in the data, not the software, and that is why I stay at WeRelate. It has developed a collection of quality data in certain locales, and has a core of users that have a committment to sources. I keep hoping at some point, it may cross some threshhold where it has enough quality data to became a place where researchers-in-the-know, or some subset of them, come.

A recent investigation of a prominent colonial American at wikitree yielded a page full of Ancestry references. That indicates to me a culture that is not yet developed and research that would have no value to me. Why not just join ancestry?

Wikitree also has page managers. I have not interacted with any there, but have in other places, and all my experience with page managers is negative. While WeRelate has no dispute resolution process, I'd rather deal with unmoderated changes than with newbie page managers protecting their own research.

The design of WeRelate used a lot of freeform fields and did not add much structure, so it can be relatively simple to enter data, and flexible enough to handle weird situations. I would like more structure because data is only entered once, and then used over and over again, so investment in careful entry is greatly leveraged. But the fact is, I can get what I want into WeRelate relatively easily, so I can live with the system as it exists.

There are many changes I think are necessary. Most require administrative time and effort, something the powers that be want to minimize. So they will not happen. But the site mostly works, and I keep trying to add the one feature I think is most important: quality data. --Jrich 16:19, 12 January 2019 (UTC)

I agree with much of what you've written, Jrich, yet I have the feeling you may be missing an important aspect of this discussion. It's clear that you value this website since you haven't found any others with the collaboration and concern for correctness that WeRelate offers. Those aspects depend on the people who come here (the community) and on the software which the site runs. If the community and the software are not maintained, the site will in not too great a time cease to function, and then disappear with its data, its collaboration, and its reputation. Maybe the data can be saved, but the collaborative community will not be easily rebuilt.
I have the distinct impression that the WeRelate community is shrinking. I suppose it seems that way to me from watching the postings that appear on the Watercooler and Support pages. Over the past year or two the frequency of postings seem to dropped off, suggesting a decline in community involvement.
Generally I feel that if software does the job, there's little need to change to a more current version. (I'm still using Office '97, for instance.) For websites, though, the datedness of the website software is more important because the browser and net environment used to access the site continues to change, not suddenly, but relentlessly. WeRelate did manage to deal with the new emphasis of clients on https:, but other issues will continue to emerge. One potentially severe issue is looming: next year "Flash" will no longer be supported by its provider, and browsers are expected to completely drop the limited, opt-in, support they currently have. WeRelate uses Flash in multiple places; two I believe are in the Family Tree Explorer and in the Gedcom submittal review and integration module. It's likely there are others. If nothing is done, access will become harder and more limited, and likely fewer people will choose to use the site. Fewer people means fewer donations and less advertising revenue, and eventually that means server costs can't be met and the site shuts down.
Given these considerations, it seems to me that software maintenance and/or a postmortem legacy plan are important for most all users of WeRelate. --robert.shaw 19:23, 12 January 2019 (UTC)

I have been reading and re-reading the various, thoughtful contributions on this topic. Thank you for all these posts. It is such a relief to me that this is being discussed - for the first time in 18 months.

It seems to me that one of the causes of difficulty is that, probably, none of you live either near enough to each other, or near enough to Dallan, to have met face to face. A conference would bring a break-through nearer! Maybe a date could be set, say a month from now, for something like a Skype conference?

There are really only two obstacles to progress: agreement about what needs doing, and funding to get it done. Re-coding need not alter appearance nor functionality. The new site could seem just the same, but would work properly on all current browsers, and for some years to come. janiejac has mentioned crowdfunding, and that seems feasible. A strong plea could be composed, and there are millions of family history hobbyists to appeal to.

Jrich: without either a handover to some organization able to invest in WeRelate, or re-coding, the site we love will definitely die. The Internet does not stand still. I don't know how others manage to navigate WeRelate, but for 18 months there has been no way that I can make FTE work. Even enabling Flash for the site didn't help much. I can pick a page from a search list and get in that way, or Google an ancestor's name and get in that way, or use one of my tinyURLs, then move about via links. With that level of inconvenience, there is no way that WeRelate will enjoy a membership surge! Income is bound to keep falling.

The coding issue is not just about Flash. The up-to-date page languages are HTML5 and CSS3 (a combination which can do amazing things), whereas WeRelate is in XHTML 1/0 Transitional.

Cos1776: Who are ACPL? And, you speak of a "decision to stop updating the code" which "sealed the fate": what happened exactly?

A long time ago, I posted: "I wondered whether any website training facility would give us a special rate for a new site? - Supervised students. Could there be any grants or special deals because of our valuable historical data....." --Helen-HWMT 22:14, 13 January 2019 (UTC)

I would love to see WeRelate turned over to some management group. We had an active group of admins volunteer recently and they ended up waiting for Dallan to approve everything. Nothing requiring any software changes could go anywhere. Dallan got involved in other software projects, and basically had little time for WeRelate, and I don't know how it could be turned over to a group that is, or if he would let it if such a leadership group were found. In the old days, decisions were made by Dallan and he was the one person who could do so with any expectation of people cooperating, but this has been a drifting ship for a long time.
Updating the software is hard because wikimedia software has changed so many times that one would probably have to start over, download the existing WeRelate data into a massive GEDCOM and then upload it. Undoubtedly many features would break that people have used because they are not supported by wikimedia any more or work differently. Even if Dallan wanted to do the software effort, the admin effort to transfer the data would be huge.
Then there would need to be a plan for ongoing maintenance so the same scenario didn't just happen again.
The FTE works on my browser (firefox), and while I use it, it is not a drop-dead feature. A replacement wouldn't need to be identical, so insertion of some other mechanism would cause some learning but should mostly be a one-time software effort with no data conversion required.
GEDCOM upload is actually a feature I would vote to remove anyway because I think it is hard to craft an entry in a GEDCOM that comes out in WeRelate the way I want it, and certainly my raw data is not suitable to be uploaded straight (embedded names and addresses, famiy-centric comments, personal research log, personal abbreviations, not written for mass consumption, not concise), so for me, it involves building a GEDCOM and then spending hours more massaging it in WeRelate. I'd rather just type it into WeRelate. I know that's just me, but my observations suggest the bulk of other people's GEDCOM use is not resulting in quality submissions.
ACPL is Allen County Public Library. They have a great genealogy section in their library if you're ever in that part of Indiana. As mentioned they were involved in the early days of WeRelate. --Jrich 00:20, 14 January 2019 (UTC)
Jrich, I am using Firefox and I can get FTE to open but regardless of what I do it always displays a blank tree. I am wondering what is your secret sauce? --Jhamstra 17:18, 20 January 2019 (UTC)
Don't know. Sorry. --Jrich 18:52, 20 January 2019 (UTC)

Thank you for the wake-up call with this discussion. I have not posted on other sites and have been wondering about this site's longevity. I initially thought it was sponsored by the Allen County Library, which has a large genealogy endowment (I understand). I have been unable to do genealogy for several months, but now will be able to get back into it and need to do some research on how to protect all the hard work. Most people I have told about it have never heard of it! It did have a long learning curve for me. Diane Hosler--Diane Hosler 20:07, 12 January 2019 (UTC)

A few (belated) thoughts:

  • As has been mentioned, WeRelate is supported by me (Dallan) and my wife (Solveig). The ACPL stopped being actively involved several years ago.
  • Because the number of people who use WeRelate is small (albeit wonderful), WeRelate doesn't bring in enough revenue to support a full or part-time software developer. I have no plans to take the site down, but as has been mentioned it will require periodic maintenance over time. I'm volunteering to do that, but I would like some help if possible. The software is completely open-source, so anyone who wants to help is welcome.
  • I'm happy to involve anyone else who is interested in management and support. Currently DataAnalyst helps out with GEDCOM uploads (thank you!). If anyone else is interested in helping out in any way, please speak up.
A correction. Cos1776 is helping with the GEDCOM uploads. I have been deleting pages for living individuals and handling the Speedy Delete page periodically. --DataAnalyst 14:26, 20 January 2019 (UTC)
  • I'm also happy to turn over the site to WMF. We made a proposal several years ago, but the challenge is they'd want the site to run on essentially unmodified software, so we'd lose a lot of functionality, and it would require a re-write.
  • There are other wiki-based trees that have grown more popular than WeRelate (for various reasons), namely WikiTree, Geni, and FamilySearch. I've talked with Chris Whitten at WikiTree about some kind of a merger in the past and he's generally open to the idea. But it would require a lot of manual work to merge the databases if we want to go down that route.
Dallan: That there are so very few alternatives to wiki-based shared trees out there shows that this technology is still in it's infancy. You are a pioneer! Several sites mention encouraging new users. You did what others have missed; allow access to the data without creating an account! This simple feature is what allows my friends to view the work I do for them whereas they will not visit sites that require them to create an account.--fbax.ca 16:31, 20 January 2019 (UTC)
I agree with you, Fbax. Allowing visotors to view public data without having to create an account, is a major advantage for those of us who wish to publish our research. --Jhamstra 16:45, 20 January 2019 (UTC)
  • I think we have to accept that more people want to use personal-tree websites like Ancestry trees, MH trees,etc., than wiki-tree websites like WeRelate. That's why I turned my attention to RootsFinder, a personal-tree website, to see if I could build something that got more people's attention than WeRelate. The eventual goal was to combine RootsFinder and WeRelate, but when I brought that up here awhile ago, there didn't seem to be much interest.
  • The big issue with personal-tree websites is the difficulty of collaborating with distant relatives. Collaborating with close relatives is easy - just invite them to edit your tree and create a shared tree together. But that doesn't work with distant relatives. The unsolved question is: how can you keep some of your tree private, but collaborate with others on other parts of your tree? I can think of three possible solutions to this problem:
1. Allow users to create "hyperlinks" between people in separate trees. So for example you could say that the father of person X in tree A is person Y in tree B. As you navigated from son to father, you would also navigate to a different tree.
2. Allow users to specify that WeRelate or FamilySearch is the "master" tree for a particular person, and that the copy of that person in their RootsFinder tree needs to be kept in sync automatically with the master copy. So if one user updates the person, then that change is automatically applied to all other copies in other users' trees.
3. Same as (2), but specify that another RootsFinder tree is the "master" tree for a particular person.

Right now I'm leaning toward (2), implementing FamilySearch sync first. This would allow RootsFinder users to use personal trees and collaborate with distant relatives via the FamilySearch wiki-based tree. I could implement WeRelate sync as well if there was sufficient interest.

I think the initial question is: do we want to keep WeRelate going as-is with software maintenance as needed to keep the website from breaking? This is a perfectly viable option in my opinion. Or do we want to consider a path that's more radical? This question doesn't need to be answered right away.--Dallan 22:45, 19 January 2019 (UTC)

(For what it is worth) I don't see much difference in collaborating near or far. In no way do I want to turn over control of my tree to another, but I want to be informed. What I share depends on my audience. So I keep my private data somewhere only I can change. And I get notified when a change is made to the public tree so I can review it. The word "sync" scares the bajeebers out of me. But a notification process would be useful.
Of course once reviewed, a change is either accepted or rejected. If rejected, I don't want to be notified ad naseum. Actually there's a third possibility: I find the data interesting but it's not possible to prove one over the other.
Perhaps some part of the incorporation process can be automated after review, but it may need to be granular: accept the birth change but not the death change - that belongs to a different person. Finally, how to handle the overwritten data is an issue. Keep a backup so it may be easily reinstated, keep it with an explanation why it was rejected, etc. Facts can be formatted. The facts may be the same but they may have added a higher quality source (or alternately added a derivative source when I already have the primary). And comparing free-form narrative? Voice recognition and AI may be here, but don't think they're ready for that. --Jrich 15:35, 20 January 2019 (UTC)
Over the years Dallan and I have engaged in some in-depth conversations regarding how to upgrade WeRelate and/or what kinds of features to incorporate into a newer web site. And we are discussing his ideas as outlined above in a private conversation right now. I do agree with Jrich that anything involving "sync" between multiple different trees and/or web sites is fraught with perils, especially where different web sites employ different data models. But if we could figure-out how to do this in a reasonable and reliable manner it would be very useful both as a migration tool for WedRelate users, and also others wanting to link data across various family trees. My own opinion is that the Holy Grail of genealogy web sites, would be a site that combines individual and shared trees, and I am still hopeful that this can and will eventually happen. --Jhamstra 17:26, 20 January 2019 (UTC)
My personal analysis long ago was that this type of activity would require an massive update to GEDCOM. An interface that would allow queries to be sent and replies received between software programs, etc. Not an easy undertaking, probably requires a consortium of major users. --Jrich 18:52, 20 January 2019 (UTC)
For a completely general solution, you are probably correct. For the special cases involved in Dallan's suggestions (2) and (3) above, I do not see any reason to mess with GEDCOM. Why? Dallan wrote the code for RootsFinder and WeRelate. Certainly he knows how to search and sync across these two web sites. Given his prior role as CTO for FamilySearch, he probably knows how to search and sync between RootsFinder and FamilySearch (from my own testing searching FamilySearch from RootsFinder already works reasonably well). --Jhamstra 21:25, 23 January 2019 (UTC)
Regarding trees that contain private data; I'd like to see a feature I suggested to Rootsweb World Connect 15 years ago (never accepted). WC is based on upload of GEDCOM file with living persons hidden. During upload; user can specify a specific year (say 1920) to indicate a person born before that year is considered deceased and data is presented on website. I proposed that this feature be modified from year age (say 100 years) and GEDCOM's be re-processed every year (perhaps on anniversary of last upload); this would auto-release more data every year. When building a personal family tree website; the same issue exists and I don't see any current website addressing this issue. If users do not agree to auto-release private data after 100 years; what was the point in entering it? It could very well be locked up forever! --fbax.ca 18:05, 20 January 2019 (UTC)
Dallan, I think I speak for almost all WeRelate users, that we appreciate all of your good work to create this web site and keep it running. I do not doubt your commitment to doing what is necessary to keep the web site running. But nobody lasts forever - this is true both of individuals and of corporations. We all need to admit that at some point either WeRelate will die or it will merge into some other ongoing entity or it will need a formal, legal, survival plan. You might want to seriously consider transforming FOLG into a self-perpetuating entity rather than a family hobby. --Jhamstra 17:09, 20 January 2019 (UTC)

Just to express my deep appreciation to everyone who has been thinking this through and posting here. In case it is relevant, Find My Past have a new 'world tree' in BETA. See [1] It may be possible to have some minor influence on how this develops. Concerning privacy, I think that the WeRelate system of only including deceased individuals, whose partners are also dead, and making those pages fully public and find-able, is the ideal. Several distant relatives have found pages via searching the Web. Living people should only be in off-web trees. --Helen-HWMT 17:51, 21 January 2019 (UTC)

Jhamstra, I'm completely open to opinions on developing a formal, legal, survival plan for FOLG. What do you and others have in mind? Also, what would a "site that combines individual and shared trees" look like? I'm very interested in this.
Dallan, Generally closely-held non-profits solve the succession problem by forming a self-perpetuating Board of Trustees. A typical structure would entail a Board comprising a minimum of 5 Trustees (with more Trustees elected by the existing Trustees whenever they deem it to be appropriate. When and if the number of surviving Trustees falls below the minimum (due to death, incapacitation, resignation, etc), the surviving Trustees elect sufficient additional Trustees to replenish the Board above the minimum threshold. The Board could solicit nominations and/or volunteers to serve as Trustees, from among the active participants on the WeRelate wiki, however the existing Trustees would make the final selections. Details vary from State to State but this is a very common approach.
Regarding the combination of individual and shared trees on a single web site, I think this would be a logical next step beyond the enhancements to RootsFinder, that we are already discussing off-line via emails. I suggest we continue to explore this concept off-line. --Jhamstra 02:25, 22 January 2019 (UTC)
Let's suppose the we have a board of trustees and the site goes down. What will the board do? I don't see how the board will help ensure the longevity of the site. Can you educate me?--Dallan 20:29, 23 January 2019 (UTC)
As long as you are willing and able to carry-on in your present role, presumably the board does not need to do anything. When and if that assumption no longer holds, then the board would be authorized to find one or more persons to take-over your responsibilities. Legal title to the WeRelate web site would be vested in FOLG. The board would be legally empowered to carry-on the work of FOLG. Nobody is suggesting any desire to push you aside (that I know of), only to have some succession plan in-place.
The board could also engage in activities (eg fundraising) that you do not have time to pursue.
--Jhamstra 20:49, 23 January 2019 (UTC)
Helen, if we could have an influence on FMP's world tree, what would be ideal?--Dallan 00:38, 22 January 2019 (UTC)
Dallan: If the best way to give WeRelate’s data a future, were to sell to a genealogy company, then it could be useful to know that there is a world tree in BETA. It might be possible to get some WeRelate distinctive features incorporated, such as our formatted person pages with proper headings and embedded images. I would think it technically possible to have Wiki-style pages within a typical genealogy set up. --Helen-HWMT 23:07, 23 January 2019 (UTC)

I read all this but not sure what it means. Is this site a viable alternative to WikiTree? I can't, or won't actually, add more profiles there (I slipped up and added one this week, then thought what the heck was I thinking). I'm tired of the junk, both data-wise and policy-wise. My original intent was an online archive of good quality so I could leave it for someone to find in the future. I knew back in 2016 that WT wasn't going to be the right place for that. I have some serious aversions to trying to do the same on the LDS site. So there really isn't much else. I wanted to take a look at Rootsfinder but so far haven't been able to connect (my wifi sucks). I've been here browsing before but I did not much, if anything, yet.

P.S. no add topic button/link as help page says--Mekehl 05:00, 15 February 2019 (UTC)

My take on the above: Although the site supports itself, it has trouble getting modest software needs met, and people are concerned about the long term availability of the valuable data on the site should the site disappear for some reason. (The data is open licensed, so it can be copied; that's not the issue.) IMHO, yes, WeRelate is a viable alternative to WikiTree. The concerns are basically reasonable, but I do feel it's likely the data would get resurrected elsewhere should the site someday shutdown. The LDS FamilySearch Family Tree is in no danger of shutting down, but it has many inexperienced researchers mangling data in the common tree.
P.S. You should be able to see the "Add topic" link near the top of the left-hand sidebar. --robert.shaw 06:22, 15 February 2019 (UTC)

Perennial questions / proposals [11 January 2019]

Maybe we need to have a Help section page that is akin to wp:Perennial proposals? --ceyockey 23:03, 10 January 2019 (UTC)

Your "akin to" link is broken. fbax.ca 20:07, 11 January 2019 (UTC)

You're right. I didn't account for the target page being in the Wikipedia namespace --> wp:Wikipedia:Perennial proposals. Thanks --ceyockey 03:23, 12 January 2019 (UTC)

Events without Citation ID [25 January 2019]

Is there a way to search for events without Citation ID (ie: no sources)? --fbax.ca 17:48, 12 January 2019 (UTC)

Maybe you could explain a bit more what you are trying to do. Events such as birth and death are searchable. Thanks for some examples / use cases. --ceyockey 02:45, 19 January 2019 (UTC)

I have a tree with 204 persons. +Tree:"Fbax.ca/Bax3"

What would I add to search parameters to include Maria and exclude Willem from results? If I need to execute search for each event type separately that would be fine. --fbax.ca 02:54, 19 January 2019 (UTC)

There is a category Category:Sources Needed that lists pages with no sources, but that requires somebody has marked them as needing sources manually.
I can find pages with sources, but not sure how to find ones without.
Look at [2] which shows you the raw xml that describes the page. Notice sources are defined by source_citation tag.
If I search for Person given name Willem surname Snoeij, exact match, there are 2 found. One has sources, one does not. If I add source_citation to the keyword field and repeat, I get only one result, the one that has sources. Don't know how to ask for something that is not there though. --Jrich 06:32, 19 January 2019 (UTC)

Thanks!! Using keywords "source_citation" and "event_fact" appears to do the job:

+Tree:"Fbax.ca/Bax3" --> produces 204 results.
+Tree:"Fbax.ca/Bax3" +source_citation --> produces 72 results - all events have source.
+Tree:"Fbax.ca/Bax3" -source_citation --> produces 132 results - some sources missing.
+Tree:"Fbax.ca/Bax3" -source_citation -event_fact --> produces 25 results - no events.
+Tree:"Fbax.ca/Bax3" -source_citation +event_fact --> produces 107 results - some events are missing source.

--fbax.ca 20:14, 19 January 2019 (UTC)

Further research shows that with the above technique a Person/Family is not included in report if there are multiple events and any of those events has a source attached. :( Using action=raw that I read about elsewhere; I wrote a script to download all data for a tree into a directory; then ran

grep event_fact * | grep -v source

Works great! --fbax.ca 01:53, 25 January 2019 (UTC)

Preservation of content via Internet Archive [7 February 2019]

I have found that, given a set of linked individuals in a multi-generational family, if you place one page into Internet Archive, the IA engine will suck the rest of the family in via link crawling. Has any consideration been made about seeing if we can implement the english Wikipedia Internet Archive Bot to save WeRelate en masse to Internet Archive? --ceyockey 02:48, 19 January 2019 (UTC)

FWIW, I'd be happy to make the xml dump file with the contents of the current wiki pages available to anyone who wants to pursue this.--Dallan 21:47, 19 January 2019 (UTC)
We discussed this a bit a few months ago, Dallan, but I would be happy to make this happen. --Jdfoote1 15:46, 21 January 2019 (UTC)
How is a page added to Internet Archive? --fbax.ca 15:43, 21 January 2019 (UTC)

To add a page to the Internet Archive, put the URL into the entry box at https://web.archive.org/ and return. If it is already present in the archive, instances will be shown on a calendar view. If it is not already present in the archive, a link down the page will show up which will archive the page when clicked. That's the one-by-one method that I typically use. There are other methods using batch and automation functions. Wikipedia uses a bot to crawl references and add the references to Internet Archive, rather than the wikipedia pages themselves; see wp:User:InternetArchiveBot. --ceyockey 23:36, 21 January 2019 (UTC)

If we do this, we need to be reasonably sure that we don't have information about living people on any pages, since once the data has been posted to the Internet Archive, I'm not sure how easy it would be to take down. I haven't been browsing the site for possibly living people; have others noticed pages for living people lately?--Dallan 00:28, 22 January 2019 (UTC)

Yes. I am within one week of handling all the pages that actually say Living, but there are many more pages for living individuals - I have found and deleted several in recent months. I don't think we are ready for archiving yet.--DataAnalyst 23:26, 23 January 2019 (UTC)
So, I think that the easiest and most complete way to do this is to upload Dallan's XML dump. How much work do we think it would take until we feel reasonable confident that we can archive the data without having any personally compromising information.
My personal opinion is that just having living people's names and/or approximate birth dates in the data is not a deal-breaker. What we really need to avoid are things like SS numbers, etc. --Jdfoote1 01:48, 6 February 2019 (UTC)
The InternetArchive accepts URL's; one at a time. Rather than an XML dump; the functionality required to feed InternetArchive already exists! Access the search page; specify namespace=people and leave all fields blank; all 2.9 million results currently in database are returned! We could simply give InternetArchive the link with all GET parameters specified and it would do the rest. --fbax.ca 04:17, 6 February 2019 (UTC)
Archive-It is a subscription service that supports domain indexing in an automated manner. Don't know if this has an associated cost or not. See https://www.archive-it.org/blog/learn-more/ . --ceyockey 02:44, 7 February 2019 (UTC)
Archive.org also supports archiving things other than web pages. For example, this is a dump of 300K+ wikis from Wikia in XML format. In our case, an XML dump would be a much better format for the recovery of data in the future. --Jdfoote1 15:21, 7 February 2019 (UTC)

I would urge caution about pursuing this at this time. For one thing, WeRelate is still an active and growing (slowly) site. There is no need to archive the data yet. There are many pages for living individuals, as well as many errors yet to be corrected. As with any genealogical site, errors will always exist - why would we want to freeze them where they continue to be referenced and used but cannot be corrected? If it becomes impossible to keep WeRelate operating in the future, then we can consider an archive, but for now I only see the downside. --DataAnalyst 00:38, 7 February 2019 (UTC)

Internet Archive is not frozen; it will continue to crawl the website (on unpredictable schedule) and copy updates. --fbax.ca 02:12, 7 February 2019 (UTC)
The role of archiving at this stage would be in Disaster Recovery rather than Accurate Secondary Reference. --ceyockey 02:46, 7 February 2019 (UTC)
I agree completely. The goal here is to make sure that everyone's hard work doesn't get lost and is available for future generations. --Jdfoote1 15:21, 7 February 2019 (UTC)

1737 European historical events (in Latin) [21 January 2019]

I stumbled onto what looks like a note regarding world events in 1737 on this page (lower left side). Royalty in Russia, Poland, Spain and Saxony appear to be mentioned (but not by name). Anyone care to transcribe and translate?--fbax.ca 15:42, 21 January 2019 (UTC)

BUG? sequence of search results [25 January 2019]

When selecting the "Date last modified" sequence on search page; it appears that the desired result was to present recently changed pages first (DESCENDING last modified). This is not quite happening. Have a look at these results. My most recent changes to this tree were indeed made on 5-Jun-2018. If you visit the first and last pages for that date; you can see a last modified date-stamp at the bottom of the page. The search results for pages modified on 5-Jun-2018 are presented in ASCENDING sequence of time changed. My last change to this tree was actually Person:Rinnik_Krol_(1) not Person:Albertje_Oordt_(1)! Thanks for your time. --fbax.ca 13:31, 24 January 2019 (UTC)

Not that I can do anything, but if I understand what you are saying, it is that changes made on the same date (ties based only on "date") are not in the right relative order. Can't say what was intended but this would not be surprising. First, being derived from wikipedia software, WeRelate is very text-oriented, and so if the timestamp has a text form, it probably has a date part and a time part. Software meant to compare dates probably only looks at the date part. Then, in the case of the tie, it probably uses what appears to be the natural order of WeRelate, which is first page created first, (one might assume this natural order is based on the order actually placed into the database?) --Jrich 14:00, 24 January 2019 (UTC)
Interesting speculation. The list of recent contributions shows that descending sort by complete date/time is possible. If I close browser and reopen to go back and check something after 40 edits in a single day; I need to scroll down 40 people to find the last person I made changes to. Annoying! Granted recent contributions would do the job; but that page gets very cluttered if there were multiple edits to each person or I work on multiple trees in one day. --fbax.ca 01:30, 25 January 2019 (UTC)

Related pages? [8 February 2019]

The report on this Related Pages reports lists 7 items. As far as I can tell, every person listed in the report is in Bax3 tree. Am I missing something here? --fbax.ca 23:12, 24 January 2019 (UTC)

I think you're missing that Person:Jannetje vanDijk (1) and Person:Lambert Halem (1) are not in your Bax3 tree, only Person:Jannegje vanDijk (1) and Person:Lambert vanHalem (1) are in that tree. Note the spellings. --robert.shaw 03:53, 25 January 2019 (UTC)
Thanks! Both of these persons are redirects. I fixed Person:Jannetje vanDijk (1); but it looks like both Person:Lambert Halem (1) and Person:Lambert vanHalem (1) are in Bax3 tree only. --fbax.ca 13:54, 25 January 2019 (UTC)
OK! So I finally solved this riddle! If a page exists that has been renamed (redirect) and is currently not part of *any* of your trees; then when you click the "Trees" link in left sidebar; the system will automatically place a checkmark in one your trees (I think the last one you made a change in). If this is the tree you want to the page to be in so that it is not included in the "Related Pages" report; then you will need to click "Update" even though you haven't made any changes. This is because the system made a change (by adding checkmark) and you need to save that change. Problem fixed!! --fbax.ca 03:07, 8 February 2019 (UTC)

Billion Graves [8 February 2019]

The Source:Billion_Graves page suggests using {{Bgraves3|##|code|name}} wiki template. I tried this template for Person:Maartje_Akershoek_(1); but generated link is broken!

Also: there appears to be a redundant source page Source:BillionGraves_Index? --fbax.ca 12:39, 7 February 2019 (UTC)

From the instructions for Template:Bgraves3: "Billion Graves has changed the format of their URL, and it is not known how long the old format, that this template is based on, will work. Use Bgravesmem to access the new format of URL directly. The new form of the example given below is:

{{Bgravesmem|530346|John S. Durham}} " (which produces John S. Durham). --Jrich 14:21, 7 February 2019 (UTC)

Thanks! That works. --fbax.ca 03:08, 8 February 2019 (UTC)

The Source:Billion_Graves page has been updated. --fbax.ca 03:21, 8 February 2019 (UTC)

Ontario, Canada - Vital Statistics [16 February 2019]

On WeRelate; we have very messy titles for civil registration records for Ontario!

  • Births Births, stillbirths, and delayed registration with indexes, 1869-1914
  • Marriages Registrations of marriages (RG 80-5), 1869–1932; delayed registrations (RG 80-6-1), 1892–1919; and indexes, 1869–1932
  • Deaths Ontario, Canada, Deaths and Deaths Overseas, 1869-1946

I guess these names originally came from the FamilySearch website:

  • Catalog 517518 Births, stillbirths, and delayed registration with indexes, 1869-1912
  • Catalog 530639 Marriages - registrations, 1869-1927; original index, 1869-1876; index, 1873-1927; and delayed registrations, 1892-1919
  • Catalog 515541 Deaths - registration, 1869-1937 and index, 1869-1937]]

On the [Ontario Archives] website; civil registration of births, marriages and deaths are called simply "Ontario Vital Statistics". The "RG" codes used in WeRelate title for marriages are useful when looking for microfilm copies in the archives library in Toronto. They are not useful when using other repositories.

I propose renaming the above WeRelate pages (and titles) to:

  • Ontario Vital Statistics - Births
  • Ontario Vital Statistics - Marriages
  • Ontario Vital Statistics - Deaths

Year range varies by repository and can be mentioned lower in page.

Any objections? Silence will be considered consent.--fbax.ca 19:07, 14 February 2019 (UTC)

Objection. The messy collections still exist and those are their titles. Best case: add a new source page. I'll leave it to someone who understands source titles to discuss what the new name could be, if needed, but I imagine it will start with "Ontario, Canada. <collection name>". --Jrich 19:23, 14 February 2019 (UTC)

Jrich - the messy titles were created by FamilySearch; they are a repository, not the owners of the collection. The owner is Ontario Archives and they call it "Vital Statistics". - added by fbax.ca 19:40, 14 February 2019 (UTC)
It is the title I see when I look at the records on their site. How in the world am I supposed to come up with your titles based on the information on the screen I am looking at. Unfortunately, the source system tends to think renames are errors, so it is difficult to create aliases. redirects are excluded from the drop-down list you get when you start typing the source name. You can't just make up "non-messy" names, you have to consider many things, one being what a user of a source is going to know about the source, and not know (such as there are many different repositories presenting the same images under different names).
Jrich, you said It is the title I see when I look at the records on their site. Which site are you referring to? For Births; I can find:
* Ancestry Ontario, Canada Births, 1858-1913
* FamilySearch Ontario Births, 1869-1912
Neither of these titles is the messy title used by WeRelate. --fbax.ca 18:27, 15 February 2019 (UTC)
If I access the data on family search, I see it titled the way they title it. All those other names are unknown to me. --Jrich 18:41, 15 February 2019 (UTC)
I did another search on FamilySearch. In the catalog; search for Ontario and select "Canada, Ontario". Near the bottom of long list is "Canada, Ontario - Vital records - Indexes ( 18 )". Click this link and you will see TWO entries for Ontario births, TWO entries for marriages and TWO entries for deaths. For Birth records:
* Births, stillbirths, and delayed registration with indexes, 1869-1912
Points to the list of FHL microfilm numbers
* Ontario births, 1869-1912
Points to an online index with links to scanned documents.
I expect that going forward most people will be using the online index; so perhaps a name change to WeRelate page is justified. - added by fbax.ca 19:40, 14 February 2019 (UTC)
I have little familiarity with Canadian records so don't follow your argument. Vital record indexes are different than vital records. People should cite what they use. If they use an index without verifying it is a correct representation of the underlying record, they should cite the index. Thorough genealogists will use an index to locate a record, but will actually look up, use, and then should cite the actual record. All indexes add some small number of errors no matter how carefully done, and as familysearch indexes were often built by volunteers with no special training working in an area and with families they were unfamiliar, they may not be the best in this regard. The Source:New Hampshire, United States. Index to Births, Early to 1900 was built by town clerks presumably familiar with the records of their town, yet it is still possible to find errors in their index (e.g., Person:Elisha Kimball (2)). --Jrich 21:42, 15 February 2019 (UTC)
Having looked at the birth records situation, I think I agree that WR's "Source:Ontario, Canada. Births, Stillbirths,...1869-1914" record would probably be best be renamed to "Source:Ontario, Canada. Ontario Births, 1869-1912". First, the predominant usage was/was/is FHC/FHL/FamilySearch and not via Ontario Archives (which I believe should probably have a separate source, cross-linked, because it goes to 1917 at present instead of 1912, but that's a whole other issue).
Second, FamilySearch essentially is now using "Ontario births, 1869-1912" and not "Births, Stillbirths..." pretty much everywhere. It shows up in general searches. The "...Stillbirths..." catalog entry links prominently to the "Ontario births" collection search page and lower down lists the hundreds of microfilm numbers and related image links. The "Ontario births" short catalog entry mentions its basis the "...Stillbirths..." collection. Following the online index link in either entry leads you to the same "Ontario births" collection search page. Searches using that yield results labelled as "Ontario births" and having generated citations for "Ontario births", e.g. 'Citing this Record: "Ontario Births, 1869-1912," database with images, FamilySearch https://familysearch.org/ark:/61903/1:1:FMC6-YVM : 16 July 2017), Gordon Roy Vancamp, 12 Dec 1878; citing Birth, Merrickville, Grenville, Ontario, Canada, citing Archives of Ontario, Toronto; FHL microfilm 1,845,216.' If one clicks onwards to the associated image page of the original document, it too uses "Ontario Births, 1869-1912" in its title and generated citation.
So uses of the 1869-1912 data is mostly through FamilySearch and that will almost certainly be now found under the "Ontario Births, 1869-1912" on FamilySearch, so it seemingly makes sense to use the same form on WR. I suggested the prefix "Ontario, Canada." in the Source: page because that seems to be the standard. (Dropping the second Ontario is probably inadvisable.) The rename to the new name should leave a redirect. The page text for "Ontario births" should include mention of the "...Stillbirths..." name and its association.
Note that FamilySearch actually also indexes these birth registrations in a separate index, one titled "Canada Births and Baptisms, 1661-1959". Obviously this has non-Ontario items, but it does include some, if not all of the 1869-1912 registrations, generally with links into the same original document images (but usually off by an image number or two). See Source:Canada. Canadian Births and Baptisms 1661-1959.
But wait, there's more ! It turns out there is already a page named "Source:Ontario, Canada. Ontario Births, 1869-1912" which is the title I suggested above. It is a redirect to a page Source:Ontario, Canada. Ontario Canada Births 1869-1912, which is a redirect to a page Source:Ontario, Canada. Ontario Canada Births, which is not a redirect but a minimal Source page about approximately the records I've been discussing. It hasn't been modified since November 2011. Despite having the Source page title "Ontario, Canada. Ontario Canada Births", the source title inside the box on the page is "Ontario Canada Births 1869-1913". This page has thousands of references from Person: pages, as compared to less than 250 references for Source:Ontario, Canada. Births, Stillbirths, and Delayed Registration with Indexes, 1869-1914.
I hope most everyone agrees the "Ontario, Canada. Ontario Canada Births" would better be replaced with the "Ontario, Canada. Ontario Births, 1869-1912" name. I also think the "...Stillbirths..." page should also be merged. Probably also the little referenced page Source:Ontario, Canada. Ontario Canada Births (MS329) which is a bungled reference to the same set of records, more or less. I think I might be able to be convinced that a separate page(s) might be good for the Ontario Archives films and indexes proper, since they now go beyond 1912 and will be extended starting in 2022. --robert.shaw 08:18, 16 February 2019 (UTC)
The post above does a good job of showing how broken the source system it, being unprepared for multiple collections of the same data, being clogged with existing redirects, and no help page explaining how a user is supposed to find a source if the name they see on the screen doesn't match any source page in the system.
"I hope most everyone agrees". I don't. The collection given by Source:Ontario, Canada. Births, Stillbirths, and Delayed Registration with Indexes, 1869-1914 still exists with that name here. That is the name the film number leads you to when you look the film number up in the familysearch catalog (film number usually given in image 1 if looking at a film).
The "I hope most everyone agrees" sentence has nothing to do with Source:Ontario, Canada. Births, Stillbirths, and Delayed Registration with Indexes, 1869-1914. Perhaps I should have made it its own paragraph to slow down skimming readers, but it was late and I failed to do that. --robert.shaw 20:12, 16 February 2019 (UTC)
It appears all the images in this particular film collection have been put online under a collection name "Ontario Births, 1869-1912", and that is given in the citation kindly provided by familysearch in the information tab. Of source, that citation assumes the reader will follow the link given since it does not provide identification of which book and which page the image comes out of, only of how to find it in the digital collection using the link, access to which requires a family search account. So it is not helpful to somebody accessing the collection in a different way. But most users will see the citation in the information tab and use that. (The same problem exists with familysearch citations for (U.S.) census records, which do not give you the universal page information such as enumeration district, etc., needed to locate the page in archive.org, only enough information to use familysearch's electronic resource.)
In the familysearch catalog, there is an entry for "Ontario Births, 1869-1912" which is called an electronic resource, and it references another catalog entry "Births, stillbirths, and delayed registration with indexes, 1869-1912" as being the associated film collection. Unlike this case, in general, it is not true that all images in a film collection are available in a parallel electronic resource. It appears that all the films in this film collection are fully viewable online, presumably all included in the Ontario Births electronic resource. However, there are many cases where a film collection contains some films whose images are available online, and *some that are not*, so the resulting electronic resource is not complete. Clearly for someone with access to restricted films there is a need to be able to cite them. So, *in general*, replacing film collections with electronic resource names is not a good idea.
If we use electronic resources, it would appear that we are tied to familysearch's organization and reorganization of online images. Film collections tend to be relatively stable being a physical object, and the film collection usually has enough information in the catalog to relate it to a physical record book (including images showing the title of those record books), so if perchance, somebody does have the ability to examine the actual record, you or they may be able to find enough information to locate the correct page in the correct record book, and not be limited to some link to some electronic resource arranged in some artificial collection.
So I think the old page for the film collection needs to be retained. If it is desired to add the name "Ontario Births, 1869-1912", presumably on the grounds that it is what a user sees in the familysearch-provided citation, then it should be a separate source page, just like it is a separate catalog entry in familysearch's catalog. --Jrich 16:21, 16 February 2019 (UTC)
Thanks, Jrich. Totally agree that film citations and digital image citations are both different sources, and should have different entries. This is based on my experience with trying to navigate the different collections, and communicating with people who have complained because they looked in the "indexed" collection and couldn't find a record cited by film number. --GayelKnott 16:52, 16 February 2019 (UTC)
Here FamilySearch helps a lot by providing reasonably explicit citation text (including specific, persistent URL) on the historical records they have. With this text I often just use "Citation Only" and avoid the "Source" and "MySource" options. The latter serve mainly as shorthands for showing source details and with the supplied citation text aren't needed. --robert.shaw 21:03, 16 February 2019 (UTC)
After all this all I can say is it's a good thing no one has inspected the Ontario Marriage and Death Records too carefully. First, death records were not collected until civil registration started in 1869, and very few records were made in the early years. Numbers improved around 1880, but around the turn of the century, the Registrar General's team decided to change the registration form. For the next few years all that was requested was the name of the deceased, the date of death, and the registration office. Very useless if you are chasing up a John Smith. Also, at this time, marriage information was collected over a double page with the groom's information on the left and the bride's information on the right. LDS aksed for transcriptions of each side separately and the index looks like they never got the two sides back together. Things improved around 1910. From then on the images provide all sorts of infomation, even the addresses of informants (deaths) and witnesses (marriages). --Goldenoldie 17:12, 16 February 2019 (UTC)
I know that there is a desire to avoid multiple source pages for the same set of records (what you call different repositories, though in truth all are different since they have different indexes which can make them in weird situations make using them different, etc.) However, this is exactly how the source system is broken, because it assumes everybody knows all the same information as the person picking the source name, instead of assuming they probably don't and just following a prescribed convention.
The convention is to name records that are government or church records starting with the place name. Thus the names needs to start with Ontario, Canada. --Jrich 23:53, 14 February 2019 (UTC)
Now you introduce new wrinkles! Repositories are separate from sources and indexes are different than original documents. Websites that combine indexes with original documents blur the line between indexes and documents. An original document for a BMD registration in Ontario might be found on various websites. The original document is a source; the website where you find a copy of that original document is a repository. If a website indexes those documents so that users can more easily find the original document; then that is a separate source; but I expect I'll fight an uphill battle on this point. On some websites; the "index" actually contains a transcription of many key data elements from the original document; if such a website also includes link to a scan of original document, the distinction between "index" and "original document" in even more blurry. The WR pages relating to various Ontario Vital Statistics include in the list of repositories websites that are really just indexes with no link to original source. These should not be included in a repository list since the original document is not there; but since they are helpful; I'll not push for removing them (or making a list separate from "repository") at this time. - added by fbax.ca 19:40, 14 February 2019 (UTC)
The distinction is not well-defined, a side-effect I assume of being designed when sources mostly meant a book in a library, and the distinction between source and repository was much clearer. The purpose of citing a source is to tell where the data came from so it can be confirmed (also so it can be assessed for quality as some sources are more authoritative than others). The information given to locate the source used is often different when using different "repositories". Thus for the familysearch collection Massachusetts Deaths, the location is a link to an image, but for the americanancestors.org collection showing the same images, the location information is a volume and page number. This volume-page information is not explicitly given for familysearch images, and in some cases would be some work to determine, such as when multiple volumes are filmed on a single film. And even if you had it, you wouldn't be able use it to direct familysearch to the right image very easily. Likewise knowing the film and image number in family search would not help locate the image in americanancestors.com It seems like every census repository shows the same images but the location information used to find that image is different. An article in a magazine holds an article at a certain Volume and page number, but an identical titled reprint may use its own page numbering, perhaps having the same number of pages, perhaps not, due to a different page size or new pagination needed to allow for additions since the original article came out. Not matter which "repository" a user gets their information from, they should be able to cite the source using only the information available to them. They should not need familiarity with the six other "repositories" and how they correspond. The knowledge about how they corresponds needs to be defined in the source system, somehow, instead of requiring such detailed understanding by each user when they may only use one source once for a single fact. --Jrich 18:38, 15 February 2019 (UTC)

It is important to add "Canada" after "Ontario" in this case. There is a town in California named Ontario, and Canada and California share the abbreviation "CA".

I was very new to WR when I attempted to sort out the Ontario pages 4-6 years ago. I wasn't sure how many toes I would step on. Today I would prefer to leave the task to someone more local who can check things out on the spot at Ontario Archives. Times have changed and it now can be reached by subway from the centre of Toronto, as well as by bus and car from places outside the city.

Regards --Goldenoldie 20:15, 14 February 2019 (UTC)

GoldenOldie - The collections that precede civil registration are also a mess! Most researchers distinguish between county and district marriage registrations in Ontario; but FamilySearch lumps these items and others into one big messy collection called Marriage Registers. - added by fbax.ca 20:52, 14 February 2019 (UTC)

"Forgey Descendants" Source - what do you think? [19 March 2019]

I've added a source that I've dubbed a 'source of clues', but it looks professionally done, though lacks the finality of a published work. See Source:Forgey Descendants. Thanks. --ceyockey 01:41, 19 March 2019 (UTC)

This appears to be a register report from someone with their data on Family Search. I rate these as a MySource rather than putting it in the community maintained Source file. The "Evaluation Copy" marks it as a first pass sent out to others for correction, etc. So someone's personal research and they aren't ready to distribute it yet. Many living people too.

If it were submitted as a gedcom through our process we would regard it as needing work, but that's what the site is here for. I don't like cluttering up the Source database after we spent two years trying to clean it up. (personal opinion) --Judy (jlanoux) 11:23, 19 March 2019 (UTC)

Are these Find-a-Grave sources considered candidates for cleanup? Should they point to Source:Find A Grave instead? --fbax.ca 22:21, 19 March 2019 (UTC)
Yes to both of your questions. If someone cleans up the references and adds a speedy delete template, I'll delete these source pages.--DataAnalyst 01:27, 20 March 2019 (UTC)

I see no issue with the "Forgey Descendants" Source; and do not understand why it might be considered "clutter". --fbax.ca 22:21, 19 March 2019 (UTC)

  • I see Judy's point in that, at a minimum, there is no reliable attribution to who or what organization was involved in the publication of the material. My asking arose because I did have some doubts when adding it, though I still think it could be useful as a "source of clues" to be supported by more reliable sources. I'll go ahead and migrate it to the MySource space. --ceyockey 00:15, 20 March 2019 (UTC)

I created the page MySource:Ceyockey/Forgey Descendants and marked the original page for deletion. --ceyockey 00:28, 20 March 2019 (UTC)

Template:Pedigree4 color issue with link for Person #1 [31 March 2019]

I read that creating an ancestor chart is one way to link deceased persons that are connected by a living person. I created User:Fbax.ca/Ancestors. I guess that Template:Pedigree4 was expecting me NOT to use a link for Person #1; because the color scheme makes Nathan's name unreadable. Anyone have a suggestion to fix this? --fbax.ca 14:51, 30 March 2019 (UTC)

I've added Template:Pedigree4A which uses different colors in the top box so that the readability of the linked name is better. (Feel free to improve Template:Pedigree4A.) --robert.shaw 17:37, 30 March 2019 (UTC)
Thanks! Looks good. --fbax.ca 18:24, 31 March 2019 (UTC)

Date format conventions - conflicting info [5 April 2019]

Help:Style_guide#Dates states:

  • Bet - the date is between (inclusive) the two specified dates (separated by a dash)

Help:Date_Conventions#Between/and states:

  • The qualifier pair "Bet ... and ..." may be used ...

Which is it? a dash or the word "and"; or either? --fbax.ca 19:42, 5 April 2019 (UTC)

Ahhhhh - the Help pages (sigh) ... It has long been recognized that the WR Help pages contain conflicting and out of date information. It is one of the pitfalls of the open editing environment without enough hands on deck for oversight. There have been several attempts to clean up the namespace (and even to overhaul the whole structure), but all have withered on the vine for various reasons, mostly due to lack of person power and consensus.
For example, if you look at the top of the Help:Date Conventions page, you will see the status note that reads, "Revisions as of Dec 2016 are intended to prepare this page for being included in the revised Help." I don't think that project was ever completed.
So - to specifically address your question - to the best of my knowledge - here at WeRelate, "Bet" is meant to be used in conjunction with "and", so you enter "Bet xxxx and xxxx". Hth, --cos1776 20:10, 5 April 2019 (UTC)
In this case, the answer is "and". Why? because that is what GEDCOM says. See page 47 of standard. So if somebody exports the posted date using a GEDCOM file, it will have a valid format. Most software is pretty forgiving and may work properly with either case, but since the standard says "and" that is the safe thing to use. Obviously the software may already, or easily could, make such an adjustment internally so either form could be entered, but I am guessing it doesn't, since in general it doesn't seem to do any reformatting of dates.
Help:Style Guide was inconsistent, and has been corrected. --Jrich 21:04, 5 April 2019 (UTC)

Person:George Johnston (23) [2 June 2019]

Person:George Johnston (23) appears to have two WR pages. In one he has spouse Christian Forbes (8), 14 children but no details of year and place for birth and death. In the other he is known as "George Johnston, Laird" with dates 1544-1593 and has no spouse. Both are the sons of William Johnston and Margaret Hay.

The right-hand panels of the two records list Christian Forbes as spouse and the same 14 children.

In the marriage record of George Johnston, Laird, details of year and place for birth and death are given, but these are not on the page for George Johnston, Laird.

I am pretty sure both records refer to the same man, but I do not trust myself to make a merge correctly. Could someone sort out these records, please.

NOTE: The birthplace given for George Johnston is Caskieben, Aberdeenshire, Scotland. Caskieben is an estate still in existence in the parish of Keithhill and Kinkell. I have changed the birthplace for all the children from Caskieben to Keithhill and Kinkell, retaining Caskieben in the description. It would improve the story if the father's details could match.

/cheers, --Goldenoldie 18:34, 1 June 2019 (UTC)

There is only one Person:George Johnston (23); so no merge is needed. There could be a propagation issue (bug?) here with vital information between person and family pages.

There are two marriages Family:George Johnston and Christian Forbes (1) and Family:George Johnston and Christian Johnston (1). Are you asking to merge the marriages and the wives?

Wouldn't it make sense to move this discussion to talk page for George?--fbax.ca 19:01, 1 June 2019 (UTC)

I chose to put this question in Support because I doubted anyone would see the problem if I put it on George's talk page.

Starting at the page for [[Person:George Johnston (23)]], the list on the right-hand side shows his marriage to Christian Forbes and his fourteeen children, followed by a second marriage to Christian Forbes Johnston. (My feeling is that this second marriage never existed, but we are working on person and family pages without sources, so we do not know if this is true or not.)

However, on the page for this second marriage we find the birth and death years and place (Cariegen, Aberdeenshire) for George. These facts do not appear on his Person page. Also, Christian Forbes' parents are traceable on the first marriage page, but not on the second.

Cariegen is an estate that belonged to the Johnston family until it was sold in 1662 (ref: F. H. Groome's Ordnance Gazetteer of Scotland: A Survey of Scottish Topography, Statistical, Biographical and Historical (1882-1885), published online by the Gazetteer of Scotland). The estate (still in existence) is in the parish of Keithhall and Kinkell. I am trying to replace Cariegen with the name of the parish.

I would like to merge the records for the first and second marriages and link all the information we have on this couple together, but since most of my work on WeRelate is with places rather than people, I am not sure I can work it out myself.

--Goldenoldie 10:25, 2 June 2019 (UTC)

Hi, Goldenoldie
I merged the 2 marriages. I can't explain why George's years showed up in the second marriage but not on his person page. I've seen this kind of thing before, and I assume it is the result of a bug that occurred during the gedcom upload (which might have involved a merge). At any rate, there was no source for the dates (which also show up in Find A Grave with no source), so I found a published source and used its dates instead.--DataAnalyst 14:10, 2 June 2019 (UTC)

How to enter ambiguous place? [2 June 2019]

Today, I want to enter "Jersey City" as a place; but my source does not indicate where this place is; WeRelate knows about two of them (in NJ & NV). If I enter "Jersey City"; this website changes it to "Jersey City, Hudson, New Jersey, United States|Jersey City" which is not desirable. What is the correct way to enter this; so that WeRelate does not select a misleading default? Please advise.--fbax.ca 22:44, 1 June 2019 (UTC)

Hard to believe it can't be distinguished between NJ and NV, or is there more to it? If it is Person:Neeltje Bax (3), source #2 says Hudson County, NJ. Also a death in 1941 suggests she can be found in 1940 census. If there is more to it than this, details are needed. --Jrich 01:02, 2 June 2019 (UTC)
In this case, I solved it after asking my question. In the general case; my question still remains. How do we prevent WeRelate from choosing an incorrect place? --fbax.ca 01:59, 2 June 2019 (UTC)
I would suggest entering an ambiguous name in the description field instead of the place field. There is precedent for this, usually when someone knows the name of the town and the state but not the county (and there are 2 towns with the same name in the state). In that case, I've seen the state in the place field and the name of the town in the description field.--DataAnalyst 02:54, 2 June 2019 (UTC)
Assuming a source is the cause of the ambiguity, I would quote the source in the citation so as to communicate precisely how it states the location, possibly adding a note in brackets that the description isn't specific enough to distinguish between ..., and list the choices. Usually a little directed research can help make a guess, in which case entering Jersey City, Hudson, New Jersey, United States|probably Jersey City, Hudson, New Jersey, United States or similar is commonly used. If both choices can be located in one larger place, dataanalyst's method works well, enter the containing place in the place field and put the ambiguous place name into the description. But quoting the source and describing the quandary is needed so future readers understand, and don't simply "fix" the page. --Jrich 04:46, 2 June 2019 (UTC)

I dealt with something similar recently in relation to "Doylestown, Ohio" and Family:Oscar Wotring and Charlotte Everhard (1). I edited each of Place:Doylestown, Paulding, Ohio, United States and Place:Doylestown, Wayne, Ohio, United States to cross-reference one another for disambiguation, and left the place in the family record red-linked with a note N1 referencing both potential places. --ceyockey 14:32, 2 June 2019 (UTC)

Note though (for others trying this approach) that the only reason the page is red-linked is because the town name on the Family page is spelled differently (Doylstown) than both the Place names, and thus WeRelate could not resolve it to either Place page. I believe that if you had spelled the town name Doylestown, WeRelate would have linked to one of the Place pages on saving the Family page.--DataAnalyst 15:02, 2 June 2019 (UTC)
Note, though, that the spelling "Doylstown" in the source consulted. Another editor came along and "corrected" it based on Census information, but it leaves open the question of whether the source had a typo or it was referring to an alternate spelling. Ignoring the value in the source because it is not consistent with expectation is sloppy, in my opinion. --ceyockey 20:16, 2 June 2019 (UTC)
That is why there is a box for including information and content from the source: so you can specify that the source spelled it one way or another. Clearly, the source does not make anything true, and there is an official spelling of the town's name ([3] wikipedia:Doylestown, Ohio, and oddities like this are almost certainly anacrhonisms, typos, quirks of the author, etc. And I am pretty sure the post office in the pre-zip era of 1891 (when the source was published) would have delivered mail to Doylestown if you wrote Doylstown. All various spellings and such must be amalgamated into a single entry in a place field, and using the standard WeRelate place name seems the most reasonable approach. I think a census before and after the residence date placing the family in Doylestown is pretty clear. --Jrich 21:01, 2 June 2019 (UTC)

Regarding the general case, How do we prevent WeRelate from choosing an incorrect place?: There is at least one way of preventing the WeRelate software from linking a name in a place field to a default Place: page. That is to include a target name, then the "pipe" symbol (straight line, |, shift-backslash on many keyboards), then the name to be displayed. For instance, to avoid Jersey City being mislinked, one could put this in the Place field:

   (ambiguous place) | Jersey City

This will cause "Jersey City" to show as the place for the event on the Person: or Family: page. It will be in red because it be linked to a nonexistant page "Place:(ambiguous_place)". The text you supply for the link is largely arbitrary as long as it does not match the name of a Place: page now or in the future. So one could instead type (ambiguous Jersey City) | Jersey City into the place field of the event.

If one exports an individual with such a field to a GEDCOM file, only the displayed text (e.g. Jersey City) appears in the event record of the file. If one hovers the cursor over the place name of an event on a WeRelate page, the name of the target page shows in a pop-up toolbox (e.g. Place:(ambiguous place)).

I heartily agree with above commenters that one should explain in a source or note entry for the event why the place name is not resolved to a specific place. --robert.shaw 17:59, 2 June 2019 (UTC)

HTTP ERROR 500 [2 August 2019]

On Template:CohabitationWithoutFormalities page, click "What links here" produces HTTP ERROR 500.--fbax.ca 01:58, 2 August 2019 (UTC)

I tried that and also got the error 500. I then tried several other "Assertion" templates, and some worked and some failed the same way. Template:NoAcceptedHusband worked and Template:RefutedWife failed. --robert.shaw 22:07, 2 August 2019 (UTC)

Birth of child before marriage, partner unknown. [5 August 2019]

Aletta Maria van Lent had a daughter in 1843 (partner unknown) before her marriage to Pieter Visser in 1848. On Aletta's page; this "family" appears *after* the 1848 marriage. Is there any way to change the sequence?--fbax.ca 02:08, 5 August 2019 (UTC)

Yes. Open her page in Edit mode and notice that the spouse family pages are listed in the order shown when rendered. Change the order to move the unknown husband page above the other one and Save the page. Best wishes, --cos1776 10:42, 5 August 2019 (UTC)

search server is down (again) [19 October 2019]

All searches are producing this error. This error prevents adding new person to website.

There was an error processing your search, or the search server is down; please try a different search or try again later.'--fbax.ca 17:41, 19 October 2019 (UTC)

Problems with numbering in outlines [13 November 2019]

I am having trouble with the automatic numbering using what I think is called Organized List. This used to work well but now, for example, I get A F G H I C instead of A B C D E F. Strother Family Descendants is what I'm working on now, but it seems to also happen on other pages.

I've checked and rechecked that the opens and closes are all matched. Can someone please check and see what I've done wrong.

I also welcome any help adding Strother pages to the list. Thanks. --Judy (jlanoux) 00:03, 11 November 2019 (UTC)

I see no outline letter problems on Strother Family Descendants. For example, the children of William2 Strother d. King George 1732 m. Margaret Thornton show "A" through "F". The actual letter characters are not in the HTML but instead are filled in by the browser (Chrome, Firefox, etc). So maybe there's something odd/broken with your browser. --robert.shaw 23:36, 12 November 2019 (UTC)
Thank you for the reply. I do now see that it looks perfect in Chrome. But I was using Firefox. Is this something I can fix in Firefox with options or do I file an error report with them? Thank again for the help. --Judy (jlanoux) 12:57, 13 November 2019 (UTC)
I don't know much about Firefox (I use Chrome), but I poked around and it appears a bug was introduced in Firefox version 68 and a fix is not yet in planning or implementation. Technical links: Firefox bug report and a StackOverflow Q&A. --robert.shaw 16:12, 13 November 2019 (UTC)

GEDCOM import stuck [31 December 2019]

I uploaded a not-large GEDCOM several days ago and did all the usual review stuff, matching everything up and all that. And then I clicked the "Ready to Import" button. And it said it would show up shortly, as usual. But nothing has happened since. It's now been nearly a week. I've gone back to the review screen several times, but the "Import" button is now grayed out, so I can't click it again. This is the first time I've seen this particular problem. Any ideas how to shake it loose? --MikeTalk 12:47, 29 December 2019 (UTC)--

Dallan had to restart the process. It should be fixed now. Thanks for letting us know.--DataAnalyst 03:43, 31 December 2019 (UTC)
Yep. Popped up just now. Thanks!

No Access [9 March 2020]

I have added my GEDCOM to WeRelate. I got the message it was ready for review hours ago. I cannot access it in anyway. Please help--bridamhouse 03:21, 7 March 2020 (UTC)

Hi, Bridamhouse, Have you tried clicking the link labeled "Click here to enter the review program"? What happens? What browser are you using? Some people have been having problems due to the required "Flash" software not being well supported. --robert.shaw 00:17, 9 March 2020 (UTC)

England & Wales: GRO certificate [15 March 2020]

Source:England and Wales Civil Registration. General Register Office, England and Wales This source is labeled "Finding Aid"; description includes "The General Register Office's index does not contain the full details ... The full details can only be released as a certificate". From this text; I conclude that this source does not include the actual certificates. I have purchased a GRO certificate. What is the correct source to use for such a certificate?--fbax.ca 16:35, 15 March 2020 (UTC)

WeRelate keeps timing out [6 April 2020]

For the second time this morning I have spent 5-10 minutes updating the same record only to be told on saving that WeRelate socket has timed out. Grrr.

Haven't seen any other social messages for 2-3 weeks. Is everybody well?

--Goldenoldie 10:13, 3 April 2020 (UTC)

Well and sheltering at home, thanks.

One thing you might want to try as a workaround until the problem is fixed. Make just a few changes and then save the page. The fact that I can edit this page, suggests this might work. I often save changes after a few minutes simply as a measure to avoid losing my work for whatever reason.--Jhamstra 15:38, 3 April 2020 (UTC)

That's what I've been doing. It can tie up after adding just a date. Written at the end of my computer day. Hope I can get back to work tomorrow.

/cheers --Goldenoldie 19:39, 3 April 2020 (UTC)

It appears to me to be fixed. How about you? When I would save the edits it would say it could not open a socket to the search function. Directly going to search was also not working. But I was able to follow links to pages, and enter edit mode just fine, just not complete the save. It cleared up for me about 8:30 this morning. I assume the computer running the search software was rebooted or something similar. --Jrich 23:25, 3 April 2020 (UTC)

The search server died last night (why do things always go wrong at night?). I set up a new server this morning. I'm sorry for the trouble. I'm glad everyone is safe. I hope we all stay that way.--Dallan 00:21, 4 April 2020 (UTC)

Hi Dallan,

Thanks for sorting out the computer problem. I had reverted to jigsaws to pass the time.

Currently I am actually working on genealogy rather than geography. One of our early contributors of 1000s of entries had ancestors whose history starts fairly close to where I live now. Many proceeded into London in the 1800s. He/she had a bad habit of providing dates as days and months but not years (as well as not giving sources, of course). I have chosen one of the surnames in this tree and am proceeding to add information from online databases.

BTW, has anyone else noticed what FamilySearch has done to keep up with privacy regulations? They are providing family trees, but not search facilities for individuals.

Everyone here in the UK is in complete "lockdown" in an attempt to keep covid-19 going any further than it has. We can go out to shop for groceries or medicines or for short walks or runs (if one is so inclined). Vegetables are getting scarce because they have to come in from abroad at this time of year.

I'd like to do some gardening but wonky legs and hips prevent doing that excessively and, given my age, the NHS is not keen to sort out my problems even in the best of times.

Keep well, everyone. --Goldenoldie 09:55, 4 April 2020 (UTC)

Possibly the search server is down again? "There was an error processing your search, or the search server is down; please try a different search or try again later." --Jrich 14:49, 6 April 2020 (UTC)

I'm not sure what's going on lately. I rebooted the search server this morning and that solved the problem today.--Dallan 15:18, 6 April 2020 (UTC)

Dallan, thanks for the quick response, --Jrich 17:17, 6 April 2020 (UTC)

What happened to Volume / Pages? [18 April 2020]

Pick a page, any page where "Volume / Pages" has been entered. This information no longer displays! Instead, a "new line" is output.--fbax.ca 20:53, 14 April 2020 (UTC)

User:Goldenoldie asked that a new line be put in before volume/pages. It seemed like a reasonable request. Thoughts?--Dallan 01:45, 15 April 2020 (UTC)

1) I like it the old way. 2) Read my note! Volume / Page does NOT display AT ALL now!--fbax.ca 02:37, 15 April 2020 (UTC)

Can you give me an example where it isn't getting displayed? Here's an example where it is getting displayed on a new line: Person:Test Test (16)--Dallan 02:43, 15 April 2020 (UTC)
Pick anything on this list; notice that search for "akte"; but that "akte" does not appear on person or family pages.fbax.ca 12:00, 15 April 2020 (UTC)

Not significant, but that cuts both ways, as in, why bother? What is the purpose or problem it is addressing? It takes up more screen real estate pushing thing down so less visible on screen without scrolling. and it looks less like a standard bibliography entry. --Jrich 02:51, 15 April 2020 (UTC)
I tried putting something in the date field, to see how it looked with data following the page number in the citation. When I added something to the date field, the page number disappears. --Jrich 05:23, 15 April 2020 (UTC)
I fixed the issue. I'm sorry for the disappearing volume/page numbers.--Dallan 20:44, 18 April 2020 (UTC)

search server down? [3 May 2020]

saving pages (can't open socket to search.werelate.org: 111 Connection refused) and searches time out (There was an error processing your search, or the search server is down; please try a different search or try again later.). --Jrich 04:59, 3 May 2020 (UTC)

Search seems to be working now. I also have been able to edit a page and save it. Please let us know if you still have a problem.--Judy (jlanoux) 13:32, 3 May 2020 (UTC)
was working this morning when I started. Thank you. --Jrich 15:21, 3 May 2020 (UTC)
Problem has come back! --fbax.ca 21:27, 3 May 2020 (UTC) And then fixed --fbax.ca 22:09, 3 May 2020 (UTC)

Trouble [11 May 2020]

The warning "can't open socket to search.werelate.org: 111 Connection refused" is back up again and I can't reach the Search facility either. Hope it can be fixed soon. --Goldenoldie 11:26, 9 May 2020 (UTC) still not working--Beatrijs 16:59, 9 May 2020 (UTC)

My apologies. I use WeRelate every day and usually notify Dallan when the search server is down. However, today I am packing up for a kitchen reno and just got around to notifying Dallan a minute ago. Hopefully things will be up soon (unless Dallan has to do more than just restart it).--DataAnalyst 18:55, 9 May 2020 (UTC)
It's back up and running now. Also, we now have 3 other people who can reboot the server, so hopefully things will be able to get fixed more quickly in the future.--Dallan 04:39, 11 May 2020 (UTC)

Thanks a lot. I was "back to work" yesterday. --Goldenoldie 09:26, 11 May 2020 (UTC)

Loss of Google maps for local areas [16 May 2020]

In the past week or two the map link to Google Earth seems to have disappeared for the UK. Don't know whether North American places are affected or not. Since I make a point of adding longitude and latitude settings I miss the facility to check whether I should have changed "E" to "W" or not. --Goldenoldie 12:27, 14 May 2020 (UTC)

Hi. I'm not sure what the issue is. I assume you mean Google Maps, not Google Earth. I can still get to Google Maps from WeRelate for places around the world, including the UK. I wonder if it is a licensing issue within the UK, or maybe just something on your computer.--DataAnalyst 17:30, 14 May 2020 (UTC)
I'm also seeing the maps. If you aren't seeing them, could you please right-click on the screen, select Inspect, then select the Console tab, and report to me any errors you see in the console log? That will help me understand what's going wrong.--Dallan 05:12, 15 May 2020 (UTC)
Hi. Sorry to be slow in answering. I have done something to my right arm and am keeping typing to a minimum.
The maps are the ones that link with Google Earth in the top right hand corner of a place page. Now, instead of the empty space I was seeing the other day, I get the message: "Sorry. Something went wrong." The console tab reports
<div class="fm-err-icon>...</div>
<div clas="gm-err-content">
<div class="gm-err-title">
Sorry! Something went wrong.
<div class="gm-err-message">...</div>
then a series of </div>s and the message goes on to different sections of the display.
Hope I gave you an accurate copy of the code on the console screen. It wouldn't copy and paste and it's not something I'm used to. I recall the last time I saw the "Sorry. Something went wrong." message, we discovered that Google wanted some money.
/cheers, --Goldenoldie 11:43, 16 May 2020 (UTC)

Common name? [16 May 2020]

The featured page Person:Louis_Amen_(1) includes "Lou" as the name this person commonly went by. As far as I know, there is no single English word for this "name". In Dutch, there is "roepnaam". The Help:Conventions/Given_name help page is still DRAFT and does not address this "name".

  • Are double-quotes the generally accepted convention here?
  • Should this name always appear as the last item in "Given Name" field, or is anywhere within "Given Name" acceptable?
  • fbax.ca 21:19, 15 May 2020 (UTC)
When you choose "Add Person", right on that page it says "Please use proper names without titles or 'nicknames'." If a nickname is likely to be a search criteria and is not recognized already by the software, Add Alternate Name, type Alt Name, should work. But I believe many common nicknames will work if the match option is Exact & Close Match, i.e., Sally Jones will match Sarah Jones. --Jrich 21:37, 15 May 2020 (UTC)

I’ve always thought that names like “Lou” in the example was different than “nickname”. My cousin John was often “Dutchy”. His registered birth name is “Johannes”. I think “Dutchy” is nickname; whereas “John” is not. fbax.ca 21:45, 15 May 2020 (UTC)

I agree with Jrich. With very few exceptions I use the formal name given at birth, as the primary name for a Person. If the person regularly used other names during their lifetime I show these as alternate names. If a person changed their commonly used name at or before marriage, their name on the Family page will be the name they were using when they married.

Almost 80% of my ancestry is Dutch or Frisian. These people often used multiple variants of their names even in the Netherlands (eg a Frisian variant and a Dutch variant or in earlier centuries a Latin variant), not to mention Americanized variants when they immigrated to North America. I find that the convention of birth name as primary and the other major variants as alternates works quite well. See as an example Person:Date Bijker (1) and Family:Date Byker and Johanna Van Leeuwen (1). An occasional exception would be Person:Katherine Byker (2) whose birth certificate shows her given name beginning with C but who from childhood onward always spelled her first name with a K. In this case I honored her lifelong choice. --Jhamstra 23:21, 15 May 2020 (UTC)

It's very common in various American contexts, such as newspaper stories and obituaries, to give a person's name as, e.g., John George "Buddy" Smith. This provides a combination of both formal name and the most-known name. You'll find some entries on WeRelate using that form but the WeRelate Style Guide says:

> Do not include nicknames in the primary name field; enter nicknames in the Alternate Name field.

Thus, the standard is that primary name should usually be the legal name at birth, omitting any nickname, bijnaam, roepnaam, or schimpnaam. --robert.shaw 18:39, 16 May 2020 (UTC)