WeRelate talk:Support

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

Topics


Who is WeRelate.org? [15 February 2019]

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

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

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

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

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


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


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


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

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

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


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


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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


A few (belated) thoughts:

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

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

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

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

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

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

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

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

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

Perennial questions / proposals [11 January 2019]

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

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


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


Events without Citation ID [25 January 2019]

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


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


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

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

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

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

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

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


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

grep event_fact * | grep -v source

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


Preservation of content via Internet Archive [7 February 2019]

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

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

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


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

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

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

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

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

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


BUG? sequence of search results [25 January 2019]

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

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

Related pages? [8 February 2019]

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

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

Billion Graves [8 February 2019]

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

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


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

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

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

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


Ontario, Canada - Vital Statistics [16 February 2019]

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

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

I guess these names originally came from the FamilySearch website:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Date format conventions - conflicting info [5 April 2019]

Help:Style_guide#Dates states:

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

Help:Date_Conventions#Between/and states:

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

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

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