WeRelate talk:Support

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


Who is WeRelate.org? [12 January 2021]

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)

I am happy to see frank discussion in this column about the future stability of WeRelate due to a variety of factors.  It supports my strengthening belief that I should probably change to a different website for my primary work but also maintain my tree on WeRelate as long as possible due to its outstanding format and accessibility to the general public.

To help decide which alternative wiki-tree website is best for me, I investigated those available and made the following summary.  I share them here for others who share my long-term concerns about WeRelate.

In the category of 1-tree wiki-tree websites (not personal trees), I am aware of only four.  In the order of increasing size, they are; WeRelate.org, WikiTree.com, Geni.com, and FamilySearch.org.  Three are totally free, but Geni uses a paywall for facts and features beyond basic names, dates, and places.  In fact, Geni provides better access to public users than to free-account holders, so for free-resource purposes, don't bother to register as it will only impede your progress.

My summary is below and after exploring all four websites (mostly WikiTree and Geni which are new to me), I now feel there is really only one solid alternative for me and that is WikiTree.com.  The modern software user-interface is night and day better than WeRelate and the up-front commitment to long-term security is exactly what I am looking for.

Geni is interesting due to its size, global scope, and probable 1-tree accuracy but the paywall is a show-stopper for me.  However, someday I would like to upload a well-polished gedcom when my research is farther along.  FamilySearch is, well, FamilySearch; massive and friendly, but with poor accuracy control over its 1-tree.

IN CONCLUSION: WeRelate.org (free) 3 million profiles

      • WikiTree.com (free) *** My choice for an alternative to WeRelate.

26 million profiles

Geni.com (paywall beyond basic facts) (Owned by MyHeritage, an Israeli company.) 152 million profiles

FamilySearch.org (free) 1,200 million profiles

I look forward to learning the opinions (and corrections?) from others on this topic.  And a big "thank you" to Dallan and the WeRelate community for such a wonderful product!--Donkle3 00:24, 6 January 2021 (UTC)

For me; not having separate fields for christening and burial in WikiTree is a show-stopper. Donkle3 said "FamilySearch; massive and friendly, but with poor accuracy control over its 1-tree"; please clarify; from what I see, none of the sites have any control over accuracy. fbax.ca 01:00, 6 January 2021 (UTC)

I agree to the recent posts above, except the 'poor accuracy control' in Familysearch. Maybe true for all trees when a GEDCOM is uploaded. I dislike geni.com because MyHeritage is extremely commercial (aggressively so).

I am using WR, WT and FS for 2 purposes: publishing selected items from my local database (Aldfaer) so other genealogists can use them + finding new data which means harvesting from the work of other genealogists. Have found all 3 sites usefull in this respect. FS gives me the most confidence in reliability because of the accessibility of sources (lists, scans, links). I like WR for the list of watchers in each profile and the named private tree feature.

Continuity of a site has a better chance with a large organization like FS. One site of interest for me disappeared abruptly when its owner Peter Blois died (did anyone copy it?). But anyway I enjoy working in WR as it is; no software changes needed for me. Thanks a ton Dallan!!!--diba 13:13, 6 January 2021 (UTC)

Reflection will show there is no accuracy control in online genealogy. One reason for this is simple: nobody knows the right answer. There is no absolutely correct authority to have some computer compare postings against. Even the best genealogist are merely trying to read the evidence and come up with likely interpretations. People studied for hundreds of years turn out to have two wives named Sarah that was never realized, etc., etc. All data is based on human records, subject to human error, often missing, sometimes confusing. So accuracy control ends up being in the hands of you, the posters. Post enough evidence that other people will come to the same conclusion as you.

One would like to think that once you get good data, it would remain and things would grow from there, but practice shows that even with good data posted, others merely add duplicates when their data disagrees. They are interested in easily uploading their GEDCOM to broadcast their family tree, not spending time researching somebody else's previously posted data to see if it is better than theirs (how is that possible?) Sheer numbers of posters are more likely to get good data posted, but also more bad data, and without a big effort to police data, good data will be buried among a bunch of bad data. This is why I have often posted that I think watching pages is one of the more important activities.

Some sites could mandate practices that tend to give better results, but they have to be careful not to have too big of a barrier to participation or procedures that are too restrictive lest they lose users. The more inclusive they are, the more they also let in people practicing lesser quality genealogy. This isn't unique to WeRelate, this is universal to all sites. I haven't seen any sites kicking off users, or restricting their access because of marginal posts, or even tabulating how many posts they make that need to be corrected. Hence, no real accuracy control. Every time I survey other sites besides WeRelate (not very scientifically), I find no evidence of any that are getting results any better than WeRelate. But my work is pretty focused on New England, which is blessed with good records. --Jrich 15:01, 6 January 2021 (UTC)

Jrich, Strangely enough I was mulling over this slice of the history of genealogical records in the wee hours of this morning. To my knowledge the Dutch were the first in Europe to initiate a civil registry back in the 1600s. As you well know, European churches kept the registries of christenings, weddings and burials that occurred in their respective venues. Given a single established church in any particular jurisdiction, this sufficed for public records of people (as opposed to land). After the Dutch revolution/civil war, as a political compromise they established both the Catholic and the Reformed churches with equal legal status. Hence the motivation for a civil registry not maintained by any one church but rather by the town hall. I suspect that the early New England settlers adopted this practice from their sojourn in the Netherlands. It certainly was not customary in Old England.
As long as you can stay out of Vermont and New York you are good. Before statehood Vermont was the Wild West of the East, though some towns did keep some records. New York (state) did not establish a civil registry until well into the 1800s. The formerly Dutch portions of New York kept very good church records though many church records absconded when Dutch loyalists took their records with them when they evacuated to Canada after the Battle of Saratoga.
By confining your research to New England you can avoid much of this mess. I do not have this luxury because 25% of my ancestry comes through Vermont and/or New York.
And you are absolutely right about the foibles of any sort of human record-keeping including public records. I have found the wrong people in burial records, marriages recorded twice or in the wrong place, even in the late 1800s and early 1900s. The most amusing recent incident was my daughter-in-law discovering that according to Social Security she is a man. Try dealing with that when you want to buy a house or register to vote. It took a lot of work to get that one fixed. Nevertheless, I much prefer less-than-perfect records to no records. Trust but verify. --Jhamstra 17:52, 6 January 2021 (UTC)

Reply comment regarding: For me; not having separate fields for christening and burial in WikiTree is a show-stopper. fbax.ca 01:00, 6 January 2021 (UTC)

