WeRelate talk:Support

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

Topics


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)



BUG: Print version of Family page [16 November 2021]

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)
This has been fixed.--DataAnalyst 12:25, 16 November 2021 (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.

Hi.
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 [2]. 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? [8 September 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)


Pedigree-Map seems to be broken again? --fbax.ca 19:13, 27 July 2021 (UTC)
Was this fixed? It seems to still be broken. --fbax.ca 00:10, 8 September 2021 (UTC)


Search - sort by "Date last modified" - broken? [30 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)
Franciscus Vercammen changed at 14:40 UTC; still shows "Recent edit, not yet indexed" after 25 minutes. --fbax.ca 15:07, 20 April 2021 (UTC)

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)

Hi
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)

I made another fix (hopefully the last?) and re-started the indexer again. Please let me know if pages still aren't being indexed in a timely manner.--Dallan 15:24, 20 April 2021 (UTC)

I added a new source over 24 hours ago. [Mahler, Leslie. Uredge Families of Counties Kent and Sussex]. As of now, searching on the sources does not pick it up. An indexing issue?--jaques1724 00:27, 1 May 2021 (UTC)
I'm not sure what the issue is. Indexing is working today and I haven't had to restart it recently. Does the source show up for you as a recent change not yet indexed? If not, is there a possibility you left or closed the page without saving?--DataAnalyst 03:31, 1 May 2021 (UTC)
Source:Mahler, Leslie. Uredge Families of Counties Kent and Sussex. Seems to be working now as far as I can tell, can search for it and it shows up in drop down list. I saved it with a small change, then reverted it. If nobody else was doing anything, it may signal that the indexing simply failed earlier and resaving it just caused the indexing to be redone. --Jrich 04:28, 1 May 2021 (UTC)

Place name completion [3 May 2021]

It seems like since for the past hour or so, there has been no place name completion. In fact, the browser appears to be doing autofill.
Also when you add a person, the intermediate screen has additional fields it does not normally:
Author:
Title:
Given name:
Surname:
Place:
Birth/Chr date:
Place:
Death/Bur date:
Place:
Husband given:
Surname:
Wife given:
Surname:
Marriage date:
Place:
Place name:
Located in:
Subject:
Select
Availability:
Select
Page title:
Keywords:
--Jrich 21:26, 2 May 2021 (UTC)

I was off the site for over 2 hours and got back on a few minutes after this problem was posted. I'm not seeing either issue at this time. Please let me know if you are still having problems and I'll let Dallan know. Thanks.--DataAnalyst 21:54, 2 May 2021 (UTC)
I just signed out and signed back in. Then want to the last family I was working on and Added a Child. Typed in both parts of name, birth date, and then in birth location, typed in 3 letters and browser offered one auto fill choice based on earlier data entry. No little rotating arrow or waiting for WeRelate to populate a drop down list. When I accept location and enter Add, it displays a list of possible matches and the data entry area contains all the fields listed in the long list above. --Jrich 02:04, 3 May 2021 (UTC)

I just tried adding a child, entered the first and last names, the birth year, and the first few letters of the birth place, and I got a drop-down list, so it's either intermittent or related to the browser / operating system / etc. The next time it happens to you, would you right-click on the screen, select "Inspect", then select the "Console" tab, and if you see some red text, would you paste it here? The red text indicates an error, and your pasting it here will help me track down the error.--Dallan 04:36, 3 May 2021 (UTC)

Failed to load resource: net::ERR_BLOCKED_BY_CLIENT js:1
Failed to load resource: chrome-extension://cjpalhdlnbpafiamejdnhcphjbkeiagm/web_accessible_resources/addthis_widget.js?secret=sdbod9:1
net::ERR_FILE_NOT_FOUND
Uncaught ReferenceError: addthis is not defined wikibits.yui.30.js:1

   at HTMLDocument.<anonymous> (wikibits.yui.30.js:1)
   at n (jquery.min.js:2)
   at Object.fireWith (jquery.min.js:2)
   at Function.ready (jquery.min.js:2)
   at HTMLDocument.B (jquery.min.js:2)

Thanks. Doesn't make much sense to me. Does it look like my end or the server? --Jrich 05:28, 3 May 2021 (UTC)

working normal now. Thanks, --Jrich 14:25, 3 May 2021 (UTC)
Odd. I checked in a potential fix, but I checked it in after you said it was working normally. I'm happy it's working!--Dallan 14:55, 3 May 2021 (UTC)
I am not sure how things were impacted but it seems too coincidental to be unrelated: I apparently accidentally deleted some files, but they presumably had already been loaded by my browser so I did not notice until the next day. The above issue occurred while the fully-initiated browser was still running. The next day when I started a new browser session, it was obvious some stuff was missing and the error was no longer occurring. --Jrich 21:42, 3 May 2021 (UTC)

placelist file generated with errors [2 May 2021]

I was looking at the placelist in Iceland and noticed many links are not working. For example, the first link on page does not work; yet the page exist and can be found from the Iceland page. Probably due to unusual characters. --fbax.ca 21:38, 2 May 2021 (UTC)