This link from WikiTree has the fields supported by WikiTree GEDCOM conversions. The list includes Christenings and Burials so GEDCOM transfers should work OK from WeRelate to WikiTree. However, the WikiTree database does not seem to track all fact-types separately so a GEDCOM from WikiTree would not call-out itemized facts, but would rather include them in their Biography section which has all the non-key facts compiled together in a large paragraph with bold type to call-out different fact-types.

https://www.wikitree.com/wiki/Help:Skipped_Tags_in_GEDCOMs --donkle3 23:11, 9 January 2021 (UTC)

FWIW, I have a great deal of admiration for the folks at WikiTree. While FamilySearch is probably the most-used and certainly the most-funded wiki out there, I believe WikiTree is the most-monitored wiki for quality. WeRelate has high quality, but we're small, which is a huge help. As more people discover you, it's harder to maintain high quality. I believe WikiTree has done an admirable job in that regard.--Dallan 03:57, 13 January 2021 (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 [6 October 2020]

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!

Same problem, just a grey unresponsive Import button. I've wasted too much time on this. Thanks for the opportunity to find and fix errors in my data. I've deleted the GEDCOM and I'm moving on.--JohnDMoffatt 19:05, 6 October 2020 (UTC)

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 [31 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)

I'm still not sure exactly what's going on. I'll see what I can do to fix it.--Dallan 04:08, 29 May 2020 (UTC)

Hi Dallan, Things are now back to normal re the maps.

/cheers, --Goldenoldie 07:38, 29 May 2020 (UTC)

really? That's so odd. I didn't change anything.--Dallan 06:07, 31 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)

How to enter NN Gelis Bax? [1 November 2020]

The children of Family:Goyart Bax and Elisabeth Dierix (1) are named "GivenName Gelis Bax". This couple has a married daughter; but her given name is not known. I can create a page with title "Unknown Bax"; but what is entered as GivenName when page has been created?--fbax.ca 17:10, 27 June 2020 (UTC)

Help:Naming_conventions says "When the given name is not known, leave the Given name field blank." For unknown surnames I leave the surname blank, and would also use blank for given names. --robert.shaw 17:39, 27 June 2020 (UTC)
Ah. Where would "Gelis" be entered? --fbax.ca 17:47, 27 June 2020 (UTC)
Those instructions need to be elaborated on, IMHO. They lead to something like this. I don't think that is useful. You can't tell which is the given name and which is the surname and which of the two names is unknown. If you had a two part surname it would look like the name was complete.
When adding the page, it is probably better to leave the name blank because Unknown is not a special word and the search for duplicates would use the value Unknown whereas blank might give you a little more generous matching. The titling of the page seems to work correctly, adding the Unknown. But then I believe clarity suggests you should edit the page and add the Unknown to either the given name or surname because what is displayed are the name fields, not the title. --Jrich 18:49, 27 June 2020 (UTC)
I don't think the "Punch       Judy" example is very problematic. On the Family page, the given/sur status of the known names, though not evident in the shaded box presentation, is easily seen just above the box in the bolded page name, "Family:Unknown Punch and Judy Unknown (1)". It's also available from the popup shown when hovering over the name in the shaded box. When editing the page, it is evident from person name shown in the data entry box. On the Person page, rather similarly the bold "Unknown Punch (1)" shows the name nature, and when editing, the Given and Surname data entry boxes make the name nature clear.
Another place where the blank name recommendation is given is in the Help:Style guide: "If a name, date, or location is unknown, leave the field blank. Do not enter "Unknown," abbreviations or acronyms such as Unk, LNU, NMI, or special symbols such as brackets < > or [ ]." ---robert.shaw 22:14, 27 June 2020 (UTC)
We'll have to disagree. I think it is an impediment to understanding the page. The Person pages (husband, wife, and any children) require extra steps to figure it out, if one is even aware of that the displayed info could mean either of two different cases. To display simply Punch without at least a blank spacing or place holder for the unknown name is misleading. The intuitive read of that is that the Given name is Punch with surname unspecified.
The help page does not justify the requested behavior, but the only reason I can think of is because of searching for duplicates. One would like there to be some kind of placeholder for unknown that is a wildcard on searching, but there is not. So the approach I outlined gives you both benefits: the search is done with the field blank, matching any value (including Unknown), and yet the resulting display is immediately clear about what is known and unknown. --Jrich 00:18, 28 June 2020 (UTC)
fbax.ca: The nature of the "Gelis" isn't fully clear to me. Perhaps it is a nickname or "called" name, or known to be a middle name even though the first given name is not known, or is a second, separate surname, or is a part of the surname. If it is a nick or called name, personally I would choose, since the formal given name is not known, to put "Gelis" in the given name field, as it is seemingly a useful thing to have in that prominent position. I would also note elsewhere on the page the nature of that name and that the formal given name is missing. ---robert.shaw 22:14, 27 June 2020 (UTC)
Robert: In this case, "Gelis" is patronymic, variation of "Goyart". fbax.ca 14:21, 1 November 2020 (UTC)

I'd say that WeRelate doesn't have a protocol for this. I would suggest entering _____ Gelis for the first name, and letting the page name be Unknown Bax. The problem with this is that WeRelate will prompt to rename the page ("This page can be renamed" under the page name). Just ignore that. (See the example Person:Unknown Bax in the Sandbox.)

I am seriously considering changing the display when a first or last name is blank so that it displays as ______. This would resolve (I think) Jrich's Punch and Judy problem. I could also suppress the rename prompt if someone enters _____ as a name - but I'm not sure I would do that if the name was more than just _____ (e.g., _____ Gelis). Further conversation is encouraged - maybe after I get the initial change done. Sometimes having a prototype sparks new ideas.--DataAnalyst 15:29, 1 November 2020 (UTC)

I've coded (but not implemented) the first change I mentioned above. Check it out in the Sandbox: Unknown Jeffries for the main name and her father Thomas Jeffries for alternate names. Please don't ask me to customize the length of the underscores to line up with other names - I changed one piece of code that applies in several places. I could make it longer if it looks too short - the same length would apply everywhere. The family tree diagram and pedigree map both pick up this change. GEDCOM export should also show an underscore for the missing name (can't test this in the Sandbox).--DataAnalyst 19:25, 1 November 2020 (UTC)
I coded the second part of my suggestion (to treat user entry of _____ in a name as Unknown and thus not suggest the page be renamed). In the process, I discovered that WeRelate doesn't treat pages with given or surname entered as _____ correctly. It completely ignores the underscores and creates the page title without that part of the name (e.g., Person:Smith if the given name is ____ and the surname is Smith). My code change fixes that. With my change, if you enter given name = _____ and surname = Smith, the page title will become Person:Unknown Smith. If you enter given name = "_____ Gelis" and surname = Smith, the page title will also become Person:Unknown Smith.
This change will not be implemented until at least tomorrow night (North America time). If you wait for the code change, you can create the page with given name = "_____ Gelis". Let me know if you have any problems. Thanks.--DataAnalyst 21:47, 1 November 2020 (UTC)

BTW: Another thought is to enter the given name as "Unknown Gelis". Or simply leave it blank since the placement of the person in the family gives the same info as the patronymic does. A source citation can explain the evidence for her being part of the family in case someone wonders about the evidence without the patronymic.--DataAnalyst 19:25, 1 November 2020 (UTC)

Gelis is a given name of the group that includes Gail and Ghislaine. I have found it in historical novels. --Goldenoldie 12:53, 1 November 2020 (UTC)

In the case of Family:Goyart Bax and Elisabeth Dierix (1), this family is Dutch -- check with the WeRelate:Nederlandse WeRelate-groep if anyone there is still active, but my understanding is that if a Patronym is used with a family name, it is treated as a second given name (like a "middle" name in present day English American naming patterns); if it is used without a family name, it is treated as a family name. Gayel--GayelKnott 18:21, 1 November 2020 (UTC)

New Gedcom stuck in 'Analyzing' state [6 August 2020]

I've noticed that someone's GEDCOM, the one dated 06:25, 3 August 2020, has been stuck in 'Analyzing' for a couple of days now. It most likely isn't urgent since most uploads are drive-by dumps that the user never reviews and eventually get deleted. Still, it would be best to give every user a chance. Does anyone know if an admin can kick a file in that hung state back into action, and if so, how to do it? Does it instead require someone with server-level access (e.g. Dallan) to do this? Thanks. --robert.shaw 16:50, 5 August 2020 (UTC)

It takes someone with server-level access to do it. I looked into it and it appears that the GEDCOM was a PDF file. I'll communicate this to the owner. Thanks for letting me know!--Dallan 05:22, 6 August 2020 (UTC)

Multiple Gedcoms [30 September 2020]

I use Legacy as my master genealogy database. I have been thinking about loading a Gedcom to WeRelate. Over time as I add to Legacy, do I just load a new Gedcom to WeRelate? Will I have to reprocess 100% of the 2nd Gedcom or will WeRelate remember what was from the first Gedcom?

Jim--Jgs1940 17:12, 30 September 2020 (UTC)

WeRelate retains records from your previous GEDCOMs. You don't have to include all your previous records in a new GEDCOM. If you have updated info on people you uploaded before, you can include them in your new GEDCOM. WeRelate will match the updated records in your new GEDCOM to existing records in WeRelate and will require you to confirm matches and merge new data into WeRelate as appropriate. Note, though, that matching is based on couples, not individuals, so it might be necessary for you to merge some pages after the upload is complete. There are instructions for this, but you may wish to ask someone to support you through the process.--DataAnalyst 17:43, 30 September 2020 (UTC)

Excess spaces in text [1 November 2020]

WeRelate is displaying something peculiar today. After every "]]" there are two or three extra spaces. I thought it was something I had done when wrting a place description, but the fault is everywhere, even at the bottom of this page in the sentence that begins "You irrevocably agree to release your contributions...." Is it us? or something hooked up to Google or Firefox? --Goldenoldie 12:35, 1 November 2020 (UTC)

Hi. If you're referring to a link to something other than WeRelate, such as the link [[wikipedia:township|township]] in Salford, Lancashire, England, then there is supposed to be a little arrow symbol after the link to show that it is to an external website. The symbol shows up for me (Chrome). Maybe it just isn't working for you for some reason.--DataAnalyst 13:58, 1 November 2020 (UTC)

Now why didn't I notice the arrow was missing? I've just gone back to the Salford page and everything looks ok now. Obviously some hiccup in Firefox. Thanks.

Download family trees for academic research [2 November 2020]

Hi, I'm an information science student, and I want to work on GEDCOM files. I'm trying to find as many GEDCOM files as I can for my research. Is there any way to download GEDCOM files from werelate (or any other source) for my research? Of course, no personal \ specific information will be published, only statistics about the files.

Best, Omri--Omrisuissa 20:19, 1 November 2020 (UTC)

It is not clear what is being requested here. This is one large database. If you interested in genealogical content, it has millions of individuals. It may be exported in as many or few (within limits) GEDCOM files you want (use of the exported data is covered by various restrictions, see WeRelate:Terms of Use#Information for re-users), but since they are automatically generated, it will not be particularly representative of how GEDCOM is used by individuals or various software packages. If you are interested in GEDCOM as an exchange format, the standard may be easily found many places online (e.g., see here). --Jrich 21:06, 1 November 2020 (UTC)

If, on the other hand, you are only interested in doing analysis of the family trees themselves, it isn't hard to write code to pull the genealogical data from each WeRelate page. I started work on just such a thing. If you go this route I would suggest that you do so gently and slowly and cache as much information in a local database for the actual analysis (poorly written web crawlers can have a lot of impact on a site) --Trentf 18:00, 2 November 2020 (UTC)

Because WeRelate is built on MediaWiki, it's also possible to dump the entire wiki DB. You would need to talk to Dallan about that possibility. -- Jdfoote1 18:10, 2 November 2020 (UTC)

Is This Spam? [4 November 2020]

This seems like spam to me. In particular since they aren't even pretending to be a cemetery or columbarium. What does the community think?

Place:Michigan Cremation & Funeral Care, Grand Rapids, Kent, Michigan, United States

--pkeegstra 17:23, 3 November 2020 (UTC)

I agree. Do you plan to block the user?--DataAnalyst 17:41, 3 November 2020 (UTC)
Yes, definitely commercial spam. I favor blocking the user and deleting the page. --robert.shaw 22:43, 3 November 2020 (UTC)

I blocked the user and deleted the page.--DataAnalyst 15:30, 4 November 2020 (UTC)

Need coaching / have info [16 November 2020]

I have been trying to correct several mistakes on the Samuel Turner and Clara Belle Rollins sites. I have not learned exactly how to change the info. If other researchers researching the Hannibal Turner Family of Gist Settlement wants to contact me about these changes, please email me at kittykat4129@att.net--Pkwright 01:05, 17 November 2020 (UTC)

I responded to this user on his/her Talk page.--DataAnalyst 01:42, 17 November 2020 (UTC)

Adding Marriage Records [21 November 2020]

Why isn't there a event/fact category to add Marriages?--Pam41014 18:53, 21 November 2020 (UTC)

You add marriage events to the Family page, such as this page Family:Morgan Miles and Lina Plick (1). I assume this answers your question, but if you need more support, just ask.--DataAnalyst 19:24, 21 November 2020 (UTC)

no marriages in infobox summary [21 November 2020]

Did something change to cause marriages not to be shown in the infobox at the top of a Person page? --Jrich 21:11, 21 November 2020 (UTC)

Do you mean in the box that includes the male/female icon? I don't think marriage info has ever been included in that box, has it? At any rate, I haven't changed any code in over 2 weeks, and I doubt Dallan has either (besides the GEDCOM beta).--DataAnalyst 21:39, 21 November 2020 (UTC)
Oops, sorry, you're right. I am temporarily on a smaller screen and the window was so narrow the fact listing was pushed off the bottom of the visible screen so no information about marriages was visisble. My mistake. --Jrich 21:48, 21 November 2020 (UTC)

BUG: Print version of Family page [25 November 2020]

The print-version of family page where either parent has not been added is messy. The 'add person' link should be hidden? See an example here. I wonder if this can be cleaned up? fbax.ca 23:03, 22 November 2020 (UTC)

Hi. I don't know how much work that would be and I won't likely look at it for a few weeks. So don't wait for a quick solution. But if it is feasible, I'll get it fixed sometime.--DataAnalyst 00:44, 23 November 2020 (UTC)

Need reboot? [9 December 2020]

I get a lot of 504 Gateway Time-out errors.

Not every time, but more than half. I have been able to add a family of children by using the history to go back to the Add Person screen, and I have been able to use Add Spouse to add their marriages, but just clicking on the link to look at an existing page is problematical. One of the servers not working properly? --Jrich 22:10, 8 December 2020 (UTC)

I rebooted the server. If it happens again, would you please let me know, and also let me know what page you were on and what you were doing when it happened. It might be related to the type of activity that you were doing.--Dallan 04:33, 9 December 2020 (UTC)
FYI, as best I recollect, it started first thing in the morning. I refreshed my watchlist and started visiting a couple of pages that had been changed overnight, getting some of the gateway time out errors in the process, even before I did any edits. Successful fetches seems to occur in two's or three's making it think it was working and letting me do some edits, but then I'll need to try a link several times before it works. Been going on all day. Even now after the reboot, it seems slow to access Person and Family pages. However, clicking on the link for the Support page seemed to work normal. Family:James Smith and Hannah Rogers (1) was the first page, then Hannah's parents, and Hannah herself. --Jrich 06:08, 9 December 2020 (UTC)
I am on a new computer since about 2 weeks ago. Apparently, it has an ad blocker. Thought that might be why I was noticing slowness but it has been there for 2 weeks with no adverse effects. Whether I enable or disable that appears on my end to have no effect except for the display of ads, i.e., slow pages still slow. If I click on a child with no marriages (from the Parent's family page) I go to the page normally. If I click on a child with a marriage (i.e., connected to another Family page as well as the Family page I am on), then the page takes a long time. Don't know if that makes sense? --Jrich 07:00, 9 December 2020 (UTC)
Very very slow since yesterday ! and many "504 Gateway Time-out" - It's now impossible to work seriously ! - Marc Roussel - --Markus3 08:52, 9 December 2020 (UTC)
I rebooted the server again, but here's the problem I'm facing: I get almost instantaneous response times for any page that I load, the server CPU is 90% idle, and I'm seeing a steady stream of page requests that are getting fulfilled (like 10 per second). The 504 Gateway Timeout usually means that the server got an error while trying to fulfill a request and thus never gave a response to the gateway. After a minute or so the gateway gives up waiting for a response and returns 504. This suggests that there is an error happening somewhere. I haven't gotten any 504 errors myself, so I'm not sure where the error is. When was the first time you started experiencing the 504 errors? Some code changes were made 15 days ago and some more were made 2 days ago. I can back out the ones that were made 2 days ago, but if you've been seeing 504 errors for the past 2 weeks, I should back out both sets of changes.--Dallan 17:31, 9 December 2020 (UTC)
Not before yesterday morning about 6 AM PST (my start of day). Only recall one today since the first reboot, but the problem I see today is that access to Family pages is sloooowwww. Person pages can be slow, but I assume that is caused by slow access to linked-to Family pages, since as mentioned, unmarried children are accessed quickly. I have seen other slow things (like calculating diffs) but assume it follows a similar pattern since doing it on an unmarried child wasn't slow. --Jrich 18:00, 9 December 2020 (UTC)
I agree about the timing. The first time I noticed it was yesterday afternoon/evening when I went on about 4 PM EST--jaques1724 18:09, 9 December 2020 (UTC)
I just reverted the code changes from two days ago. Please let me know if this solves the 504 problems. Hopefully it does.--Dallan 18:29, 9 December 2020 (UTC)

Seems to work. Loading pages quickly now. Thank you. --Jrich 18:52, 9 December 2020 (UTC)

Concur. Thanks!!--jaques1724 20:03, 9 December 2020 (UTC)
Glad to hear it. Sorry it wasn't working. The new code had to do with additional checks around deleting pages, so I expect that the problems happened when someone else deleted a page, it caused an error or a slowdown of the entire system. That's why it was so intermittent.--Dallan 20:38, 9 December 2020 (UTC)

Adobe Flash Player required for FTE [12 December 2020]

The Family Tree Explorer requires Adobe Flash Player, however Adobe will no longer be supporting Flash Player after 31 December 2020 and Adobe will block Flash content from running in Flash Player beginning 12 January 2021, Adobe strongly recommends all users immediately uninstall Flash Player to help protect their systems.

What should I do to keep using FTE?

Regards Ken--Kenamoore 22:30, 12 December 2020 (UTC)

FTE has been replaced - I just haven't removed the links to FTE yet. Any place you see a list of your trees, select "explore" instead of "launch FTE". Please read topic "FTE replacement status - check it out" on the Watercooler for more information on how the functionality has been replaced.--DataAnalyst 22:44, 12 December 2020 (UTC)

Family to delete [22 December 2020]

Family:John Savage and Anne Washington (1) and their son and his wife are all shown in red and have been since 2007. Should they be deleted?

--Goldenoldie 12:40, 22 December 2020 (UTC)

Yes. These are leftover pages from a time when the tree delete program didn't work properly. I deleted these family pages.--DataAnalyst 14:26, 22 December 2020 (UTC)

Thanks. This completes the changes from Place: Cheshire to Place: Cheshire, England. Merry Christmas! Pat--Goldenoldie 22:43, 22 December 2020 (UTC)

Problem with search? [1 January 2021]

Just started. Search for family failed "There was an error processing your search, or the search server is down; please try a different search or try again later.". Save of Person page failed, error (502?) from placestandardize. --Jrich 22:44, 1 January 2021 (UTC)

Working now. Thanks. --Jrich 22:46, 1 January 2021 (UTC)

Error Message [4 January 2021]

--Mars 18:07, 2 January 2021 (UTC) I am getting an error message that my GEDCOM is no available for review. Fine, but it will not allow me to import a newer replacement GEDCOM nor delete the old one I thought was still waiting for review. So, I am stuck. I find the WeRelate site so complicated, and it took me forever to figure out how to ask a question. Everytime(at least 10 different ways) I clicked on support and followed instructions, I could not find anyway to enter my request for help. Please help me to get this right.

I passed this on to Dallan to resolve. I believe he will remove your old GEDCOM so you can upload a new one.
Looks like you were able to add a topic here (I assume by clicking Add topic on the left).
Happy New Year--DataAnalyst 19:07, 2 January 2021 (UTC)

Note: As a result of some checking into old GEDCOM's, all GEDCOM's uploaded prior to 18 Feb 2020 have been removed. They couldn't be accessed anyway. WeRelate policy is to remove uploaded GEDCOM's if they are not processed within 3 months, but this policy has not been enforced for a while. WeRelate reserves the right to remove unprocessed GEDCOM's after 3 months. Extensions can usually be negotiated if someone is actively working on their GEDCOM.--DataAnalyst 23:32, 2 January 2021 (UTC)

I've removed all gedcoms uploaded prior to 18 Feb 2020. Hopefully this resolves the problem. If not, please let me know.--Dallan 03:14, 5 January 2021 (UTC)

Weird display of Marriage property in a Person page [27 January 2021]

see Hermina Hallers

I think what happened was when entering husband and wife i originally had them switched and later corrected. But now i can't find a way how to repair the display.

Any suggestions welcome ... or can you fix it, please be my guest. Thanks, Ron woepwoep 07:08, 27 January 2021 (UTC)

Fixed by changing gender of husband and wife.--fbax.ca 13:37, 27 January 2021 (UTC)

excellent ! Thank you very much. woepwoep 13:59, 27 January 2021 (UTC)

Blank fields in Alt-name indicates unknown? [7 April 2021]

In November-2020, DataAnalyst made some changes to present _____ when a name field is blank; with the intention of clearly identifying unknown information. See Support:How to enter NN Gelis Bax? for announcements and feedback). With this change; I notice that Alt-name for my great-uncle Person:Martinus Bax (1) now appears as if his surname is not known; so I changed it to include his surname in Alt-name. Then woepwoep reverted my change without comment. I have typically repeated surname within alt-name even when it is the same as title because in some cases a person uses multiple surnames during their lifetime and I'd like to show which first names were used with which surname (a complete name). Did I break some guideline here? I see nothing in help files about completing fields within Alt-name.--fbax.ca 16:26, 3 February 2021 (UTC)

There is no documented guideline as far as I am aware. However, it is perfectly valid to have an alt-name that is just given name(s) or just surname. The assumption is that the missing part of the name isn't unknown, but is already presented in another name line. Thus, Frederick Smith as the main name and Fred as the alt-name means that he used the name Fred Smith. There is a good reason for doing it that way, as a person can have multiple alternate given names and multiple alternate surnames, and this way, each can be listed separately without having to list every combination.
There is always an advantage to not repeating data that is already provided. For example, if a wife is thought to be Elizabeth Smith and she used the name Lizzie, and then later it was discovered that she was actually Elizabeth Jones, there is less to correct (and less to accidentally forget to correct) if her surname isn't repeated with the alt-name Lizzie.
Having said that, there is also a case to be made for having full alt-names. For example, many immigrants used Anglicized versions of both given name and surname, and you would want to show those together (as their immigrant name).
Sad to say, WeRelate Help needs a lot of work, especially around data entry conventions. It's on my radar but probably a few years out due to working on coding changes.
For now, I would say use your best judgment. If you are simply repeating a name part already provided and someone removes it, leave it be. If you are deliberately combining variants of the given and surnames to imply that not all variants were used together (such as Anglicized versions), then continue to do so, and kindly provide your reason to anyone who removes your combination.--DataAnalyst 16:54, 3 February 2021 (UTC)
Sorry fbax.ca for creating possible confusion. Yes i have tested this with some other people to make sure nothing gets lost if one enters only half the combination of surname and given name. Please feel free to contact me directly if you have any questions and/or feel uncomfortable with my changes. Thank you, Ron woepwoep 17:25, 7 April 2021 (UTC)
I am curious as to why the Latin forms of these names were chosen as the Preferred Name (and Page Title) for members of this family? It was common practice for churches to use Latin forms of names in their record-keeping, but to me, it would be more appropriate to enter the Latinized forms of their names in the Alt Name fields as a Religious Name, if at all. Why wasn't "Martin Herman" entered as his Preferred Name or even as an Alternate Name?
Also, should Source:Werkgroep Genealogie Leende van Heemkundekring. BAX Zes Eeuwen Thuis in Leende en Leenderstrijp be a Source or a MySource? Is it available to the public? If so, how, and what sources is it based on? --cos1776 17:21, 3 February 2021 (UTC) [edited]
Although Latin forms of names are usually associated with church records; in this place/time Latin form of names are used in Civil Registration. "Martinus Herman" was originally entered as his preferred name; because that's what his wife told me when I started working on family history.
The book you ask about is available to the public in several libraries and archives in the Netherlands. I have added Repository links to two archives on the source page (sorry, should have done that sooner). The book cites original sources for older events; sources before 1650 are mostly not available online. fbax.ca 21:59, 6 February 2021 (UTC)

Registration can be a challenge [25 February 2021]

I've spent a whole hour waiting for email confirmation but, ok my bad then I just realized that my email "a.w@bk.ru" doesn't look like email address to your register form. I used to use that email for all my accounts on every single Internet site. Guys, thank you so much for such a nice project, just pay attention, please, that there are some short emails still exist and even work just fine--Rayson-R 05:32, 25 February 2021 (UTC)

Looks fine to me ! https://www.ipqualityscore.com/domain-reputation/bk.ru

Let's wait for Dallan to respond. He's our CTO. woepwoep 09:35, 25 February 2021 (UTC)

It's actually not the length of the email, it's the domain. Several years ago we had a large number of fake user registrations, even going so far as to confirm their emails so they could edit pages and inject link spam. They came from about 30 different domains (bk.ru was one of them), so I blocked the domains and returned a vague error message so the link-spammers wouldn't realize they just needed to switch to a different domain. It's been long enough now that hopefully the link-spammers have moved on, so I'll go ahead and unblock bk.ru.--Dallan 03:36, 26 February 2021 (UTC)

Why are the parents not displayed? [27 February 2021]

The parents of the husband in this marriage are in WR but not displayed here. Why is this? Thx Ron woepwoep 18:28, 27 February 2021 (UTC)

Don't know current status, but there used to be a bug where some propagated changes didn't get completed. It merely takes resaving the offending page to redo the propagation. --Jrich 18:42, 27 February 2021 (UTC)

Excellent !

Thank you so much @Jrich--woepwoep 21:45, 27 February 2021 (UTC)

long name with apostroph - too much for WR? [28 February 2021]

see child #5 here

The permalink to the online record (geldersarchief.nl) is here: https://permalink.geldersarchief.nl/616581A151724D2EB9115BB157F7A5B6

thx Ron woepwoep 22:20, 27 February 2021 (UTC)

Page "[[Person:Louis D' Hangest d''IJvoij van Mijdr (1)]]" renamed to "Person:Louis D' Hangest d'IJvoij van Mijdr (1)".
Double consecutive apostrope (three altogether) in page name (not in name field). Think it is good now? --Jrich 01:34, 28 February 2021 (UTC)

at least it is better.

i changed double apostrophe (which turns text into italic from there) to triple apostrophe (which got worse because now bold text follows) and went back to one apostrophe and no space. now it looks good.

i also changed mijdr into mijdrecht (= a city in the NL) probably because the first name field is not very long, i paste the whole name in the first name, and then i cut and past the last name into the last name field.

thanks again for your help, @Jrich ! best regards, Ron woepwoep 18:55, 28 February 2021 (UTC)

FamilySearch sources [5 March 2021]

I get the impression that many sources were copied from FamilySearch. I cannot find these sources on WeRelate:

Are they already here? Perhaps a different name was used before indexing?--fbax.ca 23:05, 4 March 2021 (UTC)

When WeRelate started, it automatically created many sources from FamilySearch and Ancestry.com, but nothing has been automated since then. I note that the first link above is a source created Sep 2020, so it wouldn't be here unless created manually. The second link is harder to get a handle on - the closest WeRelate has is Source:Parkham, Devon, England. Registers of Parkham which is not as precise a name and seems to correspond to 1 FHL film. Please feel free to create source pages for the above.--DataAnalyst 23:43, 4 March 2021 (UTC)
Like many websites, familysearch.org seems to be constantly reorganizing their material. So the name things go by there is not necessarily the name it had when WeRelate would have copied the sources from their catalog. Most of the WeRelate sources correspond to films, or groups of films. Further WeRelate itself underwent one major renaming effort of its own since. So sometimes finding a source is a bit of an art.
I think many things called collections are actually grouping of multiple sources, and as such, a less than optimal name. Usually a more precise name (hence more useful to a person trying to locate the information or understand where it comes from) may be found on the Information tab, including a link to the catalog page. For example, one page of the Devon Bishop's Transcripts selected at random for illiustration is here and the link in the information tab goes to [4]. So it actually appears to come from a source that covers one specific parish within Devon, Berry Pomeroy. Also on the information tab is the title of the volume where the record came from: Baptisms, marriages, burials, 1771-1812.
The catalog page shows this is a DGS [digital group?] 4376562. There is no film number. If there was, you could find the source page by searching sources using keyword equal to the film number (unless the source page was editing in a way that removed the film numbers). DGS's are often single items from a film, possibly allowing one item to be made public while other parts of the film remain restricted. The catalog page for the Bishop's transcript says it is not available on film only through the collection. However, by searching for sources having place of Berry Pomeroy, Devon, England, I guess the actual parish register is Source:Berry Pomeroy, Devon, England. Parish Register Transcripts, 1596-1837 and while viewing is restricted to FHCs, it is searchable, and I find the same individual I used as a test case in the Bishop's transcripts.
The year range is different from the collection because the collection year range describes the collection as a whole, but individual parishes may not cover the entire range. --Jrich 06:49, 5 March 2021 (UTC)
I realize the question of what source to use is not resolved.
I do very little in English genealogy, but believe the original parish registers are often preferred to the bishop's transcripts. But obviously various issues may make only the bishop's transcripts available. WeRelate is likely to have a source for the parish registers but not for the bishop's registers.
I don't claim to understand the architecture of WeRelate's source system. So I don't have a clear answer. There are a couple of issues that come to mind.
I believe the bishop's transcripts should be a distinct source than the parish register. They are a non-mechanical copy and could conceivably be different. Thus it seems like there could be the need to cite the two sources distinctly, say in discussing discrepancies.
I believe it is better to use the more precise name giving the parish versus the generic collection, as long as they are maintained as separate datasets from other parishes (unlike, for example, Middlesex, Mass., county records, which is a single transcript combining all the towns into one book).
Therefore, to use this source, my suggestion is to create a source for the bishop's transcripts of the parish. Source:Parkham, Devon, England. Registers of Parkham would be the regular parish registers, and something like Source:Parkham, Devon, England. Bishop's Transcripts, 1598-1840 would be the bishop's transcripts. --Jrich 14:44, 5 March 2021 (UTC)

Repeating message [22 March 2021]

This is the 13th time I have received this message in the past 24 hours

GEDCOM Export Ready [22 March 2021]

I have exported the GEDCOM. Would someone please turn off the message.

Many thanks. --Goldenoldie 14:46, 22 March 2021 (UTC)

Search errors? [25 March 2021]

Verious search functions failing. "search server returned bad response: 502 for function: placestandardize". --Jrich 03:39, 26 March 2021 (UTC)

3 or 4 errors, but now seemed to have stopped. --Jrich 03:45, 26 March 2021 (UTC)

Uses for WeRelate [29 March 2021]

I would like to use WeRelate primarily to initiate discussions about families around which there are: 1) New sources (e.g. deeds) that are hard to find. (Is we relate a good way to make those available). 2) Where there is a lot of confusion between people (for example, first cousins) with the same name, and there is a need to differentiate them.