I'm sure it's the character set. I've added it to my list of things to look at.--DataAnalyst 21:57, 2 May 2021 (UTC)

2nd Apache process is dead [18 May 2021]

i can access the web host name "www.werelate.org" OK, but the name "werelate.org" (lack of "www.") fails to connect when using HTTPS on port 443 (where it normally is). so i dig a bit deeper and see that there is no Elastic Load Balancer (ELB) configuration at Amazon Web Services (AWS) for port 443 in this name. it appears from the DNS settings that a single EC2 instance is intended to redirect traffic using "werelate.org" over to "www.werelate.org". testing deeper i find that the EC2 instance is up and unencrypted HTTP (port 80, normally) is working. connecting to port 443 gets the error that the connection is refused. this suggests that the redirects are running 2 separate processes and that the one for port 443 is no running. it should be trivial for whoever has the appropriate access and authority (Dallan?) to restart it. depending on how it is configured, maybe restarting the whole instance or launching a new one (if it knows how to get the static IP address attached) could work.

i found that it is necessary to register as a user here to ask a support question. what if the support issue was preventing me from registering? what if there is now someone else who is experiencing difficulty registering?--Philhoward 01:33, 18 May 2021 (UTC)

Thanks for the heads-up. When I enter "werelate.org" into chrome it automatically prepends the www even in an incognito window. But you're right - when I enter https://werelate.org into curl I get connection refused. Thank you for pointing this out. I'll fix it next week.
As for not being able to ask questions without registering, I'm not sure what to do. My personal email is on the site in several places and I do occasionally get questions by email, but it isn't prominently displayed. However, I'm not sure I want it prominently displayed. I'm open to suggestions.--Dallan 06:11, 18 May 2021 (UTC)



Videos based on Flash no longer work [18 May 2021]

the video Tour of WeRelate does not work (nothing happens) apparely because the Firefox web browser now refuses to run Flash because it is End-Of-Life at Adobe. this video should be screen captured by someone who can play it and put this up on YouTube or at least make it downloadable in webm format (it takes about 1/5 the space and bandwidth as mp4 does).--Philhoward 02:05, 18 May 2021 (UTC)

We replaced all the flash code but forgot about the videos. I removed some very-outdated flash videos and converted the helicopter tour video and uploaded it to youtube.--Dallan 06:11, 18 May 2021 (UTC)

Pages with numbers do not exist; not deleted? [27 June 2021]

How does this happen?

Family:John Davies and Mary Muir (1)
Family:Joseph Shinn and Augusta Beger (1)

Looks like several Person pages were deleted; but there is no deletion log?--fbax.ca 23:44, 27 June 2021 (UTC)

This happened in the first year or two of the site, before the delete functionality was mature. This doesn't happen any more as far as I am aware.--DataAnalyst 02:09, 28 June 2021 (UTC)

UEL help - possible duplicates [28 July 2021]

I need some help to sort this out. Starting with Person:Anne Terry (5); a family history published in 1897 tells us that the parents of Anne Terry are Parshall Terry and Rhoda Skinner. When I entered these; I got a few interesting suggestions. Some of these pages have no event details; just links to other persons. Therefore, I'm not sure these are duplicates:

This Parshall Terry is linked to wikipedia page with details that match 1897 publication, including father-in-law Timothy Skinner (presumably Rhoda's father).

Obviously a different spouse; but both FamilySearch and WikiTree show he had two wives.

Both of these WeRelate families have a son named Parshall; which could also be duplicate.

Is there agreement that there exist these duplicates in WeRelate:

.--fbax.ca 03:04, 21 July 2021 (UTC)

Yes, I would agree that those are duplicates. Someone marked the second last set above as "do not merge" back in 2009 when a lot of cleanup was done without much research. I removed the "do not merge" template, so the pages can now be merged. Please go ahead and do so if you feel comfortable doing a merge. If not, let me know and I will do it. Thanks--DataAnalyst 11:55, 21 July 2021 (UTC)
Does "merge" simply mean using #REDIRECT in one page to point to the other? --fbax.ca 12:30, 21 July 2021 (UTC)
No. You select one of the pages and then on the left hand menu, select more>Find duplicates. This searches for possible duplicates. Check the box of the possible duplicate and select the Compare button at the top of the list. From there, you are asked if pages match and then given an opportunity to say which page to keep and what specific data to keep from each page. This can be a bit intimidating the first time you do it, but it is pretty logical if you take the time to review the screens carefully. If you wish to learn how to do a merge, I would encourage reading the Help (I don't recall how up-to-date it is) and starting with one person. I might find the time to review the Help later today if you want help with learning. If you don't wish to spend the time to learn how to do this, let me know and I will do the merge. (I'll be offline for the next hour or more.)--DataAnalyst 12:52, 21 July 2021 (UTC)

Hi. I checked out the instructions for merging pages and they are up-to-date and quite good, including guidelines on what to keep and what not to keep. If you want to give merging a try, please read the Help and go ahead. Let me know, and I can review the merge. Merges can be undone as long as there aren't later edits (or minimal later edits, anyway).

If you'd rather stay away from doing your own merges, just let me know and I will do this merge. Thanks--DataAnalyst 01:22, 27 July 2021 (UTC)

I completed the merge this morning.--DataAnalyst 16:49, 28 July 2021 (UTC)

Ongoing Gedcom 'Analyzing' problem [12 August 2021]

The problem we've occasionally been seeing of imported Gedcoms getting stuck in 'Analyzing' status and never advancing to 'Uploader review' status has become rather frequent lately. Of the 10 most recent pending Gedcoms on the list, 6 are stuck at 'Analyzing'.

Since no one has complained, these particular gedcoms don't seem to matter, but sooner or later a serious user might run into the problem. Presumably it's a timing issue, which are generally hard to find, but maybe there's a easier workaround. If there's an existing periodic utility task, perhaps an additional job can be given to it to check the Gedcom list and if necessary kick off code which will do the status advancement work. --robert.shaw 02:40, 13 August 2021 (UTC)

Thanks for the note. It's very odd. The six recent gedcoms that failed all failed due to a bug that I think has been in the system for a long time. I fixed the bug and the gedcoms processed successfully. A periodic check for gedcoms under analysis is a good idea. I'll think about the easiest way to implement it.--Dallan 04:41, 13 August 2021 (UTC)

copy needed of a map [14 August 2021]

I uploaded [[Image:Wigtownshire2.png]] to WR way back in 2013 (Can't believe it was so long ago!). I want to make some minor changes, but, try as I might, I cannot find it on my computer. Is there any chance it can be sent to me? --Goldenoldie 10:31, 14 August 2021 (UTC)

Did you try "Download" link? --fbax.ca 12:45, 14 August 2021 (UTC)

Got it. Thanks. I have changed the fonts I use when drawing maps, but on seeing the old ones, I like them better.--Goldenoldie 16:11, 14 August 2021 (UTC)


Indexing halted/running slow? [7 September 2021]

I have been working on the same surname for a couple of days and every time I add a new page the list of page not yet indexed grows, some left from yesterday:

Person:Anna Child	Recent edit, not yet indexed
Person:Abigail Child	Recent edit, not yet indexed
Person:Caleb Child	Recent edit, not yet indexed
Person:Phineas Child	Recent edit, not yet indexed
Person:Betsey Child	Recent edit, not yet indexed
Person:Thomas Child	Recent edit, not yet indexed
Person:Solomon Child	Recent edit, not yet indexed
Person:Sarah Child	Recent edit, not yet indexed
Person:Rebecca Child	Recent edit, not yet indexed
Person:Polly Child	Recent edit, not yet indexed
Person:Anna Child	Recent edit, not yet indexed
Person:Abigail Child	Recent edit, not yet indexed
Person:Phineas Child	Recent edit, not yet indexed
Person:Daniel Child	Recent edit, not yet indexed
Person:Susannah Child	Recent edit, not yet indexed
Person:Phineas Child	Recent edit, not yet indexed
Person:Sophia Child	Recent edit, not yet indexed

Seems too big for just running slowly or busy system? Obviously I am wondering about the health of the indexing process? --Jrich 18:30, 6 September 2021 (UTC)

Hello ! I believe there is a problem with indexing (general counting of persons). Since yesterday morning, the counter remains at the same number : ---> 2995006 - --Markus3 07:26, 7 September 2021 (UTC)

I believe this issue started on Sept 4th. When I click "Explore" for one of my trees and sort by "Date last modified"; the titles at top of page are listed as last changed 04-Sep-2021; some of these pages were changed today and many other changes have been made to my tree every day since Sep-04. Something is DEFINITELY BROKEN!--fbax.ca 00:06, 8 September 2021 (UTC)


I brought this to Dallan's attention yesterday as I don't have the ability to do anything about it. He must be busy with something else or on vacation, as I haven't heard back.--DataAnalyst 02:04, 8 September 2021 (UTC)


Can't do a normal save. [8 September 2021]

Get the following "search server returned bad response: 502 for function: placestandardize". Server(s) need a reboot?--jaques1724 05:11, 8 September 2021 (UTC)

Just tried again, problem went away.

I had to reboot the search server in order to fix the indexing problem, so it was temporarily unavailable. Search should be working again and indexing should be working again as well. All of the pages updated during the past couple of days should be indexed now; if not, let me know and I will get them re-indexed.--Dallan 05:51, 8 September 2021 (UTC)

BUG? HTML list not rendering in source citation text [8 October 2021]

If the first character in citation text is * it is rendered as bullet.
If the first character in citation text is # it is rendered as "1.".
This behaviour seems to be documented in wikipedia LIST.
However; if any line AFTER the first one starts with these characters; then no special rendering happens. I think this is a BUG?--fbax.ca 03:17, 8 October 2021 (UTC)

I assume you are referring to the box labeled "Text/Transcription/location". This is not handled the same as the Personal History section, and many things work differently. I don't have the exact rules of how it works, but have had to use different formatting methods for this section often, and many wikipedia command don't work, like the wikipedia tables, etc. If you can do an HTML list it would probably work? Haven't tried. But in my experience, this box likes to have most HTML commands explicitly ended by their slash counterpart even when HTML doesn't care. --Jrich 06:07, 8 October 2021 (UTC)
Yes, I was referring to "Text/Transcription/location". I tried HTML list tags; including the closing </li> tag produces a blank line which I don't want. Leaving out the closing tag works fine. Thanks for suggestion. --fbax.ca 13:39, 8 October 2021 (UTC)
example on Family:Johannis de Natris and Hendrina van Mierlo (1). I assume you'll clean it up. Each list input completely in a single line.
(Just for reference, the example put the following code into the source text box to create 2 lists:
<ol><li>first item</li><li>second item</li><li>third item</li></ol>
<ul><li>one item</li><li>another</li><li>yet another</li></ul>
) --Jrich 15:14, 8 October 2021 (UTC)
Example cleaned up. It seems that if list item contains newline characters; then a blank line is added to end of item. --fbax.ca 15:27, 8 October 2021 (UTC)
I don't know how it works, I just have managed to get tables to work in that manner. I think each line is passed to the formatter separately, so it may impose some end-of-section spacing or something along those lines. I have found putting the entire command on one line gives the cleanest looking output. I use <br> when I want a newline inside my table. Dont know if this type of formatting was done on wikipedia (in which case there probably is documentation somewhere) or if it was a hack for werelate (in which case someone with access to the code may be able to write a quick help page). --Jrich 16:07, 8 October 2021 (UTC)

How to merge places? [30 October 2021]

I found https://nl.wikipedia.org/wiki/Oosterwijk_(Gelderland) in two Places here on WeRelate.

One is located in Hengelo and the other one is located in Zelhem.

Yet they are imho one and the same Place.

Since it doesn't happen often that places are to be merged, feel free to do so and let me know when it's done.

Anyone?

Thanks, Ron woepwoep 08:33, 30 October 2021 (UTC)

Merged--DataAnalyst 12:55, 30 October 2021 (UTC)
you're my angel xxx
Ron woepwoep 13:58, 30 October 2021 (UTC)

TAG for border crossings? [21 November 2021]

What event type should be used for border crossings that are neither immigration nor emigration? Border crossings at Niagara Falls are often very short visits to another country and not a permanent change of residence.--fbax.ca 13:49, 21 November 2021 (UTC)

"Other" - if you create an event at all.--DataAnalyst 14:48, 21 November 2021 (UTC)
Thanks. For today's update; the document mentioned residence; so I used that for event.--fbax.ca 14:56, 21 November 2021 (UTC)
I agree "if you create an event at all". Are they significant? Do they need to be an event? Most of the people that read a page are trying to identify if this person is the person they ==are looking for and adding all this detail to the summary makes that harder. In my opinion, such stuff could be embedded in the Personal History or a source citation. A person interested in this individual would be expected to read everything on the page and will still see it. --Jrich 15:54, 21 November 2021 (UTC)

Photo on user page [24 November 2021]

Greetings I want to add my image / photo to my user page. but I do not see this in it. Please help me / guide me Thanks / Regards--Saatyaki 09:06, 22 November 2021 (UTC)

From any page; use menu "Add" then "Image" to upload your photo. The page also explains you can use [[Image:page title.jpg]] to then add your photo to user page. --fbax.ca 21:51, 24 November 2021 (UTC)

search server returned bad response: 502 for function: placestandardize [25 November 2021]

I get this error when trying to update a profile

  • search server returned bad response: 502 for function: placestandardize(UTC)

For example; Person:Elizabeth van Meeteren (1) - Click "Edit" then "Preview" to see error. --fbax.ca 22:19, 24 November 2021 (UTC)

same here--Beatrijs 22:21, 24 November 2021 (UTC)

I think the Search Server must be down. I am finding that any Person or Place search is displaying the message
There was an error processing your search, or the search server is down; please try a different search or try again later.
--robert.shaw 22:50, 24 November 2021 (UTC)

I received the same error message when trying to add a new person or doing a search. I have emailed Dallan asking him to restart the server.

Stay tuned,

Jim:)--Delijim 23:30, 24 November 2021 (UTC)

FYI - Dallan has fixed the server, the add person and search functions are working again. Delijim 24 November 2021


FOOTER - This page was last modified [12 December 2021]

For quite some time; I have been able to scroll to bottom of a person page to see "This page was last modified" information. Today I noticed that this footer is missing. In the past, person pages presented this footer; but family pages did not. Now the family pages present this footer but not the person pages. The page on WaybackMachine confirms person pages presented footer information on 20-Oct-2021. When and why did this behaviour change? --fbax.ca 02:15, 11 December 2021 (UTC)

I see your Wayback example does have the footer for Person:Jacob Crum (3), and when I go to that Person page today, I also see the footer. Do you not see the footer on that page? --robert.shaw 04:53, 11 December 2021 (UTC)
I don’t see the footer either. The last thing is the blue stripe with the featured page category. Is it the featured page template not closing some command correctly? Is it browser specific? --Jrich 08:17, 11 December 2021 (UTC)
I use Chrome mostly, but checked with FireFox and found No footer with it on Person:Jacob Crum (3), but then I realized I was not logged on during that FireFox test. So I tried an "incognito" test on Chrome, thus not being logged on for the test, and the footer was missing, unlike logged-on Chrome.
When logged on I am not seeing ads (having a current yearly donation in effect), so I suspect it may be the ad handling going wrong. On Watercooler, Dallan mentioned earlier this month he was trying some ad program variation; maybe that's related. I looked at the page HTML, and did find that the second ad's <iframe> did not appear to have a matching </iframe>, so that may be at the root of the problem. --robert.shaw 18:58, 11 December 2021 (UTC)
Yes, that was it. I forgot to add the </iframe> when I added the myheritage ad. Thank-you Robert. It's fixed now.--Dallan 04:45, 13 December 2021 (UTC)

504 Gateway timeout error messages [15 December 2021]

I'm getting a 504 Gateway timeout error message whenever I try to access the following pages:

Person:John Womble (4) Person: John Womble (3) Family: John Womble and Catharine Greene (1)

Does a server need to be rebooted?--SusanYockey 14:38, 11 December 2021 (UTC)


I've been looking at this a bit and from what I've seen, it seems to be related to redirection inside WeRelate. Seems that there might be some server issue with resolving redirects. The site is up. Is this something that could be taken a look at? --ceyockey 19:38, 11 December 2021 (UTC)

addendum: I did take a look at the 'all pages' view --> https://www.werelate.org/w/index.php?title=Special%3AAllpages&from=John_Womble&namespace=108 ; this shows the existence of person pages for John Womble (1) through (6). (1) is a redirect to Albert Womble (2), and it's interesting that this page does not appear on the 'browse pages' view --> https://www.werelate.org/wiki/Special:Browse?scope=all&namespace=108&pagetitle=John+Wombl&go=Go ; the others, (2) through (6) appear in this view. So, it might not be a redirect disfunction afterall -- something really weird going on. --ceyockey 20:00, 11 December 2021 (UTC)


I was trying some of your pages, like Person:John Womble (4), Family:John Womble and Catharine Greene (1), and related pages, and most were getting 504's. But then I got one or two 504's just while editing this Support page reply, which makes me think that maybe the problem is not with WeRelate software but with the underlying hosting - Amazon Web Sevices (AWS). Your Womble pages may be particularly susceptible to seeing the error, perhaps because they reference many other pages like images, or perhaps for some other reason. --robert.shaw 20:20, 11 December 2021 (UTC)
Thanks, Robert. Are there any performance / fault monitoring page related domain-specific AWS resources? Most of these would be either not accessible to or completely arcane for standard users. --ceyockey 22:45, 11 December 2021 (UTC)
I don't know of any good resources for AWS monitoring. I just used this page at DownDetector for a basic assessment. --robert.shaw 05:46, 12 December 2021 (UTC)

Is there a way that I can somehow access the pages to remove the images? Or are you wanting to research it more?--SusanYockey 21:59, 11 December 2021 (UTC)

Susan, I'm not researching this. I don't think there is anything I can do to avoid the 504s to allow WeRelate to work reliably for all pages, including Womble pages. I know some about computers and software, so I can make some guesses and maybe sometimes figure out a workaround, but fixing this looks to be something that Amazon (AWS) has to do. It looks like AWS has been having problems since midweek, and apparently made things much better than it was when it first got bad on about last Wednesday, but reports seem to indicate they have a continuing lower level of failures since then. The fact that my earlier simple edit "Show preview" on this Support page itself got a 504 at one point I think shows that the AWS 504 problem is erratic and heavier pages (like some Womble pages) just have a higher likelihood of getting 504s. AWS will probably be able to make the 504s go away, but that could take 2 hours, 2 days, 2 weeks, or whatever.
I did find something of a workaround, but it's a bit of a hassle and I don't know how suitable it is. Using it I have temporarily removed the image references from Person:John Womble (4), which allows me to now view the modified Person page. I presume that (most of the time) you will be able to view it also. Basically I went directly to editing the page, edited by using "remove" button on the image lines, added text to note the temporary removal, added a edit summary to show (in history) what the edit was doing, and then saved the edited page. The tricky part is that one has to construct a URL of this form:
https://www.werelate.org/w/index.php?title=PAGECODE&action=edit
where PAGECODE is a modified form of the normal page name. To get the PAGECODE value, I did a "Copy link address" (right click menu in Chrome on Windows) of a normal clickable link to the page. This gave me a URL that looked like this:
https://www.werelate.org/wiki/Person:John_Womble_%284%29
I then selected the part of that URL that follows the "/wiki/" and pasted it into that "edit" URL form in place of the "PAGECODE" characters. This gave the text below that I could paste into my browser search/url box to go to edit the page
https://www.werelate.org/w/index.php?title=Person:John_Womble_%284%29&action=edit
A downside to doing such editing is that it leaves the edited pages is a state where they need to have the image references restored later (presumably). The more pages, the more to keep track of and then to restore. The more removed links on each page, the greater effort to restore them, if any further edits have been made to the page. If only a temporary image-link removal edit has been made to a page, then it is possible to restore the previous image-ful version without typing in all those image names. One can do this by going to History for the page, clicking on the previous version (link is date-time), then clicking on the "edit" link. The edit page that comes up warns that saving will drop later edits, but if only the image removals were done, that is exactly what is wanted, so then one simply does the "Save page".
Maybe some of this will be useful to you. --robert.shaw 23:35, 11 December 2021 (UTC)
I think I fixed the problem. The images having issues are very large - 5000x6000 pixels. The process that generates thumbnails was running out of memory and crashing, which caused the 504 errors. I gave the process more memory and that appears to have solved the problem.--Dallan 05:34, 13 December 2021 (UTC)
Susan - I've restored the images to Person:John Womble (4) and it looks like things are good now. --robert.shaw 22:28, 13 December 2021 (UTC)

@Dallan thank you for fixing the image issues on my pages. Long ago, when I added those image the file size didn't seem to be an issue. @robert.shaw thank you for your efforts in getting it where I could at least access some of the pages I was having issues with. @ceyockey thank you for you input on the issues I was having.--SusanYockey 01:10, 15 December 2021 (UTC)


death aboard a ship [13 December 2021]

hi all,

i added a person who died aboard a ship. please improve the page if possible. thx, Ron.

the page is here

woepwoep 09:59, 13 December 2021 (UTC)

I moved the description to the description field so it isn't showing as a red link.--DataAnalyst 14:14, 13 December 2021 (UTC)
See Place:At Sea. --Jrich 04:57, 14 December 2021 (UTC)

Using FindMyPast as a repository [24 December 2021]

I have found source informatation for a baptism on "FindMyPast" which is not in "Ancestry". Does WeRelate have a list of sources produced by various large online repositories? I know that I can incorporate many of the titles of Ancestry sources directly into WR, but can I do the same for those from FindMyPast? I have drafted one out, but I am hesitant to use it. (The entry is a correction of another contributor's work and if I were to use a "MySource" entry, it would go under my name which I don't want to do.) I also do not want to duplicate a source that is already in our database, but hiding when I do a search.

FindMyPast now has a great many sources for UK events and a few for other English speaking countries. We should be able to give them the credit for providing them just as we do with Ancestry. (Next month FMP will have the 1921 UK census and I don't think the Office of National Statistics has made the same arrangement with Ancestry.)

--Goldenoldie 20:05, 18 December 2021 (UTC)


I forgot I had a login for this source and recovered it. Took a look at the Ferguson surname in Parish Registers. Found an image of a page from the Bahamas Birth Index 1859-1959. On the image, I noted the copyright as FamilySearch. I tried to find the same record I was looking at on FindMyPast but on FamilySearch, and I couldn't - which probably means that the two transcriptions leading to search index indices were done independently, yielding somewhat different results -- which is interesting in and of itself.

Then I saw the that image page url is actually a wrapped familysearch.org url --> https://search.findmypast.com/record?id=https%3A%2F%2Ffamilysearch.org%2Fark%3A%2F61903%2F3%3A1%3A33S7-9RSL-NVP%3Fcc%3D1922411&parentid=R_101391350486 --> removing the wrapping and converting %-chars yields --> https://familysearch.org/ark:/61903/3:1:33S7-9RSL-NVP?cc=1922411 --> which redirects to https://www.familysearch.org/ark:/61903/3:1:33S7-9RSL-NVP?i=180&cc=1922411 <-- and that's the right image.

Granted, this is just one record from one dataset, but it suggests that, yes, you could use this as a repository, and the information sets as sources. However, it is very clear and well displayed how to cite individual records in FamilySearch; this does not seem to be the case for FindMyPast. My thinking is that it would be ideal, but overkill, to expect every person using every respository to determine whether they are looking at a record that also appears in a better cited/citable repository. I would suggest gathering as much informaiton on the data set that the record comes from as the basis for a source record in WeRelate.

Regards--ceyockey 02:08, 25 December 2021 (UTC)

P.S. I've created a source based on the investigation I did above; Source:Bahamas. Bahamas Civil Registration 1850-1959. I've also added some info to the Repository:Findmypast.co.uk page. --ceyockey 02:26, 25 December 2021 (UTC)


A question about a child born before marriage [26 December 2021]

The case is Philip Jacobs.

In the birth certificate only the mother is mentioned. The father is unknown.

On death record, the father is recorded to have acknowledged and lawfully accepted the child as his son.

So my question is: is it right to add the father to this child?

Thx Ron woepwoep 14:11, 24 December 2021 (UTC)

I have seen similar situations where birth registration does not mention father; then marriage registration mentions that groom is father of the child. I added that father to the child. See Gerardina Rutter; in this case a note was added to margin of birth registration. --fbax.ca 15:12, 24 December 2021 (UTC)

There's a couple of things that suggest a solution.

  1. on the person page, there is a codable event "adoption".
  2. when you have a person who has been married two or more times, the children are not transferred from the previous family if a parent dies.
  3. there is not a "stepchild" option when adding children to a family
  4. there is not an adoption option for a family event.

These suggest that you would create a family "Unknown and Mother's name" and associate the child with that page.

In my opinion, the structure of WeRelate suggests that "family" is more "biological parentage" than a reflection of the legal construct. By adding Marriage and Divorce events to the family, you bolster the biological with the legal, but the legal is not required for "biological parentage".

Regards --ceyockey 15:15, 24 December 2021 (UTC)


Thanks all !

I guess the death record decides who the parents are, biological or legal.

(yes it hurts)

Thx, Ron woepwoep 03:46, 26 December 2021 (UTC)


Walter Singer (1) and Johanna Carter (1) [31 December 2021]

I am in the midst of editing the marriage of this couple. The marriage record only gives the husband's name. There is a separate page for the bride's details (including the marriage) but she does not show on the family page. The couple were first entered in 2010.--Goldenoldie 12:02, 31 December 2021 (UTC)

The bride was showing on the family page, but the formatting of the first source citation (one continuous line) was pushing her information far to the right. It looks fixed now to me, but please see if you agree. You could remove many of the "blank fields" in the first citation, if you wish, as they do not provide any information. Hope that helps, --cos1776 14:02, 31 December 2021 (UTC)

Many thanks. I can now proceed to replace the original source entries with ones from manuscript images on Ancestry that I have picked up in the past couple of days.

We really ought to have some sort of warning in our instructions to the effect that the large box under a Source will take a carriage return, but the Personal Information area at the bottom does not.

Happy New Year --Goldenoldie 16:32, 31 December 2021 (UTC)


how to correct a marriage place [6 January 2022]

I accidentally imported a GEDCOM that listed a church as part of where a marriage took place. (You can see it on https://www.werelate.org/wiki/Family:Carl_Wellmeier_and_Alma_Zimmerle_%281%29). How do I remove the "Cathedral" part of the marriage place? I already added a note that the marriage took place in the Cathedral (although I'm not sure which one as I can't recall when the Catholic cathedral moved back to St. Peter in Chains), so that info won't be lost if it's removed from the place name, consistent with WeRelate standards.--Llmann 01:38, 6 January 2022 (UTC)

Edit the family page and in the place field, remove the "|" and everything after it so that is just says "Cincinnati, Hamilton, Ohio, United States". If the same description shows on other pages, you have to do it for each page uploaded.
Does that answer your question?--DataAnalyst 02:13, 6 January 2022 (UTC)

Thanks, that's what I needed to know.


place for a moved cemetery [9 January 2022]

What's the proper way to create a place for a moved cemetery? I have several people who were originally buried in St. Joseph's cemetery in Piqua, Ohio (eg. see https://www.werelate.org/wiki/Person:Maria_Zink_%281%29). As that's the way it is documented in the contemporaneous church or newspaper record, that's the way it is in my records. However, quite some years later, the entire cemetery was moved and laid out in the original arrangement in Forest Hill Cemetery in Piqua. So, if you wanted to see the tombstone (if there is one), you would go to Forest Hill. Do I somehow convert my private cemetery place for St. Joseph's into an alternate name for Forest Hill Cemetery? Or should they get separate places but with a note that St. Joseph's has moved, or what? And how would I do whatever I should do?--Llmann 01:46, 6 January 2022 (UTC)

I would say you have two separate Burial events. List them separately on the Person page. Add a Note saying the entire cemetery was moved. You can only be born once and you can only die once. But you can be buried multiple times. --Jhamstra 06:05, 6 January 2022 (UTC)
There's a remaining question of whether to retain Place pages for cemeteries that no longer exist. If the cemetery was eradicated, paved over, with no relocation of burials, then I'd definitely say to keep the old cemetery page (happens all the time with both potters fields and "forgotten" burial grounds). However, if the cemetery has been moved, then my thinking is that the old cemetery page should be merged into the new cemetery place page in a transparent manner. --ceyockey 23:19, 6 January 2022 (UTC)
@Llmann - are you sure St. Joseph Cemetery changed location? Find A Grave: Forest Hill Cemetery suggests that the location remained the same and only the ownership changed in 1904 from the Catholic church to Washington Twp and the city of Piqua as that section was annexed into what is now known collectively as Forest Hill Cemetery.
If this is accurate, I think there should be one burial event on the Person page where the Place field should link to the existing Place page for Forest Hill Union Cemetery. You could include a brief note on the Person page specifying a burial in the old St. Joseph section, but IMHO the Place page for the cemetery is the appropriate location for details about the history of the cemetery itself. The Place page that was recently created for St. Joseph's should either be unlinked and deleted (cleanest solution) or redirected to the Place page for Forest Hill Cemetery.
Please let us know if you have any questions or would like some help with any of this. Best Wishes, --cos1776 21:55, 7 January 2022 (UTC)

All the mentions of St. Joseph cemetery in Piqua implied it had been moved, but I saw at the web page for Forest Hill Cemetery a few days ago the same info you found at FindAGrave, that it was just ANNEXED to Forest Hill Cemetery, not physically moved. So, I thought it was proper genealogical standard to note place names as they existed at the time of the event being documented. In which case, the burial event should say the person was buried in St. Joseph's, but there could be a note that this cemetery is now a part of Forest Hill. The two place objects should certainly be linked together.--Llmann 14:19, 9 January 2022 (UTC)


Search Server reboot? [13 January 2022]

I think the search server needs a reboot. This [SEARCH] page of recent changes to watchlist does not include any changes made in past 24 hours.--fbax.ca 03:42, 13 January 2022 (UTC)

Yes, it needed a reboot. How are things now?--Dallan 04:52, 13 January 2022 (UTC)
Seems to have caught up on backlog and continues working. Thanks. --fbax.ca 17:53, 13 January 2022 (UTC)

BUG: Indexing server? [23 January 2022]

Person:Unknown Morin (4) is in my "Default" tree. This profile page was created 13-Dec-2021 with no subsequent modifications. When I use SEARCH page to find all persons with surname Morin in "Default" tree; there are 5 persons modified 13-Dec-2021; but this person is not listed. Why not?--fbax.ca 03:41, 23 January 2022 (UTC)

Hi. That page isn't, in fact, in your Default tree. I can tell this by exploring the tree (explore link next to the tree name on your User page). Once in exploring mode, which shows a list of tree pages on the left-hand side, I searched for (using the normal search function) and selected Person:Unknown Morin (4). Then I selected the Family Tree link (right above Facts and Events). The box for Unknown Morin says "not in tree", which means it is not in the tree I was exploring. BTW - you get out of exploring mode by selecting Exit just above the list of pages on the left.
There doesn't appear to be any problem with the indexing of this page.--DataAnalyst 12:42, 23 January 2022 (UTC)

Family without dates (and placenames) [25 March 2022]

Family:Abraham Pierson and Abigail Wheelright (1) has no dates and a placename that has been located in the wrong English county. This continues for 3 generations. Did I read somewhere that there is a campaign to remove entries like this from WeRelate?--Goldenoldie 16:18, 1 March 2022 (UTC)

Hi. I'm deleting small trees where there are no dates whatsoever, but in this case, there is a descendant with a date so this isn't in the scope of what I am addressing. Some year, I'd like to get around to updating or deleting older pages where this is no evidence - I don't know if anyone else is tackling this now.--DataAnalyst 17:17, 1 March 2022 (UTC)
I don't think it is in England, it is Newark, NJ based on comments on the page. --Jrich 20:51, 1 March 2022 (UTC)
I'll handle Place:Gelderland, Netherlands so feel free to ask before deleting. woepwoep 04:20, 25 March 2022 (UTC)

To JRich.
Thanks for noting it was New Jersey. There were about 20 entries linked to Newark, Northamptonshire, which is a hamlet now a part of the City of Peterborough. Every one but these has already been redirected to Newark in one of the following: Nottinghamshire, Ohio, New Jersey and Ontario. Such is life. --Goldenoldie 23:20, 1 March 2022 (UTC)

Almost every former British colony has several Kingstons and the older place completion algorithm would pick the shortest match to what was typed in so they got all mixed up... Okay to leave off the county in one's home system, but it doesn't translate well when loading to a global system. --Jrich 01:30, 2 March 2022 (UTC)

Editing pages [25 April 2022]

Hi ,i am going thru my gedcom, and on the warnings tab, i click on a warning, which takes me to the person/family. So far so good So, now what? Example: event occurs after death:

       How to correct the information?
        
       Wrong birthdate: no place to edit this?

I really want to correct these things, but i can see no editing option. Only adding places, etc. Help please?--LucyLuLuu 07:33, 21 April 2022 (UTC)

Hello, Lucy, If you have more than a few things to correct, it's usually best to correct your data in its original location, or in a copy using software you like to edit with. This is mainly because if you have a lot, something could happen before you get your uploaded-but-not-imported GEDCOM data imported, and then you'd have to repeat doing the fixes.
But if you have a limited number of fixes, you can edit them in: On a person or family display, you can find a small, blue "Edit" command in the upper left, just under the upper, smaller, display of the person's name (or fanily's name). If you click that, you'll get a form similar to the regular editing form for WeRelate, where you can change dates, places, names and so on. Then you will need to click the "Save page" button at the bottom of the form. Good luck, --robert.shaw 06:05, 25 April 2022 (UTC)

David Brosius [1 May 2022]

--EKBDVA 20:46, 1 May 2022 (UTC)

Person:David Brocius (1)? Rename (edit page to correct spelling, then select rename in left name menu and click on standardize page title)? --Jrich 20:54, 1 May 2022 (UTC)


Possible duplication [3 May 2022]

Anne Stafford (31) (born bef 1460-died aft 12 Apr 1501) and Anne Stafford, Baroness Neville (1) (born abt 1471-died aft 1500) are possibly the same person. Anne Stafford (31) lists her parents and siblings; Anne Stafford, Baroness Neville (1) lists her husband and children. This appears to be a simple merge, but there are no specific sources in either family and both families contain Nevilles.

Another look at the family list for Anne Stafford (31) makes me wonder if she has been duplicated as her older sister Lady Anne Stafford (10) (1446-1472) despite the fact that she married Aubrey de Vere.

Would someone with access to medieval sources like to check this out? Thanks,--Goldenoldie 11:30, 3 May 2022 (UTC)