Are these good uses of WeRelate, and what is the best way to do them?

Very Respectfully, George Moore Fairfax, VA--Geocmoore 16:21, 29 March 2021 (UTC)

I think that WeRelate is a great place for you to post your findings, and the methods for doing so are only limited by your creativity. If the amount of text and images is not too long, you could post this information directly on each Person page. Alternatively, if it is lengthy, you could create a MySource page for each record and an Article page to present the research for the records. In this case, you would add a link to the Article page on each Person page to direct readers to your findings. There are several active users that are engaged in similar projects, so I encourage you to spend some time browsing what others have done. I would browse the New England or Virginia families. In the left margin of each page is a list of Watchers who can be contacted directly via their User Talk pages if you have any questions about how they have designed their pages and workflow. Best Wishes, --cos1776 17:06, 29 March 2021 (UTC)
Hi George, I speak for myself but not officially for WeRelate. I have used the WeRelate wiki for about 10 years now. It is a very good platform for organizing and presenting the results of your research. It is also a useful platform for collaborating with others who are researching the same family lines. In other words where your research intersects with those of other active users, it supports collaboration. In some cases those who are researching intersecting families are working elsewhere online or offline. In those cases I have found email exchanges or submitting comments on their web sites to be more productive.
So my first answer is that if you find your own research intersecting with other work on WeRelate, by all means dive-in. In my case, this was true both in the Netherlands and in colonial New England. So I gained a lot of leverage by collaborating on WeRelate. To trace my main family lines (paternal grandmother) from New England through New York and Canada to Michigan, nobdy else was doing that work on WeRelate but I was able to find two others elsewhere for some very fruitful collaboration. So a lot of my lonely contributions on WeRelate came from my own digging and from collaboration elsewhere. However, once it was posted to WeRelate some distant relatives found my work here and reached out to me to exchange information.
Using WeRelate as a platform for research, as opposed to sharing research results, would be a bit more problematic. WeRelate itself is not a repository of primary information. Rather it allows and encourages you to document what are your sources. And in my opinion it is far better than any other wiki for this purpose. If you are looking for repositories of genealogical information I would start with FamilySearch,org. It is free and reasonably well indexed. The data is of varying quality, but in my experiences tends to be better than 90% accurate. For more comprehensive coverage of sources and better indexing and search facilities there is Ancestry.com. Ancestry accuracy is not necessarily better than FamilySearch. In fact to a large extent they are drawing from the same underlying data. There is also an amazing amount of historical information available in Google Books if you are willing to dig for it.
Bottom line - if someone has already published the results of their research of value to you on WeRealte, then you have a huge amount of leverage on your own work. Of course if you can bring a group of collaborators with you then WeRelate is also a great platform for sharing information.
--Jhamstra 17:23, 29 March 2021 (UTC)
George, I would like to specifically address your questions regarding old deeds and disambiguating cousins with the same names. I have dealt with both of these challenges. In both cases WeRelate is an excellent platform for publishing your results, which probably helps other people more than it helps you. Regarding old deeds, their availability varies widely from one jurisdiction to another. Two sources that proved invaluable to me are the online records of the US General Land Office, which covers the original purchasers of land in many but not all parts of the US. Not only was I able to trace the land holdings of some of my ancestors, but also i was able to identify missing family members by who shared the original title to certain parcels of land. Also, some of my ancestors who migrated from New England to upstate New York after the American Revolution, purchased land from the Holland America Land Company which was the agent for selling of a large swath of western New York in the early 1800s. You can find an amazing quantity of those records online with a careful Google search.
Regarding disambiguation of cousins, I encountered this challenge with Dutch-American settlers of the Beekman Patent in the Hudson River valley in the 1700s. There were multiple generations of multiple cousins named Abraham Losee (or variant spellings). I was able to sort this out using baptismal records that I found online. There is now a published series of volumes covering the settlers of the Beekman Patent including wills, etc. However I was able to disambiguate the Losee cousins by carefully searching for sources on Google.
In both the Losee clan (example) and the Stansell clan (example) (two examples from the New York to Michigan migration) there are several published genealogies online (including on FamilySearch and Ancestry and other web sites). However the ones I found all contained errors which I was able to correct from public land records and baptismal records, etc. FamilySearch and Ancestry will yield some but by no means all of the answers. There is no substitute for expending a lot of time digging. You will find surprises if you do.
--Jhamstra 17:53, 29 March 2021 (UTC)

George, I find WeRelate a very useful place to work out some of these problems you mention. I'm currently working on a project to document and sort out some very badly "researched" family lines in the Carolinas, where so many courthouses burned and having deed records is a blessing. From what I have seen of other peoples' work, I think a lot of contributors to WeRelate are also using it as a place to work out some of these problems.
WeRelate offers so much flexibility that every person seems to work out their own approach. As Jhamstra has said, you can add sources that you are considering without linking them to actual events, for example. You can add notes to source citations, commenting on their quality, relevance, whatever. You can add separate notes to an individual profile. You can add discussions of your research and thinking as text to a profile, or to the talk page for that profile (especially useful if you are working with other people), or you can create a separate "article" page. As your research progresses, you can edit whatever you have added in the past.
For some examples to add to what Jhamstra has already given: Phillip Rushing, John Dunn, Job Meadors (son of Lewis Meadors) Carolina Land Records (I'm a bit wordy, so you can see different approaches.) Gayel --GayelKnott 19:16, 29 March 2021 (UTC)

Thanks very much for those ideas and recommendation. I do have some deeds to publish, copies of which I obtained from the registrar of deeds as public records. But together (9 pages of deeds) clearly identify the child-heirs of one ancestor. My goal would be to have a public forum to make those more widely available.

I'll try that first, with the article pages, and then try to get to the disambiguation of confused people area. My goal there is to help other sort their trees out, or to have them tell me what sources they have that I am wrong. (Sadly, it has happened that I have been wrong. :) )--Geocmoore 19:25, 29 March 2021 (UTC)

Hi and welcome to WeRelate. I just wanted to add that when you transcribe the deeds, you should create Transcript pages (select Add > Transcript from the drop-down menu). You can structure these pages however you like, but I would suggest one page per deed if you want to reference them independently of each other and/or allow side-by-side comparison. You can insert headers on the page to distinguish between the actual transcription and any discussion you might want to add. You can insert links to other transcripts to support your discussion. Or maybe you want to put the discussion on Person pages instead. In either case, you can include links to the Transcript pages on Person and Family pages. See several examples:
Another advantage of WeRelate for documenting people who are often confused with each other is that you can explicitly add a template that prevents anyone from merging their pages. Most of the time, just a template is added, but you can supplement that with your argument for why they are different people.
If you need help with any of this, just reach out here.--DataAnalyst 21:18, 29 March 2021 (UTC)

Copyright? [29 March 2021]

Some of the material I post here, I may post elsewhere, for example on Ancestry.com

I assume WeRelate doesn't claim exclusive rights to any material posted?

Very Respectfully, George Moore--Geocmoore 19:29, 29 March 2021 (UTC)

Anything you post on WeRelate is licensed under the Creative Commons Attribution/Share-Alike license, which basically means anyone can copy it and reuse it as long as they say where they got it. For more detail, see this page. Gayel --GayelKnott 20:40, 29 March 2021 (UTC)

[29 March 2021]

Thanks much for both of those answers!

Very Helpful.

P.S. So, you don't recommend loading deed images? Or at least, not without a transcript?--Geocmoore 22:28, 29 March 2021 (UTC)

You definitely can load the images. Images are loaded into separate WeRelate pages (Image:image_name). Then when you add the link to any other WeRelate page, the image is displayed. See one of the Transcript examples I pointed out earlier, which includes images. If you edit that example transcript, you can see how it is constructed to include images.--DataAnalyst 23:36, 29 March 2021 (UTC)
You don't need to create a transcript, but if the image is difficult to read, it is nice for the next person. Or you can just put the image on the Person pages you want and transcribe just the part of the deed that you need for the information you are gathering from it (e.g., "... purchased 100 acres ... 10 Jun 1788 ... Virginia ... signed John Smith").--DataAnalyst 23:41, 29 March 2021 (UTC)
Creating a transcript also enables search engines to see the contents of the deed. When a site like ancestry, etc., shows images of deeds, sometimes the images are under copyright. You would be free to make transcripts from the image and share your transcript, but using the image of a picture somebody else took may be questionable from a copyright status. Same with gravestones. Many deeds are available online and it is simple to add a link to websites that have them. --Jrich 00:07, 30 March 2021 (UTC)

Perfect, thanks.--Geocmoore 01:52, 30 March 2021 (UTC)

Pedigree-Map broken? [13 April 2021]

When I click on "Pedigree-Map" for a person; I see a nice ancestor chart. Then click on any of the PLACES tabs (BIRTH PLACES • DEATH PLACES • ALL PLACES); I see a blank page. Then click any of the PLACES tabs for a second visit; I see "Working" seemingly forever. The "Working" continues to be displayed even when clicking other tabs (PEDIGREE • TIMELINE • THUMBNAILS • DETAILS). --fbax.ca 22:20, 11 April 2021 (UTC)

I must admit the "Pedigree Map" is a WR feature I have never discovered before, but I'm very surprised the "places" feature has never been tied into the software. Having worked almost constantly on improving the details for the English part of WR's place database since 2015, this is very disappointing.

--Goldenoldie 10:21, 12 April 2021 (UTC)

Maps are working better, but I need to upgrade the google maps api from v2 to v3. I'll try to get to that this weekend.--Dallan 05:32, 13 April 2021 (UTC)

Search - sort by "Date last modified" - broken? [18 April 2021]

I did a search for all namespaces within Tree:Fbax.ca/Arkel The last change shown for today is "Pietertje van Rijswijk (2)" changed at 16:51 UTC (about one hour ago now). I have made numerous changes in this tree since that time which should appear in the list; what's wrong here?--fbax.ca 18:02, 13 April 2021 (UTC)

The indexing of changes is not instantaneous, but may take some period of time. I don't know anything official, but I had the impression it might sometimes take on the order of an hour. --robert.shaw 18:50, 13 April 2021 (UTC)
According to "List-Contributions"; I made a change to "Willemijntje Ryswyk (1)" during the same minute as aforementioned change at 16:51 UTC. By counting "Top" entries under "List-Contributions" about 30 changes were made in the past two hours; none of which are showing up on the search page. fbax.ca 19:00, 13 April 2021 (UTC)
I did a little informal test this morning. After 2 hours the indexer had not yet made changes for a page I modified. After 2.5 hours; indexer had made the changes. --fbax.ca 15:05, 17 April 2021 (UTC)
I'm not sure what to think. The indexer runs every 5 minutes and indexes up to 1000 pages each run. There would have to be a lot of changes for it to get backed up for 2.5 hours. The indexer might have been "hung", but that requires manual intervention to fix, so that also doesn't explain the problem. I just did a quick check and it indexed a change I made under 10 minutes, so it's not consistently slow. Would you please report the next time you notice a change hasn't been indexed within 15 minutes? Hopefully I'll be able to look into it before the indexer has indexed your change so I can see what's going on.--Dallan 05:19, 18 April 2021 (UTC)
Theodora Cruijff Still shows as "Recent edit, not yet indexed" 15 min after changes made. --fbax.ca 16:02, 18 April 2021 (UTC)
And then 30 seconds later; index is complete!

Search page is very simply BROKEN!! It seems sort by "date last modified" is irrelevant to this issue. I found some interesting pages and added them to my watchlist. A search for "unwatched" items still shows these pages in search results. --fbax.ca 01:57, 14 April 2021 (UTC)

Second issue (watched) appears to be have been resolved.

Initial issue still not resolved - changes made after 16:51 13 April 2021 UTC do not appear with correct last-changed date in search results. See these Search Results for example; Page was changed 13-Apr-2021; but search results report 8-Feb-2018 --fbax.ca 18:48, 14 April 2021 (UTC)

The indexer got stuck last night but I didn't have time to restart it then. I restarted it this morning but haven't been able to monitor it due to other commitments. It looks like it might be working now - but maybe catching up on a backlog of indexing. I'll keep an eye on it for the next hour or so, and if it doesn't clear up, I'll contact Dallan.--DataAnalyst 19:32, 14 April 2021 (UTC)
The indexer is definitely working now. I can't explain why the search in your link still shows a last change date of 2018. I'll drop Dallan a note to see if he knows why and how to fix it.--DataAnalyst 22:50, 14 April 2021 (UTC)
The link I shared shows just one page; there are many with same issue. --fbax.ca 22:52, 14 April 2021 (UTC)

I'm not sure what happened. I just updated the page and it now shows the correct date, so it must have been a glitch that happened when the indexer went down. i just re-indexed the last day's worth of edits. Hopefully that fixed it. If not, the entire website is re-indexed every two months whether the pages have been recently-changed or not, so at most the pages will have the problem for a few weeks.--Dallan 03:56, 15 April 2021 (UTC)

Looks like the one day re-index has resolved issue. Thanks! --fbax.ca 12:35, 15 April 2021 (UTC)