WeRelate talk:Watercooler

This page is for discussing anything you want to discuss, unless it relates only to a specific page. If it does, then post your comment on the Talk page associated with that specific page or on the WeRelate Support page.

To learn about using this Watercooler page or to ask questions about using it, go to Help:Watercooler.

If you don't want to leave comments on this page, you can email them to dallan@WeRelate.org.

Are you a new user? Have a question about how to use WeRelate? Post it to WeRelate talk:Support.

Old topics have been archived: 2006 | 2007 | 2008 | 2009 | 2010 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017 | 2018 | 2019


Topics


The Disappearance of Flash [7 March 2020]

Probably everyone already knows about this, but when I fired up my browser today and went to do a GEDCOM review, I got a reminder from the browser itself that Adobe is dumping Flash in 2020. WeRelate's GEDCOM review is Flash-based, of course. Does anyone know whether Dallan has plans to convert that function to HTML5, or whatever? (I don't want to pester him with that if he's already got something under way.) I'm not a coder -- haven't been since Line-Numbered BASIC in the early '90s -- and I have no idea how big a job that might be, but we obviously need a replacement of some kind. I know he's mostly concentrating his efforts on RootsFinder these days, but still. . . . --MikeTalk 21:05, 5 September 2019 (UTC)


I need to look into this a bit for accuracy, but I do not believe Flash is going to disappear, it is simply no longer going to be supported nor updated in any way. For the longer term, yes we would need to move away from the medium, but for the near term, it's a matter of ensuring the browser has the last available version ... and the browser doesn't balk at trying to use flash as an interpreter. --ceyockey 01:41, 27 February 2020 (UTC)

If I'm correctly interpreting what Chrome says when it starts up, it's going to actually block the use of Flash at any website it loads, as being "dangerous." Firefox (which I always use by preference) is not currently allowing me to use Flash at WeRelate at all, and hasn't for some time -- which I why I'm having to use Chrome for GEDCOM review these days. --MikeTalk 15:15, 27 February 2020 (UTC)
Flash will disappear. Any website functionality using Flash will be useless. No up to date browser will run it, and precious few do now. Remember that keeping browsers up to date is absolutely vital for security. David Newton 21:22, 6 March 2020 (UTC)
Mike interpreted Chrome startup message to mean "it's going to actually block the use of Flash at any website it loads". Perhaps "blocked" is the wrong word; what will happen is all code to support Flash will be removed from Chrome in Dec-2020. Flash Roadmap - Upcoming Changes. Does Dallan have any plans to remedy this situation?fbax.ca 21:51, 6 March 2020 (UTC)
"Does Dallan have any plans to remedy this situation?"
And that's exactly what I'm trying to find out. I'm not a coder, so I don't really know what the functional substitute for Flash will be. (I keep hearing it can be replaced by HTML, but I don't really know.) Whatever it might be, it's obviously going to have to be done in the next few months, to allow time for testing and all that. I know Dallan has sold RootsFinder and is working as the new owner's support person, but I'm hoping that doesn't cause him to put WR at the bottom of his To-Do list. --MikeTalk 13:08, 7 March 2020 (UTC)

Source quality [26 February 2020]

I keep on finding "MySource" reference which appear as follows:

  • FreeBMD, mmm yyyy [Place] 4 145, Primary quality.
  • International Genealogical Index (2), [file number], Primary quality.

The words "primary quality" are not written by the User, nor are they found in the Source Reference. They must be in a hidden template.

I have always understood that neither FreeBMD nor the IGI could be considered references of primary quality as they are copies and condensations of facts found in earlier sources. Why do we use this description?

Regards, --Goldenoldie 19:52, 21 February 2020 (UTC)

I believe Dallan removed source quality, largely because of such misuse and lack of agreement over source quality. When a page is edited that has an old source citation where the source quality field was set, saving the page will automatically remove the source quality setting from regular Source citations. Assume this happens with MySources too, but don't recall actually testing it. So, if not, and assuming it's not coming from the MySource page itself which could be edited, i.e., it turns out to be the worse case: it was input as part of the MySource citation but now hidden from you by Dallan's change, the best thing would probably be to delete the MySource reference and either replace it with an appropriate Source equivalent, or simply recreate a duplicate MySource citation, which being new won't contain the source quality. An link to an example would have enabled a more thorough answer. --Jrich 21:32, 21 February 2020 (UTC)

Hi

Thanks for your reply. I shall try replacing the offending source—unless someone has found it and done the work. I have been sorting out 20-30 more entries donated by one of the offending users this morning and “Primary Source” hasn’t come up. If it’s been fixed, thank you.

I purposely took all possible clues out of my example so that I didn’t offend any less knowledgeable users. Your explanation fits in time with the entries I am working with: a user who submitted most of his 10,000+ entries from a gedcom in 2007 and ran. Until this week I thought he was long gone, but then I received a message of the “are you related?” variety from a relative of the original user.

The WeRelate website has been having transmission problems in the past 24 hours. Here in the UK we are experiencing very strong winds and at the same time Google is warning us that it has improved its security features. This results in a very long saving time followed by a security warning notice, and a shutdown. Frustration. I shall continue to watch for “Primary Souce” and report it in full if it comes up.

--Goldenoldie 12:08, 22 February 2020 (UTC)

There's no need to replace the source. What is needed is to do an "Edit" and "Save" of the Person page. (Even a null, do nothing, edit will work.) The pages I found with the "Primary quality" citation text were all old (2007, a few with "Propagate" edits since then). Apparently the WeRelate software has changed since then, and the simple Save of the Person page will remove the "Primary quality" text. (It may also do a few other things, such as combine duplicate citations on the page.)
So it seems you can basically just do any edit to such a person page to get rid of the problem. (It'd be nice to have a bot do all those saves, but...). --robert.shaw 19:40, 26 February 2020 (UTC)

Computer cloud trouble [20 March 2020]

This morning (UK time) I keep getting the message:

"can't open socket to search.werelate.org: 111 Connection refused"

Can someone have a look, please.

--Goldenoldie 07:31, 20 March 2020 (UTC)


Disappearing census references [17 April 2020]

Hello - something seems to have happened to the seven England & Wales Census source pages. When citing these sources on person pages there's a "Volume / Pages" field, which I have always filled in with the correct class / piece / folio / page references as part of showing my workings and enabling others to easily find the same information I have relied upon. However, as of a couple of days ago, whatever information has been included in this "Volume / Pages" field is no longer displaying on any Person pages. The information is still there if you go to edit the affected pages, but for some reason isn't displaying on the finished version. This change is not just affecting new edits - all old pages which reference those English & Wales Census source pages are no longer displaying the references. By way of an example, this page: Person:William Edwards (178) references all the English & Wales Census source pages except 1841 - the information from the volume / pages field used to display between The National Archives' address and the date. I'm aware that there have been edits recently to these source pages to update the address of The National Archives, but I can't see what within those changes would have caused the volume / pages to no longer display. I assume (and hope) this is just a glitch - would anyone be able to work out how to get the references displaying again please? These sources are amongst the most frequently cited for English and Welsh people. Many thanks. Richard.--RichardK 06:06, 17 April 2020 (UTC)

There are postings about this problem over on WeRelate talk:Support, at the end. No resolution so far. You might want to copy your post into the section over there so the information is gathered together. --robert.shaw 06:26, 17 April 2020 (UTC)

The missing Volume/Pages field problem that you describe is caused by the same glitch pointed out on the "Support" page (What happened to Volume / Pages? [15 April 2020]) two days ago. I see that you date your census source entries. If you leave the date blank, the Volume/Page data will appear. Mary Oxlade (26) was entered this morning before I picked up your message. Since I never fill in the date field, her Volume/Page data follows over to the finished page.

Dallan and I have been discussing the whole revise of the England and Wales census source pages. The basic aim was to reduce the wordage in the title that appears on a Person page so that the year of the census under discussion would be visible at a glance. The reference to the PRO has now been removed, but there seems to be a problem in how the following fields in the Edit screen of the Person page are joined with the details in the Source page (some of which do not show on the Source page, even on Edit) to make up a decent citation on the completed Person page.

I pointed out the note on the Support page to Dallan 36 hours ago. Time zones can get in the way of changes being made; I think his time zone is close to being 12 hours behind ours in the UK. Perhaps we will get more information tonight. --Goldenoldie 10:04, 17 April 2020 (UTC)


How long have we got? [9 September 2020]

A few years ago I moved my entire family tree to WeRelate, plus a few more trees relating to one-name studies on the surnames Turvey and Tulloch. Whilst I haven't used them for a while (I mostly use WikiTree now), I haven't moved all of them to another site.

I can see growth on WeRelate ground to a halt a long time ago and activity is slowing down and down. There appear to be more and more technical problems and there haven't been any significant technical support for years. Eventually, I would imagine, the income won't be enough to cover the bills and this site will sadly go the way of Rootsweb or worldconnect.

My question is does anyone know how long we have got? Will we get much notice so we can download the information we need? AndrewRT 22:15, 17 April 2020 (UTC)

Most people who want to use a wiki-based website have chosen to use wikitree or familysearch, but a few people prefer werelate, and the ad revenues and donations cover the hosting costs, so there is no reason to take it down. The flash software used for the family tree explorer and the gedcom uploader will stop being supported soon, so unless someone rewrites those components, those components will stop working when flash stops being supported, but the rest of the site will continue. If anyone is interested in helping with technical support for WeRelate, I'd love to talk with you.
Maybe. What are the needs? --jrm03063 04:18, 19 April 2020 (UTC)
see below :-) Another thing that's needed is someone else who's willing to reboot the search server or the GEDCOM importer when they need it.--Dallan 04:26, 21 April 2020 (UTC)
hi Dallan, i am a Unix admin since midst 1980s (BSD 4.2 on Digital Vax/750). Also i am a database guy since 1989 when i worked for Unify Corp in Sacramento. These days i use Ubuntu on my laptop and Debian on my servers. I know about Apache2 and live in the Netherlands which is a different TZ from yours i believe. Let me know if and how i can help rebooting the server in case you need an extra pair of hands in this part of the world. Thanks Ron woepwoep 00:16, 22 April 2020 (UTC)
That's cool! I'm sorry to report that I'm at least that old... But I'm much more of a developer. Not incompetent on the IT side - but I know enough about things IT to appreciate that I'm more of an amateur there. Maybe I can back you up? --jrm03063 00:28, 22 April 2020 (UTC)
Thank you! i will reach out to you both over the weekend.--Dallan 05:39, 24 April 2020 (UTC)
I too am an ancient Unix admin from the mid-80s. I think I could also handle reboot needs with instructions. --Judy (jlanoux) 13:05, 24 April 2020 (UTC)
In addition to WeRelate I've developed GenGophers.com and RootsFinder.com. I still run GenGophers but RootsFinder was acquired by findmypast last year. i'm now working with a few others to develop free open-source software for genealogy societies that allows their volunteers to upload genealogy records and images and make the records searchable. I'd be interested in working with others on this project as well. If your society wants to be a beta-user for this software, please also let me know.--Dallan 20:41, 18 April 2020 (UTC)
Posting a link to the project would be a good way to get both volunteers and beta testers. --Tfmorris 20:49, 18 April 2020 (UTC)
That's a good idea. We should have our initial mockups next week. i'll post a link then.--Dallan 21:13, 18 April 2020 (UTC)
Thanks Dallan - that's useful to know. There's no transparency (as far as I can see) on the finances so it's hard to understand whether this is a problem or not - good to hear that it's still covered and long may that continue! AndrewRT 21:33, 18 April 2020 (UTC)

"unless someone rewrites those components, those components will stop working when flash stops being supported"

Dallan, this is not what any of us want to hear. All of the regulars on WR chip in with volunteer work of one sort or another, but I'm pretty sure that recoding the GEDCOM upload function to replace flash is beyond any of our abilities.

I keep track of what I do here, and in the 15 years I've been active on WeRelate, I've created more than 30,000 Person & Family pages from scratch, and added very substantial info to another 6,000+ existing pages. Virtually all of that was done via GEDCOM uploads. I clean up each and every page I create. But if I had to do each page entirely "by hand" -- typing stuff into the text box, waiting for it to save, copying each of the sources, saving the details for them, then doing the same thing for each of the children in a large family, and for all their spouses -- I promise you, I would have given up long ago. We all tweak pages by hand, adding images and new bits of info and making corrections, but GEDCOM is what all of us here depend on for the heavy work.

If there is no replacement for GEDCOM-by-flash by Christmas, then I predict that this site will be almost totally abandoned by this time next year. I know you have the skills for this, inasmuch as you created the site in the first place. Can you not find the time? I'm told HTML is the preferred replacement method; would it be that complex? If necessary, I think I personally would be willing to contribute to a fund to hire someone to do it for us.

Yes, WeRelate has pretty much become a "niche" genealogy site -- but I like it here. WR lets me do what I want to do and all my research is posted here. And since it's all available to anyone who Googles it, that's all I need. I imagine most others feel the same way. There are simply no other really good replacements for WeRelate -- and I've experimented with a bunch of them. And I'm not ready to quit. --MikeTalk 11:47, 19 April 2020 (UTC)

Were there risk of WeRelate going dark - for lack of a technical contact for example - I would think very hard about what I might be able to contribute to prevent that. But I don't think it stops being a useful, openly searchable, repository without the flash-related features. I'm pretty strongly invested in this database.
I quite agree will (or should) continue to be useful for those who come here to discover information on someone. Adding new family groups is a different issue. --MikeTalk 15:44, 21 April 2020 (UTC)
I won't try to speak for others on the ongoing value of GEDCOM upload, but it's been a very long time since that mattered to me. The work that had to go in after those loads often left me wondering how much effort the load saved. And I think I will remain scarred for life by the years of effort that were needed to do basic de-duplication on the GEDCOM dumps of the early days. I don't strictly know how many pages I created over the years - but I'll bet its a lot less than I removed by way of de-duplication and straight-up delete of ancient/mythological spaces. --jrm03063 02:37, 21 April 2020 (UTC)
I'm always expanding the outer reaches of my own family -- these days, that means adding new 4th & 5th cousins to ancestors and their descendants in order to identify new DNA hits -- but I also have a number of other on-going projects. Whole-population studies of certain communities and military units through time, exploring certain interesting large family groups that simply interest me. I do all my research-compiling in desktop software (originally TMG, these days RootsMagic), and when I get at least the basic work done for what is usually 50-250 people, I upload it here as a GEDCOM. At that point, it doesn't take that long to go through the list of new pages and tidy up. That's a MUCH faster process than if I were to try to create each page one at a time -- because I've done that occasionally, when I only had a set of 8-10 page to create for a family. Typing and saving everything on my laptop is much quicker than waiting while my fast Internet connection does its thing. --MikeTalk 15:44, 21 April 2020 (UTC)

There are two programs that will go away if they are not rewritten: the Family Tree Explorer, and the GEDCOM importer. Here are a few questions to answer up front.

  • How important is it to rewrite the Family Tree Explorer? How many WeRelate users couldn't live without it?
  • How important is it to rewrite the GEDCOM importer? How many WeRelate users couldn't live without it?
  • Could we get by with a GEDCOM importer with less functionality that was available only to "trusted" users of the site? What functionality would be needed then?

Let's see what needs to be built first, then who might help build it.--Dallan 04:26, 21 April 2020 (UTC)

Dallan, for me, the GEDCOM import function is an absolute necessity, for the reasons I've given. GEDCCOM has many problems of its own, but there simply exists no substitute. When I'm cleaning up a GEDCOM import, I always use FT Explorer (with the Index tab) because it gives me a nice alphabetical checklist that I can work my way down through, and it keeps me from missing any of those new pages. And I can always see that list in the lefthand panel while I'm cleaning up pages on the right. It's pretty efficient. The alternative is to use "View" from the Trees page -- which gives you only a dozen or so pages from a given Tree at the bottom of a regular page, and in no particular order. And you have to keep two browser tabs open and flip back and forth in order to see both the list and the page you're currently working on.

Hi. My contributions to WeRelate have been on the cleanup side for several years now (getting rid of pages for living individuals), but I also prefer GEDCOM upload for similar reasons. However, I never really got into FTE, and never thought of using it as you do.
I'm a bit confused by your description of the alternate to FTE ("View" from the Trees page). I get that it is in a separate browser window and thus less than ideal, but I'm not sure what you mean by a list "of a dozen or so pages at the bottom of a regular page". If you mean a regular search page, then I'm looking at the same thing you are. If so, then you can sort by page title and also increase the number of results per page to up to 200. I know it is still not ideal, but might be tolerable until something else can be developed.--DataAnalyst 13:18, 24 April 2020 (UTC)

When you say "a GEDCOM importer with less functionality," what exactly are you thinking of? Omitting the GEDCOM Review step? I could live with that if I had to. That step alerts me to problems and possible data errors, so it would mean a bit more clean-up farther in to fix place and source names and such, but that's doable -- as long as I was able to get the GEDCOM up there in the first place. I don't think there would be any point in a GEDCOM with limited tags, though. --MikeTalk 15:44, 21 April 2020 (UTC)

My views on GEDCOM are perhaps well-known so I will try to be brief. My main point is that GEDCOM is only essential to maintain an existing pattern of work, and it is certainly possible to do lots of work without it, as I have contributed to over 100000 pages (and that always means at least one if not many sources on each page) in about 14 years of work.
I have only used GEDCOM once, to see how beneficial it would be, but found it tedious and hard to get it to do what I wanted. It seems under-documented: for example I was unable to figure out how to title a census so it would match the correct WeRelate Source by default, and I had trouble figuring out which field gets loaded into the text field of a source citation. Has the shifting to upper case of dates been fixed yet? That would save some people who dislike upper case a lot of time. And spreading out the posting of edits as a user takes days to finish a review has caused me problems with Mike once, and several others over the years, because I get notified of the first changes without any indication further steps are in the works, causing problems if I make changes before the others get around to finishing their review.
Now obviously some people make this work, and it makes the most sense when you are building a copy at home and transferring it. This is admittedly not my pattern of work, which undoubtedly influences my opinion, as others' patterns of work influences theirs. I am working on a population study of my own, but just entering it directly into WeRelate in the hopes it will prove useful to others. Having no long term personal interest in the data, I do not stage it on my home system, and thus I only enter it once. That said, the work I do at home has an audience of me, and the work I do at WeRelate has an audience of potentially many having many perspectives, and I have a hard time imagining ever transferring things as I keep them at home verbatim without having to stage them and edit them to reflect the change in audience (things like relationship to me, private information about correspondents, logs about where and when I did research, even some of the details that are known to be refuted, unproved or simply not of general interest). So even still, it always strikes me that it is just as easy to enter things into WeRelate manually: it ends up in a form I think is appropriate for WeRelate, and I find the think time during the posting always helps me spot areas needing more work or clarification.
I never used to use family tree explorer but lately have found it very useful for seeing which parts of a tree haven't been fleshed out yet. This is a big time saver for me, but I wouldn't call it essential. I don't understand what tools are available to replace this. I have seen similar things done in a Java applet years ago, but don't know if that is even a possibility these days. --Jrich 17:03, 21 April 2020 (UTC)
it makes the most sense when you are building a copy at home and transferring it.
See, this is exactly the case for me. I want all my work on my laptop (and backed up daily at Carbonite), because I want it all there handy no matter where I am, and whether or not I'm online. I post biographical & family info to a number of other sites, too, and I write letters to and articles for historical journals, so I do a lot of copying from my database. I also have a ton of scanned documents, and research notes, and other stuff. And it's all together in one place -- on my laptop. I'm too paranoid to have all my work available only at a single website. --MikeTalk 00:47, 22 April 2020 (UTC)

If by a "less functional" import - we mean something like the old days. A naive load without review for source sufficiency or duplicates - I think that's fine as long as it's only for a trusted user or two. I recall loading GEDCOMs to a tree of their own. Then using membership in the tree as a way to work through every page to know I reached them all to improve cosmetics. I don't know why I would need that again - but it's not impossible. As long as folks working that way understand that it's a way to know they started with a GEDCOM of <n> people and <f> families, and that corresponding pages for all <n> folks and <f> families are there as a start. That they then need to go back and tidy the whole thing - I don't see a problem with it. Human implemented graph/tree-traversal - of approximately corresponding trees in different systems - is something with which I have painful experience.
The explorer is kind of handy for the reasons Jrich offers. But I could live without it better than I could live without WeRelate altogether. --jrm03063 23:35, 21 April 2020 (UTC)

By less functional gedcom import, I'm thinking that instead of having a screen that shows scrollable lists of things on top and the web page on the bottom, we would take you to a screen that has links corresponding to each of the existing tabs, and clicking on a link takes you to a full-screen list. Clicking on a link opens whatever used to appear on the bottom of the screen in a new full-screen tab. Actions taken on that tab (matching a family for example) wouldn't be reflected in the list until you hit refresh.

Regarding the family tree explorer, there are four views. Ordering from simplest to most complex to implement, they are:

  1. the list view
  2. the pedigree view and the descendants view (tie)
  3. the hourglass (pedigree and descendants together) view

Which views do people use most often? More importantly, which views could people live without?--Dallan 05:39, 24 April 2020 (UTC)

Personally, I never use any of the chart views at all. (I'm honestly not sure what I would use them for.) I use only the list of pages, which (as I said) works as a checklist that I can work my down while cleaning up the import. If the list view -- or something functionally similar, as you described it -- were the only thing available, I would be fine with that. --MikeTalk 11:26, 24 April 2020 (UTC)
I find the Pedigree view most useful for reasons explained by Jrich. Secondarily the Descendants view for the same purpose though much less frequent. And I like the Hourglass view for a concise summary of certain families though that is more of a nicety. I have never used list view so no opinion on that one.--Jhamstra 17:03, 24 April 2020 (UTC)
I've been uploading the various MorrowDNA branches for... years. I'm behind enough as it is; manual would be a no go, but the version with links instead of a split screen sounds fine. Something that's restricted to trusted users would work for those of us commenting, but it would limit new people even more than the pure learning curve does already.
I can't remember the last time I used FTE. I would not miss it if it disappeared.
As Mike noted above, small is okay because it gives us an excellent place to post research that allows collaboration without being overrun. I don't have time to maintain my own website anymore, WorldConnect is near useless, Wikitree is a hot mess... this is still my favorite spot.--Amelia 05:22, 4 May 2020 (UTC)
I never found the FTE very useful and hardly ever use it. For tree perusal I find the on-demand hourglass pop-in(?) at the top of every Person: and Family: page (which works without Flash) adequate.
The Gedcom upload, though, seems pretty important, but of course it needn't be in the current form. The important part is being able to import and integrate with existing WeRelate content (families, places, sources). --robert.shaw 06:20, 6 May 2020 (UTC)
So what about: (1) FTE with just the list and pedigree tabs, and (2) GEDCOM uploader with just the overview, warnings, family matches, and import tabs? How badly would the rest be missed?--Dallan 05:08, 7 May 2020 (UTC)
How do we do what we do in the People Tab? (i.e., clean stuff up before it gets imported?) This part can take me months (as I open my upload from February to check what this would mean), and if it just gets uploaded for clean up later, I fear for my diligence. Also, how would we deal with sources without the sources tab? --Amelia 15:21, 9 May 2020 (UTC)
Forgive me if my approach strikes as lame beyond words (It has been a number of years since I had cause to load a GEDCOM). Last time I did an upload - I remember loading to a new/uniquely named tree. Then, I worked through every page in that tree, dropping them from the load tree and moving them to a destination tree. It was a way to be sure I reached every page (when the load tree became empty). But I wouldn't be surprised if you thought of this and rejected it - such that you're wondering only if my next suggestion will involve 3x5 cards... --jrm03063 02:02, 10 May 2020 (UTC)
I don't have a lot of time to spend on WeRelate personally this year. If a scaled-back solution doesn't work, do we have other ideas?--Dallan 04:54, 11 May 2020 (UTC)
Well, this conversation seems to have died; I can only hope because something's going on offline, because this is a depressing place to end. I didn't mean above to reject the ideas promoted, just to understand better what it would mean. One of the things I value, and I think the site values, is the checkpoint between upload and actually having the page go live, so one can take time to review and make sure things look right. Is that inextricably tied to Flash? It doesn't seem like it should be.--Amelia 19:20, 24 May 2020 (UTC)
I wholeheartedly agree, Amelia, that having GEDCOM upload with a checkpoint is quite important. Further, it's important to have a way to integrate the new individuals with the existing Persons of WeRelate. Secondarily, it would be good to have the mechanism support integration of sources and places, but that is less necessary. I would think that a set of relatively simple inter-navigating HTML pages could provide this without being nearly as fancy as the current Flash mechanism is. --robert.shaw 20:18, 24 May 2020 (UTC)
Could we please have some quotes for the professional, full re-writing this site, entirely in up-to-date code? Otherwise, we don't know what it is that we are told is un-affordable. The loss of functionally has, for years now, meant that I can't navigate around my tree beyond clicking links. I get in via either a tinyURL to a page, or via a Google search! It is a pathetic situation. We must remember that unless the site is easy to use, it is effectively unavailable to the general public and to the potential new user. --Helen-HWMT 08:38, 26 May 2020 (UTC)

I've been reading the additions to this thread but not understanding exactly what changes to the site are threatened. (I was surprised to see that someone considered WikiTree to be a mess - I use it a little and am impressed with what it can do as a wiki.) Here your GEDCOM upload followed by checking of every individual sounds a bit tedious. Maybe some of you should reconsider Familypedia, which doesn't have GEDCOM upload (though I expect it could if some programmer was keen enough to work on it) but does have simple individual upload and an automatic check if your individual is given the same page name as an existing one. No Flash, as far as I know, but Semantic MediaWiki allows for a practically infinite variety of semi-automatic table displays and search options. For any of you interested, the old URL presumably redirects to the new familypedia.wikia.org. Registration not essential but is free and has numerous benefits including much reduced advertising! Robin Patterson 00:07, 25 May 2020 (UTC)


Looking for volunteers to help both with GEDCOM review and with software development. So far only User:DataAnalyst has volunteered to help with software development, and we could use others to review GEDCOM uploads. Is anyone willing to help? If you are, please reach out to me at dallan at werelate.org.

Companies like Ancestry, FamilySearch, MyHeritage, etc. have likely each spent at least $1M to create their online trees. FamilySearch has dozens of developers working full-time on their tree -- they're likely spending well over $1M per year. Geni had a decent-sized number of developers creating their tree before MyHeritage bought them and I'm told they still have a couple of people working on it full-time. FindMyPast announced they were going to build a wiki-based tree and started in that direction but have since backed away. I agree WikiTree is a fantastic site and it is being actively enhanced. I have a tremendous amount of respect for Chris Whitten and what he has done and is doing there. Familypedia may be worth looking at as well, though I haven't spent time on it lately. I do what I can to maintain WeRelate, and I will work with User:DataAnalyst to get some sort of minimal (not full-featured) replacement for both the FTE and the GEDCOM uploader before the end of the year, but I'd be happy for some additional help.--Dallan 04:21, 12 June 2020 (UTC)

FWIW, I'll be spending the next several days migrating WeRelate off of an ancient hardware platform onto something a bit more modern. This will help with stability and also reduce costs so we remain in the black, as ad revenue has been dropping as more people use ad-blockers. People don't see this kind of back-end work, but it's also necessary to keep the site operational.--Dallan 04:25, 12 June 2020 (UTC)
I spent the last few days migrating WeRelate to a more-recent hardware and operating system platform. There were a few issues today with search and gedcom uploads, but everything should be working now. If you notice any problems, please let me know.--Dallan 04:05, 19 June 2020 (UTC)

Good news (I hope) for some users of FTE. I've got a first cut of the list functionality (without Flash) running in the Sandbox. You can check it out by going to sandbox.werelate.org and signing in as Test1 (password = testexplore). Go to My Relate > Manage Trees and select the "explore" link for TestTree. You'll see a list on the left and a Person or Family page on the right, as in FTE. If you click a link in the list, you'll see that page on the right. As of writing, if you click any other link (e.g., Edit or a sibling of the person), you will get dumped out of explore mode. I hope to fix that within a week or so. [Fixed 21 Aug 2020-DA] The list can be scrolled using the Next and Prev links. The Exit link will take you out of explore mode.

If you currently use the list function of FTE, please check this out and let me know if this meets your need. I can add namespace filtering as in FTE, but I don't plan to add a search (at least any time soon) as the existing search screen already supports searching for specific pages within a tree.

Note about the sandbox: It is not fully functioning (e.g., it has no place names and you can't add any; email is not running so you can't authenticate a new account). Also, because I am testing there, the site is a bit unstable. If it doesn't work at all, give it a minute or two and try again. If you get dumped out of explore mode when you don't think you should have been, go back to Manage Trees and start again. If you want a block of time to poke around at the new functionality, add a note on my Talk page (DataAnalyst) in the sandbox and I will keep out so you can do so.--DataAnalyst 19:40, 20 August 2020 (UTC)


I'm trying to understand the other requirements for FTE replacement. To me, the pedigree and descendant views in FTE are very similar to the Family Tree picture you can get on any person or family page. There are differences (such as display of full dates vs. years, inclusion of marriage dates, and listing of spouses in the descendants view). The Pedigree-Map (available under the More menu) also has similar views - again with some key differences. The most notable difference in both cases is that FTE indicates which pages are in your tree and which are not.

  • If we were to enhance either the Family Tree picture or the Pedigree-Map to meet the needs that FTE currently meets, what enhancements would be desired?
  • Also, I note that both of these views have boxes too small for all the data at times (but if you hover in Family Tree or click in Pedigree-Map you get all the data) - would changing that be a priority?

BTW: I'm working on FTE replacement. Dallan plans to develop a GEDCOM replacement later in the year.--DataAnalyst 20:39, 20 August 2020 (UTC)

First let me thank you for tackling this problem.
I looked at your Sandbox example and it did not do a lot for me. I can already filter searches by Trees and display every Person and/or Family in the Tree. But your questions got me thinking and looking at the options you suggested. The Pedigree under the "More" drop-down only shows Persons but not Families so this is not a substitute for FTE functionality. However the "Family tree" drop-down gives me most of what I need - it shows Persons and also Families if you hover over the connectors, and it shows ancestors as well as descendants. What it does not show is Tree membership. If the "hover detail" boxes showed my named Tree memberships then I could do what I mainly used FTE for - which was to verify which Persons and Families in the shared tree are actually members in my named Tree. Then I could quickly select a specific Person or Family to update their named Tree memberships.
Hope this helps a bit? --Jhamstra 20:03, 27 August 2020 (UTC)
Thanks. That is sort of what I suspected, although not quite the solution I was envisioning. Let me see what I can do. I haven't looked at this code at all yet, but will take a look in the next few weeks and see what is feasible for me to develop. I appreciate the feedback. I'll let everyone know when I have something semi-working in the sandbox.--DataAnalyst 20:40, 27 August 2020 (UTC)
Totally agree with Jhamstra, including a huge Thank You for Janet. I never really used FTE, but do use the "Family Tree" drop-down. And I know I sometimes get people in the wrong tree, or the wrong people in one of my trees. Gayel --GayelKnott 14:56, 28 August 2020 (UTC)
It wasn't all that hard for me to make the change you asked for. Check it out in the Sandbox. I've done 2 things: Added a list of user trees a person or family is in when you hover and get the larger box (as requested), and also if you are exploring a tree, the diagram will indicate which people are not in the tree you are exploring. To see both changes, sign on as Test1 (pw: testexplore), select the Test1 user page, and select "explore" beside tree "Kilborn". Select page Charles Kilborn (1) and then the Family Tree diagram. The first change (list of trees) shows up even when you are not exploring a tree.
Let me know if this is what you had in mind. If not, what should I change/add?
I also note that the Family Tree diagram shows only persons (not families) when you expand to the left (descendants). I don't know if it is in my skill set to fix this, but I will take a look some day.--DataAnalyst 18:41, 5 September 2020 (UTC)
(I deleted the former sub-thread because it is now an irrelevant distraction. Problem was handled on my Talk page - thank you very much for your patience! And I hope you don't mind my removing a few indent levels - they were getting too deep IMO.)
After coming to my senses with your help, I tested the feature I requested, both in normal mode and explore mode. I love the way it works in explore mode. And in both modes hovering works exactly as I hoped it would. I do have one comment about both modes - the list of trees displayed when I hover should only include my own trees - not everyone else's. Otherwise for some of my New England and Nieuw Netherlands ancestors this would become a very long list. For a guest who is not logged-in I would not show any trees in the hover box.
Regarding your comment about no Family hover boxes when you expand to the left, I have never seen this problem on the regular WeRelate web site. Hovering over the +/- connectors has always worked just fine for me. See for example Person:Martinus_Skrove_(1), or thousands of others in my own trees. I am wondering if there is something strange in your test tree?
Finally, let me offer you a hearty round of applause for tackling this. I think we are close to being able to lay the erstwhile beloved/maligned FTE to rest. --Jhamstra 15:25, 9 September 2020 (UTC)
And I failed to mention that while I liked some of the functions of FTE, I always found it a pain in the rumpus to have to open a FTE pane, wait for it to load-up my larger trees which is where it is most needed, wait even longer whenever I had to navigate up or down a level, etc. The Family tree drop-down is always there and it runs a whole lot faster than FTE. So for me being able to verify my trees without resorting to FTE is a HUGE win. --Jhamstra 15:39, 9 September 2020 (UTC)
Thanks for the feedback. I should note that it is only the trees of the user who is signed on that show up. I added a dozen trees for Test1 just to test what happens if the list contains more than 10, even though I know that would be very rare for a real user. The list still shows up if you are not signed in, and says "User Trees: none". That should be quick to change. I'll take a look at that before I get this deployed. I'm occupied with other stuff today, so it will be another few days.
As for the family not showing up for descendants, I didn't mean the popup, which does show up, but a box for the spouse in the diagram itself. Right now, there is no way from the diagram or the popup to see if the spouse's person page is in the user tree. To add a box for the spouse might be quite a bit of work, so I will leave that for now. If it is a concern once people switch over to using this feature instead of FTE, someone can create a suggestion. (Of course, if you click on the page of a descendant and select the diagram again, then you can see each of that descendant's parents. Maybe that is good enough.)--DataAnalyst 16:56, 9 September 2020 (UTC)
For me the structure of the Family tree dropdown is fine. The point is, navigation inside the box is very fast. I have never been bothered much by having to click around inside the tree display to get more details. Often I right-click in a pop-up and open a new tab to get more details. I usually have a dozen or more WeRelate tabs open at the same time. As I explained above, my biggest problem with FTE (when it worked) was that it ran really slowly on big (order of many hundreds to over a thousand) trees. But it is often on these larger trees where I want to edit or verify tree membership.
When there are no trees to display in a popup, I think it is better to not advertise that fact and clutter the popup.
Thanks again, and I look forward to this upgrade going live I think the Family tree dropdown will become the common way to check and edit tree membership. Far better to enhance an existing tool than to develop separate tools for separate jobs, in my opinion. --Jhamstra 17:18, 9 September 2020 (UTC)

Map View [24 June 2020]

When I've gone into Werelate in the past, I have sometimes added a small town to the list of places with its latitude and longitude, which I pin down wit trial and error because the instruction about click on the map to show the lat/long has not ever worked for me. Today, when I signed into Werelate to add another small village (which is another one of my ancestral villages), I could not see any maps. Is this because of some update in my Microsoft operating system, or some change in Werelate?--dquass 20:46, 12 June 2020 (UTC)


Noticed this also, starting yesterday (11 June 2020), My guess is that google did something to their mapping.--jaques1724 22:32, 12 June 2020 (UTC)
We've been using an old version of google's map api, and it looks like they turned it off. I'll update the code to use the latest version tomorrow.--Dallan 04:03, 19 June 2020 (UTC)
Thanks. I use it to check my work when adding cemeteries from Find A Grave. Their coordinates are not always on target and I usually have to tweak them. By the way, response time is vastly improved with the upgrade.--jaques1724 19:31, 19 June 2020 (UTC)

Is that what happened? I recall reporting the same problem about a month ago and then the maps reappeared. Hopefully, with the new revision of the map api, the long/lat requested will appear closer to the middle of the map. It has always been toward the bottom; so much so that when a place is about 5-10 miles north of a body of water, the lake/ocean/whatever doesn't show. This used to bother me when I was defining small towns in southern Ontario, Canada, and again now when working on Sussex, England.--Goldenoldie 08:38, 19 June 2020 (UTC)

Maps should be working again now. Let me know if you notice any further problems.--Dallan 04:54, 25 June 2020 (UTC)
Just tried it - SUCCESS! THANKS!!

user and edit statistics [26 December 2021]

The page https://www.werelate.org/wiki/Special:Statistics has been archived at the Internet Archive irregularly since 2006, and I've just archived a 2020 version. The pipe-delimited dataset appears below. Apparently the 'views' value is nor working for Statistics and is, therefore, not usable.

Year|Month|Month #|Year Frac|Day|# pages|uploaded files|page views|page edits|reg users|admins|edits/page|page edits/user
2006|May|5|2006.3|11|119297|n/a|155355|4671|118|5|0.04|39.58
2009|Feb|2|2009.1|28|4580786|9141|7669938|8995090|14635|20|1.96|614.63
2009|Dec|12|2009.9|11|5269543|13177|7669938|10955926|18003|27|2.08|608.56
2010|Jan|1|2010.0|16|5312940|13599|7669938|11064217|18219|27|2.08|607.29
2010|Feb|2|2010.1|17|5388305|13897|7669938|11211119|18515|28|2.08|605.52
2010|Mar|3|2010.2|29|5424721|14599|7669938|11318558|19128|29|2.09|591.73
2017|Jul|7|2017.5|2|7399196|62446|7669938|20794576|77038|29|2.81|269.93
2018|Sep|9|2018.7|13|7565817|65380|7669938|21807891|102688|29|2.88|212.37
2020|Jun|6|2020.4|23|7678646|71150|7669938|22932237|111434|30|2.99|205.79

The "Year Frac", "Edits/page" and "page edits/user" are calculated fields.

A subset of the data was used to produce a plot

Year Frac|edits/page|Edits/100/user
2009.1|1.96|6.15
2010.1|2.08|6.06
2017.5|2.81|2.70
2018.7|2.88|2.12
2020.4|2.99|2.06

--Jrich 02:47, 26 December 2021 (UTC) Without much fanfare, the plot results.

Image:WeRelate editing trends 2009 to 2020.png

Regards ---ceyockey 01:48, 23 June 2020 (UTC)

Some other stats, if interested are here:

https://www.werelate.org/wiki/User:AndrewRT/Size https://www.werelate.org/wiki/Image:Werelate_growth_v2.jpg (figures updated even if graph isn't!) AndrewRT 22:26, 1 July 2020 (UTC)


Decided to update and revise the calculation to be a little bit more valid. The image page for the image below has the data and the data source information. The X-axis is in thousands of days since 11 May 2006 when the first archived stats page appeared on Internet Archive. Though arbitrary, we crossed 1 edit per 10 days per user back around March of 2013. --ceyockey 23:24, 25 December 2021 (UTC)

Image:WeRelate editing decline all available stats.png

The stats show what we, the 31 administrators, already saw: only a few of us enter data.
We don't know if it is because the site is little-known, if other sites offer different strategies (single tree and matching versus one tree for all wiki style).
Anyway, thanks much for the graph. Even if reality hurts, it wants to tell us something.
And sometimes one has to pursue a dream instead of reality.
My answer is that i continue to enter new pages from scratch, no matter what.
I know for a fact that i am not the only one.
Warmest regards, Ron. woepwoep 02:12, 26 December 2021 (UTC)
No, not the only one, and thank you for your work, but it would be nice to have more. Frustrating that so many people seem to want to dump and run and not invest in ongoing research.
I suspect the big decline was a result of very modest checking of GEDCOMs. Probably, based on this, more isn't necessarily better. Even here in the New World, where I work, genealogical discoveries are often centuries in the making. Keep plugging away! The value is in being right, not in being biggest. --Jrich 02:47, 26 December 2021 (UTC)
Hear hear @Jrich !
We are descendants of a time when people started to build a cathedral that would take more than their lifetime to build.
Merry Christmas, Ron. woepwoep 03:21, 26 December 2021 (UTC)

broken link in homepage footer [30 June 2020]

In the footer, there's a link to the foundation for on-line genealogy that is broken --> http://sites.google.com/a/folg.org/family-history . I'd suggest that a broken link on the homepage is not a good message to send to potential contributors. Can this be updated or revised so that either the link is removed or fixed?

WeRelate is a free public-service wiki for genealogy sponsored by the Foundation for On-Line Genealogy formerly in partnership with the Allen County Public Library. 

Thanks. --ceyockey 16:29, 28 June 2020 (UTC)


Maybe this could be an alternative link? --> https://www.guidestar.org/profile/81-0660912 --ceyockey 16:32, 28 June 2020 (UTC)

I've made a temporary substitute to the link near the bottom of the main page, so that instead of getting error 404 on url http://sites.google.com/a/folg.org/family-history it goes to https://www.charitynavigator.org/index.cfm?bay=search.profile&ein=810660912 . I didn't use the guidestar.org link because that site, if you are not logged in, forces you to register to see the content of the page. --robert.shaw 21:00, 28 June 2020 (UTC)
While looking at the above problem, I discovered a different but similar problem: All (or most) pages on WeRelate have a footer, the last line of which has a link "About WeRelate". That link is okay; it reaches the page WeRelate:About. The first sentence of WeRelate:About includes a link for "Foundation for On-Line Genealogy, Inc." which has url https://folg.org and that url causes Chrome to give "This site can’t be reached / ERR_CONNECTION_CLOSED". That error is apparently because https: is used and is not supported by the target. If one substitutes "http:", the site returns a blank page. (Actual HTML code is returned, but the <body> is empty.) For the moment, I have replaced the url with the same charitynavigator.org url given above.
I'm not sure what, if anything, should eventually be done for these two links. --robert.shaw 21:20, 28 June 2020 (UTC)

Thanks for the fix. I did notice the About page link shortly after noticing the main page link problem, but there are several things about About that need revising, so I was going to reserve comment until collating a suggested changes set for that page. Regards --ceyockey 03:42, 1 July 2020 (UTC)


Understanding different styles of new data input and current data validation [2 July 2020]

Hi all,

I would like to start a dialogue -- not a discussion -- about the various styles of entering new data input and current data validation.

The thought came to me that some people like to finish and close, while others would rather start and connect. When I spot some person or family page that is incomplete, I am excited ... for me this is a welcome page, an invitation to join if you will. I know for a fact that for others, an incomplete person or family page means work !

There is nothing wrong with our various perspectives on the status of a person or family page.

My question is simply this: is it possible that we as administrators become aware of the various ways how people think and act, and support them in a way that they feel fueled?

Thanks, Ron woepwoep 14:12, 29 June 2020 (UTC)

How one practices genealogy at home is largely immaterial, but contributing to a collaborative tree like WeRelate is different. It is about the reader. We should be empowering the reader to build on the work that is there. Some time, maybe tomorrow, maybe 30 years from now, a poster who has done in-depth research may be able to push that page a little further. Posting pages with no dates and no locations makes it difficult for the reader to know who is being identified. Posting without sources makes a future reader guess where the data came from, and chances are, not much effort will go into that before the data is erased. If people want to post a speculative post and see if anybody can help, that is fine, but they need to explain what they believe, and why, as a matter of courtesy to the people that are going to help them, and as a matter of efficiency so those people can get up to speed quickly.
While there are many different styles of work, WeRelate may need clarify some of its messaging about its purpose, and the form of contributions that work best, and differentiate itself from other websites that cater to different situations. For example, people that are looking to dump their family tree here and expect it to sit there unchanged should realize that that cannot be supported by the Single Tree that has no ownership of pages. Personally, I would like to see WeRelate try to encourage and educate users about more professional approaches to genealogy, so we can grow to be a fairly reliable reference database of the current state of genealogical understanding. But WeRelate should not be trying to serve all styles. It should be trying a serve a purpose. --Jrich 18:15, 29 June 2020 (UTC)
Excellent Jrich !
Anyone else?
Thx, Ron woepwoep 04:49, 30 June 2020 (UTC)
Agree totally, thanks Jrich ! --Beatrijs 15:17, 30 June 2020 (UTC)
Thanks for starting a conversation. I've been thinking for a long time that WeRelate should try to distinguish itself on the quality of data, and I'm pretty sure most long-term contributors would agree. I agree with everything that Jrich said. We should also recognize that we have contributors who use WeRelate to build their trees, and thus have incomplete information at any point in time, as well as weak sources (such as "Aunt Mary's one-page genealogy that I am starting from"). Even so, we should encourage people to enter their sources, and then add new sources as they find confirmation.
It would be great if this conversation could evolve into a renewed statement of WeRelate purpose/focus.
I'd like to know what others think about more stringent oversight such as rejecting GEDCOM uploads with few dates and weak sourcing. (You don't need to reply Jrich - I know you would fully support this :) )--DataAnalyst 15:27, 30 June 2020 (UTC)
Finding sources that are not "weak" for persons that were born and died within last 100 years is difficult since records are often not yet public. This is also a starting point for new researchers.--fbax.ca 23:21, 30 June 2020 (UTC)

So, to see if i understand this, the general idea is that we want to encourage people to use the site.....by not letting them use the site unless they live up to the gatekeeping standard?

I have a lot of information on here that does not have sources yet because this is a long term goal for me, and I'm sure its out there, in fact I know that there are sources listed on other websites, i just dont have the info entered yet. If you tell me I need to delete that data until I have a valid source (as opposed to simply flagging it as untrusted until sources are added), then I will probably just leave.

Perhaps you can instead add a filtered view so that it only includes sourced entries, or only 1st and 2nd hand sources, or whatnot. Those that have the data can easily find what they want, those who still have work to do can still use the site to collaborate, which is the whole point.

We can't build a common tree if only select few are allowed to touch it.--Jonmcrawford 23:01, 30 June 2020 (UTC)

I think you may have read too much into other contributor's opinions. I can't totally talk for others, but I'm talking about encouraging people to enter what sources they have, as they go. Even if the source is "family records" (I have some of those, for people from the 1900's). Also, I'm talking about a go-forward approach, not deleting pages that already exist (unless, of course, they prove to be nonsense or are for living people). And maybe encouraging adding sources to existing pages that don't have any before continuing to build the tree. Otherwise, there really is no confidence that people will come back and add sources.
I also may have been unclear with my GEDCOM suggestion. By "weak sourcing" I did not mean that only strong sources would be accepted, but that the reviewer get a sense of the reliability of the data based on the sources. We've had way too much garbage uploaded to WeRelate that we've taken years to clean up and don't want to add to it. Also, GEDCOM's with few dates are a way that people avoid edits to prevent pages for living people, which is a problem we want to avoid.--DataAnalyst 23:52, 30 June 2020 (UTC)
It is not clear to me how we are going "to collaborate, which is the whole point", if you don't enter sources. If you don't have sources, you aren't going to be able to convince me you are right when I have something different; it becomes impossible to resolve discrepancies because I don't know how reliable your data is; and since I know good practice (i.e., Genealogical Proof Standard) includes documenting sources, a lack of sources doesn't look like good practices have been followed. I understand many people have not recorded sources, but there is nothing preventing them from going back and documenting them, and waiting to post until that is done. From personal experience, I can tell you, the improvements in your family tree from this activity will be significant.
In the early days of WeRelate, massive GEDCOMS uploads (which are still being cleaned up) uploaded data that is, at best, partially right, and often, completely wrong. All these sourceless pages require volunteers to hunt for sources and complete them - time that those valuable and skilled volunteers could better spend investigating unknown facts instead of simply cleaning up undocumented facts.
I have posted extensively about how important sources are in a collaborative environment on several of my user pages (e.g., here) and people are free to read that if they need bedtime reading, or don't understand the points I am making.
Whether a person is born one day or the next is not really important. What is important is to believe that whichever one you have is the correct one. That ultimately requires you know how that data is known, i.e., sources, and how to evaluate the reliability of sources. Entering the data value is only a small fraction of the work and and a small fraction of the value of a page. Even that statement is true only if the data is true, which is hard to believe until a source is known. If the data is wrong, it sends those poor volunteers on a long search for something that does not exist.
This is a fairly inclusive website. Anybody can edit any page, you don't have to have any kind of certification. It has not been proposed to change this, only to use warning popups to slow down excited poster and encourage them to read help pages that alert them and educate them on professional methods, so they can grow to become more valuable contributors. Not all contributors can be expected to work at the same level to start with, but hopefully they can grow into it. If they are not interested in doing the work to develop their skills, that may be an indication that they are looking for features better provided by other websites. --Jrich 02:43, 1 July 2020 (UTC)
This is an old argument that keeps coming back. My own contributions to this wiki have been developed online in situ. I do not have a separate private genealogy database that I maintain somewhere else - WeRelate IS my database. So information of varying quality has been entered and updated, as I have uncovered it, and found the time to enter it. Most but not all of my contributions now have sources documented. However where sources apply to an entire family, I have generally not taken the time to copy them to each individual family member. This was a long-standing request of mine - that we have an efficient method for propagating source citations. Unfortunately it has not happened. So you may have to look at the Family page, or one of the Parent pages, to find source citations that apply to the entire family.
If you go through some of the family groups and try to automatically flag pages with "missing" sources you will create a lot of noise. I would suggest that if you are trying to do something like this, then you only flag "missing" sources if there are no citations of the related Person and Family pages, perhaps for a couple of adjacent generations. That way small gaps will not trigger an avalanche of warnings.
As for nagging popups while editing or saving pages, if they require extra clicks to dismiss them then please give me a way to disable them. I don't need a nanny to baby-sit me while I am working. Often I edit groups of pages at once. And I may have to leave-off some work for a time and return later to complete it. For better or worse, the WeRelate structure allows me to do my work incrementally, in whatever order I have new information to add to the database. I have tried various other genealogy web sites, but none of them are as amenable to allowing different users to collaborate without imposing a common work flow, and still maintain a coherent collection of data. So I always come back to WeRelate.
--Jhamstra 03:45, 1 July 2020 (UTC)
Thanks for your input. Understanding your data entry style is good for anyone who might design additional controls in the future (not happening any time soon). This is part of the point of the discussion. I appreciate (and share) your frustration with the effort to add the same citation to multiple pages. As I'm sure you're aware, the impact may be that someone changes a page without noticing a source. Not the end of the world, but an opportunity to start a dialogue. You (I assume) understand and are willing to take the risk, to achieve faster data entry.
The risk associated with entering really incomplete data (e.g., just names with no dates) is that another person may create a page for the same person without realizing, or being cautious about assuming, that the page already exists. Not great for WeRelate's goal of one page per person. So, in the spirit of discussing how people work with WeRelate, are there actions we can take to mitigate this? Improved automation could help, but assuming we don't have developers to handle that in the near term, can we keep this risk in mind and think about how to avoid duplicates?--DataAnalyst 19:16, 2 July 2020 (UTC)
>> WeRelate IS my database
Same here, @Jhamstra
woepwoep 23:17, 1 July 2020 (UTC)
Having watched this discussion, and having seen some of the different approaches people take to using it as well as what happens on the other two reasonably reputable wiki sites, I think WeRelate does allow for a great deal of flexibility already, more so than other wiki sites. The one real problem I do see is the uploading of Gedcoms. At one time WeRelate did block Gedcoms that had "too many" problems (I don't remember the exact percentage). How difficult would it be to set up some sort of screening for the inclusion of places, dates and sources, and then block those Gedcoms that fell below some certain percentage in any one of those categories (somewhere between 50%-75% perhaps)?
Increased control in GEDCOMs is a good goal. For now, we have to rely on the administrators to screen. An experienced user just volunteered for this, and I think that will improve the situation. (For those impacted by recent GEDCOM uploads, the new volunteer was AFTER the uploads that caused issues.)--DataAnalyst 19:16, 2 July 2020 (UTC)

Wishlist or logic? [20 August 2020]

Hi all,

I forgot the URL to the wishlist. But here's the thing. When i add a person's husband or wife. And then i add this partner's parents. So i add a family. A father. A mother. In the current system it would be obvious that, upon adding the father's details in the search box, and pressing the Next key, i would only see male persons in the search results? And vice versa, when the father is added, and the mother is due, upon adding the mother's details (the mother's personal page) i would in the search results expect to only find females?. Thanks, Ron woepwoep 11:29, 20 August 2020 (UTC)

WeRelate:Suggestions --Jrich 12:50, 20 August 2020 (UTC)

[1 September 2020]

Just for a laugh, take a look at the template description for Bury, Lancashire, England that I found on our website this afternoon:

the text in this section is copied from an article in Wikipedia

Bury may refer to:

  • The burial of human remains
  • -bury, a suffix in English placenames

Looking at the WR history, apparently I opened the page to add Research tips in 2014, but my mind must have been on adding a whole lot of research tip entries that day, and I didn't get back to "unbury Bury". The town is not exactly small; its population is 78,000.--Goldenoldie 17:53, 1 September 2020 (UTC)

Obviously gremlins at work :-) At least they had a sense of humour. --GayelKnott 04:11, 2 September 2020 (UTC)

FTE replacement status - check it out [22 December 2020]

The list functionality of Family Tree Explorer has been replaced. To use the new functionality, go to one of the following places where you can see a list of trees (your own or someone else's):

  • your User Page (if you created one)
  • someone else's User Page
  • your Dashboard (on the My Relate dropdown menu)
  • Trees (on the My Relate dropdown menu)

Each tree with at least one page in it will have a link called "explore" after it. Select the link and you will see on the left a clickable list of pages in the tree, while the main part of the screen displays the first page in the tree. Scroll the list using Next and Prev, or jump directly to entry number N by entering the number N. You will stay in the "exploring" mode until you click the Exit link. That is, you can select a source, place, sibling, etc. and the list on the left will remain there, until you select to Exit.

Some screens (such as "What Links Here") won't show the list on the left, but as soon as you return to a screen that supports the list, it will show up again.

Please let me know (respond here) if any small changes would enhance this experience. Thanks.

Note: Additional changes to replace other features of Family Tree Explorer will come soon.--DataAnalyst 19:00, 5 September 2020 (UTC)


The remaining features to replace Family Tree Explorer have been implemented. These are:

  • If you are exploring a tree (as described above) and select the Family Tree link just above Facts and Events on a Person or Family page, you will be informed about which ancestors and descendants are not part of the tree you are exploring. For example, if an ancestor is not in the tree, the box will include the words "not in tree".
  • Whether or not you are exploring a tree, whenever you select the Family Tree link just above Facts and Events, if you hover over the box for a person or the dash between generations (which represents a family), the popup will give you a list of all your trees that person or family is in.
  • The Trees function (left-hand menu) and the tree check boxes at the bottom when you add or edit a page have been enhanced to let you know which tree(s) the page is currently in and which tree(s) WeRelate is proposing for the page. Before this enhancement, it was not always possible to tell whether a page was in a tree or if WeRelate was making it easy to add the page to one or more trees by pre-checking the box(es).
  • The function to pre-check tree box(es) has been modified. For those who may not be aware, the function works like this: If you add, edit or select the Trees function for a page, and that page is not yet in one of your trees, but your most recent change (add, edit or Trees) was for a page in one or more of your trees, WeRelate will pre-check the tree(s) associated with last page you changed. This function has been modified such that if you choose to explore a tree (as described above), WeRelate will pre-check the tree you are exploring instead of the tree(s) associated with the last page you changed.

I know some of these descriptions are a bit complicated. Some day I'll get around to rewriting the Help and include pictures. In the meantime, check out the functionality for yourself and let me know if any small changes would meet your needs better.

This concludes the replacement of FTE. At some point before Christmas, I will remove the "launch FTE" links from WeRelate. If further changes are required after that, you can add them to the Suggestions list. I hope you enjoy using the new functionality.--DataAnalyst 14:05, 14 September 2020 (UTC)

I checked it out (logged in and not logged in) and it works great! Thanks so much - I will not lament the demise of FTE. --Jhamstra 16:33, 14 September 2020 (UTC)
Thanks for the feedback. I like it better than FTE, too.--DataAnalyst 16:49, 14 September 2020 (UTC)
This is fantastic. I could waste hours just playing with it. Thanks so much for all the work you have put into it. Gayel --GayelKnott 21:10, 14 September 2020 (UTC)
You're very welcome. It was (mostly) fun learning something new. It was especially fun when it worked.--DataAnalyst 21:23, 14 September 2020 (UTC)

Has anyone thought up a name for the FTE replacement yet? --Goldenoldie 20:12, 14 September 2020 (UTC)

It isn't really a separate thing any more, and won't show up on the menu. There's only a link (called "explore") beside each tree name, and this is just to get to the list. The existing Family Tree functionality (with enhancements) is also part of the solution and doesn't need a new name.
If we're going to talk terminology, though, I wouldn't mind renaming the "view" link beside each tree to "search", since that is what happens - it takes you to the search screen with a keyword filled in. The new "explore" link could be called "list" - I'm open to suggestions.--DataAnalyst 21:19, 14 September 2020 (UTC)

Hello ! Does anyone like me have a display problem for this new feature? This only works on my desktop computer ... example --> https://www.werelate.org/w/index.php?title=Special:ShowPedigree&pagetitle=Person:Josiah_Alford_(3) Image:Pedigree werelate.JPG
but it's good on my smartphone except for the options "Birth places, Death places, all places" - Thanks ! Marc Roussel - --Markus3 07:16, 16 September 2020 (UTC)

I am not sure whether the problems on your smart phone are caused by this enhancement. Smart phone browsers tend to be dumbed-down compared to their computer cousins. The link works fine in Chrome and Firefox on my Windows laptop. But not being able to log-in as you means I cannot see anything related to your trees on this page even if something special should be there. All the enhancement does is add some tree-specific features. --Jhamstra 12:33, 16 September 2020 (UTC)
Actually, that wasn't even the page that was changed. The Pedigree Map (selected from the left-hand menu under More) is separate from the Family Tree diagram (selected from the icon above Facts and Events). I only changed the Family Tree diagram, so I'm pretty sure your issue already existed. Try the Family Tree diagram instead. It works fine on Chrome on my smart phone - you have to touch and hold a box in the diagram to get the popup that lists the trees.--DataAnalyst 15:14, 16 September 2020 (UTC)

BTW - you can look at someone else's tree if they've created a user page. When someone creates a user page, all their trees are listed there, and anyone can select the "explore" link. When you explore someone else's tree, the "not in tree" message relates to their tree. However, the list of trees in the popup is the list of your own trees the page is in (if any). This way you can see the overlap between someone else's tree and your own, if that is of any interest.--DataAnalyst 15:24, 16 September 2020 (UTC)

Merci pour ce début d'explication, mais beaucoup de choses ne sont pas claires pour moi. Mon anglais est très pauvre et je dois utiliser google traduction qui est loin d'être parfait. Me suis-je mal fait comprendre ? Ma copie d'écran provient de mon desktop/laptop sous Windows10 et Firefox. J'ai cru d'abord que le non fonctionnement était causé par AdblockPlus. Mais je l'ai désactivé et le problème reste le même.
Thank you for this early explanation, but a lot of things are not clear to me. My English is very poor and I have to use google translate which is far from perfect. Did I misunderstand myself? My screenshot is from my desktop / laptop running Windows 10 and Firefox. I initially believed that the non-functioning was caused by AdblockPlus. But I disabled it and the problem remains the same. - --Markus3 15:49, 16 September 2020 (UTC)
Ah ! Je viens de consulter le site sous Chrome ... Et voilà ! Je retrouve ce qu'affiche mon smartphone (sous Chrome) ! Le problème serait causé par Firefox ...
Ah! I just visited the site in Chrome ... There you go! I find what my smartphone displays (under Chrome)! Image:Pedigree Chrome werelate.JPG The problem would be caused by Firefox ... - --Markus3 16:22, 16 September 2020 (UTC)

Hi, Marc. You are still looking at the wrong screen. To get the new feature, click the circled link:

Image:Family Tree diagram - link.jpg

You will see:

Image:Family Tree diagram - expanded.jpg

If you press and hold a box on your mobile, you will see:

Image:Family Tree diagram - person popup.jpg

--DataAnalyst 17:07, 16 September 2020 (UTC)


Thanks, Janet ! It's OK. - --Markus3 06:00, 17 September 2020 (UTC)

Nifty new source reference Copy feature [26 September 2020]

I just noticed that we now have a convenient way to copy those complicated source citations when editing Person: and Family: pages. Once you have a source citation filled in on one page, you can go to the entry (in Edit mode) and click on a new "copy" command (which is next to "remove" on the citation header line). Then you can edit some other page, click on "Add source citation", and there will be a new "paste" command. Click on it, and all the copied citation fields are filled in. Saves a lot of painful repetitive editing. It looks like User:DataAnalyst just recently put this in. Thanks, Janet! --robert.shaw 19:53, 24 September 2020 (UTC)

You're welcome. BTW: If you add a new source to a page and want to copy it right away, select Show Preview (at the bottom of the screen) and the link on the new source will change from Paste to Copy. Might be faster than saving and re-opening in edit mode.
Keep your eyes on the WeRelate:Request List page for other changes as I pick away at the list - not necessarily in the order listed, as some changes are more difficult for me than others.--DataAnalyst 22:03, 24 September 2020 (UTC)
This is awesome if it works as advertised. I requested this kind of feature about 9 years ago! Whether I will actually use it now after I have entered a few thousand pages without it, I do not know. But thanks anyway for finally getting this done. It would have been a huge time saver for me and still would be if I decide to go back and propagate a lot of sources. --Jhamstra 05:33, 25 September 2020 (UTC)
I tried this out, pressed copy on a source citation, nothing visible happened. Added a source citation, pressed paste, and nothing happened. Tried the same process from one page to another page, nothing happened. I was able to copy a source citation of type MySource but all my attempts to copy a citation of type Source have apparently not worked.
A couple of questions. Just for clarification: is this a WeRelate-internal clipboard (I assume) or is it using the system Clipboard? It would be nice to be able to do the copy step without being in edit mode, to avoid the risk of some inadvertent change (and save one step). --Jrich 13:47, 25 September 2020 (UTC)
Not sure why it didn't work for you. Did you try more than one different source? I'm just wondering if there was some character in the citation that I need to look out for or if there is a length limit - I forgot to test for a length limit. Let me know which page and source you tried to copy so I can see if it works for me.
This enhancement uses an internal clipboard. The copy command doesn't show any visible result - that is as designed. I thought of allowing copy without having to edit, but could see no obvious place for the copy link. I didn't think we wanted to push the citation info down to allow a copy link above it.--DataAnalyst 19:36, 25 September 2020 (UTC)
I agree we don't want any visible wart showing on each source citation in normal (non-Edit) mode; besides there being no good place in the layout, people do way more looking at pages than source copying and it's harmful to clutter up the displayed sources with more, rarely-needed, stuff. There might be ways to make it available on a normal read-mode page without adding visible clutter to the normal citation display, but I think it would take a whole lot of design and coding to fit it in. The present, edit-mode-only copy seems pretty good to me.
The lack of feedback when clicking "copy", though, seems like a fixable problem. Three ideas: 1. when clicked, change the "copy" command text into "Copied"; 2. when clicked, change the color of the "copy" command text from blue to, say, green; 3. when clicked, put up a message box that says "Copied" and then disappears after a timeout. --robert.shaw 20:58, 25 September 2020 (UTC)
Sorry to be so long in responding, was gone all day. I tried copying the only citation on a page I was currently looking at, Person:Abigail Wise (5), first to itself, and then to another page. Tried again just before posting. There is nothing special that I can see: not particularly long, etc. Does have some quote characters in article title, and text in the text box, including an ampersand, but NO url in brackets or fancy formatting like <table> or <font>, or inclusion of templates like fgravemem, etc.
Regarding visible feedback, I would think that if there is a source in the clipboard, then paste should be visible as an available option, not if clipboard is empty. Less need for Copied, but if you are looking at the source citation currently on the clipboard it may save some confusion and work if it said Copied instead of Copy. The implication being that it is unnecessary to copy it again if it says Copied, and if you see and select Copy, you are verwriting the current contents of the clipboard whatever they are. --Jrich 22:49, 25 September 2020 (UTC)

So I confirmed it is the & causing the issue. I'll take a look at fixing it another day, and maybe see if I can find other problem characters. I already tested quotes and they work fine.

As for the other suggestions, I could take a look at suppressing Paste if there is nothing to copy - that might not be too hard to do. I'm not crazy about any of the suggestions for feedback on a copy. Think, for example, of copying 3 citations from one page to another and then to another - you probably want all the links to stay as Copy so you can copy them over and over again. Changing color on a link goes against web norms. And if I add a popup, someone's bound to ask me to get rid of it. When you copy in Windows, there's usually no visible feedback (Excel being an exception). People get used to it. If the function works correctly, most people won't think twice about getting no feedback on the copy.--DataAnalyst 23:31, 25 September 2020 (UTC)

I don't really care much, this isn't a feature I am going to use much, as I tend to craft my source citations specifically for the page it is on. And the Copy/Copied change doesn't seem like it would be an important feature since copying to the clipboard seems cheap so if done many times who cares. But I am not sure I understand the comment about copying 3 citations from one page to another. You have 3 source citations, only the one in the Clipboard should say Copied, the other two would still say Copy. That is the way that makes sense to me. This gives you feedback that yes, it was copied, and in case you get confused, a way to remind you what you have on the Clipboard. But as I said, just pressing Copy redundantly appears to be cheap, so no big deal. --Jrich 00:19, 26 September 2020 (UTC)
FYI, on Person:William Wood (128), copying the 4th (last) source citation didn't seem to work. No ampersand, so different issue? Has URL in brackets, also has apostrophe in text box which is stored as &apos;. --Jrich 01:00, 26 September 2020 (UTC)

On reflection, I'm fine with no feedback on a copy-click, since it is consistent with the usual text copy-click operation. I've poked around a bit on problems with copy/paste characters, and besides "&" found that "#" seems to be a problem in the same way in that it prevents copy and paste from giving a result. I also found a problem with "+" in that it is replaced with " " (blank) in the pasted version of the citation. Didn't see any other issues. I tried all of the special chars on my keyboard, and tried them in all of the fields (other than Images+ and Notes+). This was in "Citation Only" mode. Oh, and the problem with the last citation on Person:William Wood (128) is that the URL in it uses a "#". --robert.shaw 20:32, 26 September 2020 (UTC)

Thanks. The defect has been fixed. I tested all special characters and punctuation, as well as an accented character. Please let me know if you encounter any other problems. I also added a length check, since a citation over about 5500 characters won't work. There is now a popup message if the citation is too long to copy. Thanks for the feedback.
I decided not to suppress the Paste link if a copy has not yet been done. People work in different ways, and someone might create a new source before copying the old one. I'd like people to use the feature for a while before requesting further changes. I suspect it will be fine the way it is, now that it is more reliable.--DataAnalyst 20:57, 26 September 2020 (UTC)

New Roadmap for improvements to the Wiki [30 September 2020]

Hi

I created a new roadmap to show what is being worked on now and next to improve the WeRelate site. Select the Watch feature on the Roadmap to get updates on status.

I invite people to check out new features in the Sandbox as they become available there, keeping in mind that as I continue to code and test, I can break the Sandbox at any time (you'll know it's broken as you won't get a page at all). Also, the Sandbox is not fully functional, so you will see things such as <pageinfo> where there should be text, and you can't do anything involving places. Use user name Test2, password testmore in the Sandbox.

If you have feedback on improvements, please do not respond in the Watercooler. Instead, find the Suggestion Talk page (from the WeRelate:Suggestions page) and respond there. Thanks.--DataAnalyst 17:19, 30 September 2020 (UTC)


New date edits [1 November 2020]

Within a day or two, WeRelate will have some new date edits. This change does NOT require users to do anything, even though you may see some suggestions and error messages. However, if you see an error message under a date, you may wish to correct the date.

See WeRelate:Suggestions/Format Date Field for more information. Feedback on the suggested dates and error messages you may see is welcome. Please provide it on the talk page of the suggestion. Thanks--DataAnalyst 19:41, 6 October 2020 (UTC)

By tomorrow, this change will progress to the next step. When you edit a page or select preview, WeRelate will automatically replace a date that doesn't meet GEDCOM standards with the format that does. If WeRelate cannot interpret the date, a message will appear below it, just as it does today. You will NOT be required to fix such a date - that will come several months from now. (I'll be cleaning up all the WFT EST dates in the meantime.)
When WeRelate replaces a date, it will show the original date below, as "was: olddate". Please give it a quick check to ensure that the date has been replaced correctly. I tested everything I could think of, but I might have missed something. If you notice an error, please let me know right away (here, the suggestion page or my Talk page).
Note: The date replacement will only occur when you edit an existing page or select preview. In the latter case, the replacement will only show in the edit portion of the screen, not the preview itself. If you save the page, the new date will be saved. If you cancel the edit, the new date won't be saved. If you think the new date is wrong, you can retype the old date and save the page.--DataAnalyst 13:41, 1 November 2020 (UTC)
Thanks for this update. If a date is entered as "7 sep 1929" when adding a new person; the date is changed to "7 Sep 1929" without any mention of old date. fbax.ca 14:08, 1 November 2020 (UTC)
Yes - if the only change is the case, then the replacement is automatic. It has been this way since Oct 8. I didn't see the point in asking people to review such a change. BTW: For those who prefer European-style lower-case, they can get the month in the language of their choice (including appropriate capitalization) by selecting the language in their Settings. This applies only to the month, not the modifiers (Abt, Bef, etc.), but I'm open for conversation about modifiers.
Thanks for pointing this out, though. You never know what is intentional and what is a defect, so I'd rather hear from you than not.--DataAnalyst 15:14, 1 November 2020 (UTC)

Broken child sort on 13 Oct 2020 [14 October 2020]

You may have noticed that if you added or updated children in a family today they do not display in the correct order. I apologize - this was an unintended result of a change I made to improve sorting of events on a person page. The code has been fixed. However, the pages you updated today may still show the wrong order. To fix the order, change the birth/christening date of any child in the family, save the page, and then change the date back to the correct date. This should fix the order for all children in the family. Sorry for the inconvenience.--DataAnalyst 03:13, 14 October 2020 (UTC)

Thank you Janet. woepwoep 03:25, 14 October 2020 (UTC)
My thanks, as well, including for all the work you're doing. Gayel --GayelKnott 17:19, 14 October 2020 (UTC)
Yes, Janet, thanks for all the recent improvements. Changes may come with occasional problems, but it's worth it to have the new functionality. --robert.shaw 17:54, 14 October 2020 (UTC)

Poor Law Unions [3 November 2020]

I have been editing some pages for suburbs of Manchester, England, and this includes checking through the "Sources" under Manchester to see if they need to be added to the records for a suburb as well. So far I have come across four sources dealing with Poor Law records. Each one describes the subject as "Deed/Land records" (a possibility from the pull-down list).

Obviously the English Poor Law system was something that the original compiler was not familiar with. These sources generally list the unfortunate people entering and leaving the local Workhouse. They are better described as "Institutional records". --Goldenoldie 20:40, 3 November 2020 (UTC)


New gedcom review in beta [12 December 2020]

I have finished the new gedcom review program. It has most of the same functionality as the old one. If you want to try it out, click on "gedcom review" under the "Admin" menu, then click on a "beta" link next to the gedcom you want to review. I will remove the "beta" label and make it the main gedcom review program next month. If you notice something that's not working in the new program, let me know and I will look into it.--Dallan 05:43, 15 November 2020 (UTC)

The main link in "gedcom review" will be to the new reviewer probably by tomorrow. The old reviewer will continue to be available until about the end of Dec. - you can access it by clicking the "Flash" link next to the gedcom name.--DataAnalyst 19:21, 12 December 2020 (UTC)
Thank you Dallan. I do not use GEDCOM uploads so this does not directly affect me. However many of our users do use this feature, and it is crucial for the viability of WeRelate. As I have entered or edited thousands of pages of data on WeRelate, I am heavily invested in its future. --Jhamstra 16:58, 15 November 2020 (UTC)
Yes, thanks, Dallan. I only gave it a quick look but the first thing I noticed was a typo on the Instructions, beside the Remove button. It says "uplading" instead of "uploading". I hope to take a closer look in the next week or so, but I'm pretty tied up for a few days right now. Excited to have this in beta!--DataAnalyst 20:23, 15 November 2020 (UTC)
I've actually just finished putting together a GEDCOM of ~150 people, so I know what I'm going to be doing this weekend. Thanks for getting this rolled out before the Viking funeral of Flash, Dallan! --MikeTalk 20:27, 11 December 2020 (UTC)

The new non-Flash GEDCOM reviewer has been implemented for all users. Starting yesterday (Dec 10), all newly uploaded GEDCOM`s will get links to both the new reviewer and the previous Flash version, and users can choose which to use (or use them both interchangeably). After the end of Dec, only the new version will be available. Please report any problems here or on the Support page.

If you are already in the process of reviewing a GEDCOM uploaded before Dec 10 and wish to try out the new reviewer, add a topic on User talk:DataAnalyst to request the new link and I will add it to your talk page. You do not have to reload your GEDCOM or start your review over again - the new reviewer will pick up all the changes you have already made.

Happy reviewing.--DataAnalyst 13:52, 11 December 2020 (UTC)

I just noticed that the Statistics on the Overview page are not being updated as people do their work. Dallan has been notified and will fix this when he gets the time. The temporary workaround is to return to WeRelate and then start your review again - the statistics will show the current state of your file.--DataAnalyst 15:18, 11 December 2020 (UTC)
Dallan fixed the program so that Statistics are kept up-to-date as you work. Yay, Dallan!--DataAnalyst 23:43, 12 December 2020 (UTC)

Time to archive the old posts? [18 January 2021]

This page is getting AWFULLY long. How about we catch up by archiving the last couple of years of posts? Or at least the 2019s. (I have no idea whose job that is, though.) --MikeTalk 17:05, 18 January 2021 (UTC)

A good suggestion, however I would prune the page based upon when the last comment occurred rather than when the discussion began. Some of these discussions have in fact been ongoing for years. If you want to prune everything before 2019 (eg) then for these ongoing discussions I would begin the sequel with a link directly to the previous portion of the discussion in the archive. --Jhamstra 17:41, 18 January 2021 (UTC)
2019 has been archived. Perhaps someone can delete the two pages I created in error. 23:55, 18 January 2021 (UTC)

Islington St. Mary parish, London, England [20 February 2021]

I discovered today that Ancestry has indexed the entire baptismal register for Islington St. Mary parish for the years 1836-1841 under Lambeth St. Mary parish (that's 1,904 entries). Each page in the microfilm images is titled Islington St. Mary and this church appears in each baptismal entry, but the indexing takes it to Lambeth St. Mary.

Both parishes were densely populated at this time, but located on opposite sides of the Thames. Islington was in Middlesex and Lambeth was in Surrey.

This just shows how careful a researcher must be when looking for records in Ancestry.

--Goldenoldie 21:09, 20 February 2021 (UTC)


Acting like a pack [16 May 2021]

hi all,

i get much energy from combining my personal interest (area 20 kilometers around my place of birth) with the findings of other members of WeRelate.

So my idea now is that we put forward a challenge - as a pack - that increases our community feeling.

Let me know your thoughts.

Thx Ron woepwoep 04:02, 26 April 2021 (UTC)

I think this is a great idea. Do you have something in mind that enough people might be interested in and have access to sources for?--DataAnalyst 17:25, 26 April 2021 (UTC)
Thank you Janet. My current "project" is to relate to persons born in Winterswijk who relocated to the US of A.
The paper that i found https://www.oudwinterswijk.nl/emigratie/8-bestemmingen/verenigde-staten/verenigde-staten/ is a wonderful source for me to go out and find these persons and families.
WR members in the US and Canada pick up what happened to these people after migrating abroad. This is the kind of collaboration that i am looking for.
Thanks, Ron. woepwoep 00:32, 27 April 2021 (UTC)
My impression is that the vast majority of people are only interested in their ancestors, even if they demonstrate good research practices. How to justify bypassing research you think is needed on your own ancestors to find somebody else's? The people that work on anybody tend to have an area of expertise, and typically they construct projects of their own making to keep them busy, so are generally occupied. I think one of the challenges is 1) notifying people with an appropriate research expertise that specific help is needed, and 2) convincing them to drop what they are doing to look into it. Alternately, you could attract outside people with appropriate research interests and get them to view WeRelate as a good collaboration platform. But unless you change a page I am watching, even if your problem is in my wheelhouse, I am not likely to be aware of it. Even if I learn of it, I may not investigate, because I have other goals I am trying to meet (as meaningless as my goals may seem to someone else). --Jrich 02:19, 27 April 2021 (UTC)

Hi. There are a number of contributors with interest in Dutch immigrants to the U.S., as evidenced by the Dutch immigrants to the United States category. You might want to reach out directly to the users watching this category to see what interest they would have in collaborating with you.--DataAnalyst 14:39, 27 April 2021 (UTC)

I believe if you precede Category with a colon, the internal link will work. Category:Dutch immigrants to the United States. --Jrich 20:21, 27 April 2021 (UTC)
Thanks--DataAnalyst 20:55, 27 April 2021 (UTC)
My point is that i actively search for a combination of Place Winterswijk and Pages Unwatched. woepwoep 17:40, 27 April 2021 (UTC)

For this type of project; might I suggest searching other database sites? For example, these links will keep a "pack" busy for quite some time!

A search for burial in USA might yield some persons where place of death is not known. Using the "exact match" keeps result set to those that are interesting. Of course; other sites might also prove useful if they have functionality for this type of search. Convincing researchers you find on other sites that they should contribute here might be challenging. Good luck!--fbax.ca 15:46, 27 April 2021 (UTC)


I have always appreciated very much the input from others on this site, especially the people with more expertise/information about a particular geographic area.--Diane Hosler 17:45, 27 April 2021 (UTC)


Hi all,

Even if i don't comment on your reply, please understand that i do appreciate your response.

User Beatrijs responds by editing one single person and let me introduce the whole family to WR. That is what i was looking for. Someone to work with, someone who shows me new directions. Even if it is outside the area that i was looking at (in this case: Neede)--woepwoep 02:17, 16 May 2021 (UTC)


Transcription of old record (primarliy English language specific) [4 June 2021]

In colonial US records, the letter 's' was often written in a style that looked liked a 'f'. But the writers thought they were writing a 's'. My opinion is that this 'f' looking character should be transcribed as 's' to reflect the intent rather than the mere appearance. I notice some people have changed some records that used 's' to 'f', probably at the expense of destroying the matchability of the actual spelling.

There are other similar issues, but they are more ambiguous. 'j' used to be written as 'i' (beniamin instead of benjamin), but the colonial writers meant to write a i (see Indiana Jones and the Last Crusade). Same with 'v' versus 'u'. There is appearance, intent, and matching to modern spelling as possible factors here. Appearance adds the least amount of assumption by the transcriber, but as indicated may make matching both within and from without (i.e., google search engine) difficult.

A third related issue is that adding a bunch of markup language, like Oct<sup>r</sup>, instead of Oct'r, but this markup does not cut and paste. So, at what point is this counter-productive? One argument for doing the markup is to show the information is based on an authentic record, but what is delivered by cut and paste does not have the formatting and may be confusing if viewed out of context.

Probably a policy indicating the general preference for handling these transcription issues would be helpful? --Jrich 02:47, 4 June 2021 (UTC)


"S" written as "f" does not only appear in US colonial records. It can be just as prevalent in British records right into the 19th century. It was common in printed books and newspapers as well as in handwritten documents. We ought to consider this variation in the same way that we accept differences in dialect when listening to speech. --Goldenoldie 07:40, 4 June 2021 (UTC)

Not sure what this analogy to sounds tells us? We don't have any WeRelate policies about dialects? If there is a HTML character entity (e.g., £) that looks like an 'f' but gets sorted and matches to an 's' I would use that but unaware of such a character. --Jrich 13:23, 4 June 2021 (UTC)

The long s is orthographically distinct from f (https://en.wikipedia.org/wiki/Long_s), and has a unicode character (U+017F, rendered as ſ). At least on a Mac, it cuts and pastes just fine. But I don't know how it would sort... -- Bruce Kendall 21:13, 4 June 2021 (UTC)

So I believe that is entered "&#x017F;" giving "ſ". --Jrich 02:13, 5 June 2021 (UTC)

Family:John Drayton and Phillippa d'ARDERNE (1) [23 June 2021]

Is there someone within WeRelate with sufficient interest and knowledge of mediavel English genealogy who could sort out this family? According to the record that I came upon this morning, the couple were married more than 30 years before they were born. Their places of birth and death are parishes to be found in counties all over England. Once their daughter, Katherine, marries Henry Greene the line stays in parishes relatively close together in Northamptonshire, but no sources are provided for several generations. I get the feeling that the original contributor got his/her notes completely mixed up and copied dates of birth and death for parents from those of their children.

The family seat is Drayton House which still exists in the parish of Lowick on the eastern side of Northamptonshire, but there is another Drayton, a suburb of Daventry, 27 miles away. I am in the midst of tying Drayton House to Lowick in our database. There has never been a link up to now.

The family and Drayton House are documented in The Victoria County History of Northamptonshire and A genealogical and heraldic dictionary of the landed gentry of Great Britain and Ireland, Volume 2. Sir Bernard Burke, 1863 (Second reference from Wikipedia, not consulted).--Goldenoldie 07:00, 23 June 2021 (UTC)

I'm no expert in this area, but I added one source that helped to clear up some of the date issues on the surrounding pages (it's a start). I'll leave the geography to your expertise. Best Wishes, --cos1776 12:09, 23 June 2021 (UTC)

Did you see the note in the Wikipedia article on Drayton House that the family "of Drayton" started with Aubrey de Vere in the late 11th century? But thanks for looking up that old tome. This house just keeps atlases and maps.

I wonder if any those early contributors are still around?--Goldenoldie 19:06, 23 June 2021 (UTC)


Sources index [5 July 2021]

The July challenge on the Home Page

"fix as many pages as possible where there is an event before the birth/christening date"

interested me, but I don't feel I have time to compete. However, I just came across a series of entries made by one user in 2007 where more than one possibility of marriage date or birth date was provided because day and month could have been reversed in his/her source (obviously not an original one; the dates were in the 18th century).

I was successful in finding a firm marriage date by searching out the couple on Ancestry. I copied Ancestry's generalized source name "Devon, England, Extracted Church of England Parish Records" back to a WeRelate source box, only to find that Ancestry's title was not listed (it came out red). The contributor had provided the name of the parish (fairly small), so I looked for that in the WR index, but the index of 205,000 possibilities is not alphabetically sorted, even after filtering for Devon places only. I ended up inspecting the four sources listed for the parish under "What links here" and selecting the most logical one.

If we want users to source their information, shouldn't we make it easier?--Goldenoldie 14:43, 5 July 2021 (UTC)

I agree that the source system is extremely hard to use well, and has been for years. I believe, for example, that the system needs to recognize that, at best, the user may know what is on the title page, and so the system needs to provide source pages, or searching algorithms, that only require that knowledge, and not knowledge about other editions, geographic naming, etc. Instead there has been an effort to combine basically equivalent sources into single pages that then don't match the information found on the title page of either, leaving the user confused. Alternate approaches are limited by the flat name space. More hierarchy needed to be designed in, e.g., have a page for parish record, then subpage for various transcripts and copies and extracts and original, possibly each with different title pages. For books, there needed to be some better handling of collections where each volume may their own title but also be known as a volume within a collection. And article sources needs change, to deal with reprints (some have corrections added, some have different page numbers) and less conflict with book titles. A lot could be done to improve census sources. I would like to see drop down lists for the source fields like we have for date and place that reflect the most recent used values in each field, because my browser's autofill treats source S1 as a different beast than source S2 so my autofill on S1 doesn't help if I use that same source in S2 on a different page.
If you compare WeRelate to Wikipedia, there is no dictionary of sources in wikipedia. Every thing is basically free form. So WeRelate's scheme is more ambitious.
Originally WeRelate's sources pages were created by copying both the familysearch catalog and ancestry. Many of these have been combined where they overlap. Further those two repositories have not been shy about renaming, changing and adding to their collections. So databases on those repositories often don't match a source page.
Knowing how much effort went into implementing the switch to geographical style source names, etc., that went on for months, surely now, there is nowhere near the resources to undertake much change. The scope of the system is vast, dwarfing the number of users.
I don't think there is going to be much system-wide improvement for these various reasons.
In the end, the goal is to provide the reader enough information to find the source and verify it if they wish. In the above situation, if I can find the posted source, I might create a source page or use a "citation-only" citation. If I am unable to find or access the cited source, I might try to find an equivalent source and verify it provides equivalent information, then replace the citation to the equivalent one. Academically, replacing a citation of an abstract with a citation of the actual original, without verifying the original contains the information attributed, is not exactly correct, and it may be better to leave the original poor citation unchanged. There are many cases where such abstracts contain mistranscriptions which could cause the reader to waste time searching the original for something that is not there. --Jrich 15:56, 5 July 2021 (UTC)

Nearing 30,000 entries [27 July 2021]

hi all,

as some of you know, i enter by hand one at a time. now nearing 30K people

current count is 29196

-)

Ron woepwoep 07:38, 15 July 2021 (UTC)


Wow! That's impressive. Is that the number of new pages you have created? How did you determine that number? I messed around with Special:Contributions but couldn't limit it to newly created pages. --Trentf 20:54, 22 July 2021 (UTC)

yes indeed Contributions. not all of them are newly created, i also check current info and add from Geldersarchief.nl
thx Ron. woepwoep 07:56, 25 July 2021 (UTC)
How do we find number of contributions? --fbax.ca 14:53, 25 July 2021 (UTC)
From the top menu List / People
woepwoep 06:50, 26 July 2021 (UTC)
Ah, I didn't know about that page! Though that only seems to show pages on our watchlist, which, in my case, includes a bunch that I never edited (i.e. ancestors who others added). It would be nice to be able to filter that list by pages edited or added. Regardless, my count is 1764, which is thoroughly dwarfed by your accomplishment! --Trentf 15:17, 26 July 2021 (UTC)
Yes it is not 100%. I only watch what i edit, or what i looked at but could not disapprove of nor add info to, e.g. old data.
Best regards, Ron woepwoep 21:29, 26 July 2021 (UTC)
Trentf, you can list your watchlist people on that page according to whether they appear in any of your trees, specific tree or trees, or "No Tree". If you have tree assignments related to whether you added or edited pages, then you can filter as you mentioned. --robert.shaw 21:24, 27 July 2021 (UTC)

Plastified map of Winterswijk area 1036-1300s [18 July 2021]

hi all,

yesterday i was in a place just outside Winterswijk
i met someone who has created a plastified map of the Winterswijk area.

all the mentioned places on this map are in the original notation and their date is from when they were first mentioned.
so for example Ruurlo is called Roderlo.

the map is from long before there were nations like the Netherlands or Germany.

Just a tip for those interested in buying an item.
the price is 6 euros. for sale in the restaurant

thx, Ron.
woepwoep 08:22, 18 July 2021 (UTC)


Living people [7 October 2021]

Hi everyone,

We need to be careful about not posting living people on WeRelate. No one likes to find vital information about themselves or their living parents/grandparents online unless they authorized it. To this end, we are tightening up our edit rules. Specifically, if someone has a birth year less than 110 years ago, they must have one of the following:

  • a valid death or burial date (not in the future, which is no longer considered valid) that doesn’t use the "aft" or "est" modifier (the latter is sometimes used when people assume someone is dead),
  • "(in infancy)" or "(young)" in the death date field,
  • the FamousLivingPersonException template in the death description field.

Please feel free to comment.--Dallan 21:43, 4 August 2021 (UTC)

  • I find this to be a quite reasonable policy, myself. --ceyockey 23:33, 7 October 2021 (UTC)

There are several (many?) jurisdictions that publish birth certificates for persons born less than 110 years ago. Why is that information not allowed here? —fbax.ca 22:02, 4 August 2021 (UTC)

  • It is a matter of the policy of this particular site, speaking from a non-authoritative point of view. --ceyockey 23:31, 7 October 2021 (UTC)

I recently came across a couple of people who had lived in the 18th century, but had baptisms dates 1925. The new rules stopped me from completing edits to places, etc. I realized these were LDS baptisms and had to adjust the wording to explain this.--Goldenoldie 02:22, 5 August 2021 (UTC)

You can delete LDS baptisms. I believe it was decided a long time ago that they aren't relevant on WeRelate.--DataAnalyst 03:00, 5 August 2021 (UTC)
Agreed, the LDS baptisms can happen well after the death of the person; see https://www.churchofjesuschrist.org/study/manual/gospel-topics/baptisms-for-the-dead . --ceyockey 23:31, 7 October 2021 (UTC)

The 1940 United States Census is available on numerous websites and includes data about many persons less than 110 years old. Data about these living persons is allowed on those sites; but not WeRelate?--fbax.ca 12:07, 5 August 2021 (UTC)

WeRelate doesn't allow pages for living people for privacy reasons. If you allow a page, it could include the complete birth date and place (which the census data doesn't have). Furthermore, it is a place people can post personal information such as divorces, miscarriages, job failures, etc. that living people might not want easily available and searchable. There is no way to police this once you allow pages for living people.
WeRelate is committed to protecting privacy. It is common practice in publicly available family trees not to display data for living people and WeRelate follows suit. This has been WeRelate's policy for a long time, so no one should be surprised about this restriction. The policy hasn't changed. It is only being enforced more rigorously than before.
If you are looking for a site where you can share information on living people with close family members, there are other places that can be done. WeRelate isn't (and won't ever be) designed for that. It is a site for collaboration on research on deceased people to avoid having multiple versions of genealogical information, and to work towards the best information we can put together collectively.
A question has been raised recently about what the cutoff age should be. WeRelate chose 110 years, as did FamilySearch Family Tree - again, a common cutoff age. Alberta, Canada has chosen 120 years for publishing birth VR indexes, so we are not the most restrictive site. From a coding point of view, there is no appetite to have different cutoff ages for different countries. For one thing, 30% of pages have no indication of country. Again, just because a government chooses to publish birth dates after 100 years, that doesn't provide a platform for publishing all sorts of other personal information about the person, while a WeRelate page does.--DataAnalyst 13:04, 5 August 2021 (UTC)

[20 August 2021]

I don't usually share the problems I come across with the geographical idiosyncracies that I find in WeRelate, but I just came across a real humdinger. There are eight real places in Devon, England, with "Buckland" as part of their name and....under "inhabited places" I have found a place called, simply, "Buckland". There are 13 families and 15 persons to be put in their proper places.

I haven't started the inspection yet, but the surname that predominates is Drake and that gives me a clue who the earliest ancestor will be. I'll be bowling along.--Goldenoldie 19:01, 19 August 2021 (UTC)

Apologies for duplication. Forgot to add the title the first time. BTW. Job done.


Places: a problem [19 August 2021]

I don't usually share the problems I come across with the geographical idiosyncracies that I find in WeRelate, but I just came across a real humdinger. There are eight real places in Devon, England, with "Buckland" as part of their name and....under "inhabited places" I have found a place called, simply, "Buckland". There are 13 families and 15 persons to be put in their proper places.

I haven't started the inspection yet, but the surname that predominates is Drake and that gives me a clue who the earliest ancestor will be. I'll be bowling along.--Goldenoldie 19:01, 19 August 2021 (UTC)--Goldenoldie 19:03, 19 August 2021 (UTC)


Enhancements to GEDCOM upload [27 August 2021]


Edit Dates

For all GEDCOMs uploaded 26 Aug 2021 or later:

  • there is an error message for each date that cannot be interpreted
  • there is an alert for each date that requires "significant" interpretation (e.g., 25/06/1875, BET 23 and 26 OCT 1850, 1820-1830)

Note that errors reduce the likelihood that the user will be allowed to import the GEDCOM to create WeRelate pages. This prevents users from adding a significant number of invalid dates to WeRelate through GEDCOMs.

Alerts don't affect the likelihood that the user will be allowed to import the GEDCOM. However, the user must click on each alert before they are allowed to import the GEDCOM. This may slow users down when reviewing GEDCOMs, but it protects against an accidental misinterpretation of intent (e.g., 1820-1830 could mean "Bet 1820 and 1830" or "From 1820-1830", which are not the same thing).

Note that the uploader can interpret dates with months in English, French, Spanish, Dutch, German, and Norwegian. However, it doesn't necessarily interpret all the modifiers (e.g., "abt") in those languages. If you need additional language support, please leave a message here.


Other Enhancements [28 August 2021]

In addition to the date edits, the GEDCOM uploader was enhanced to:

  • import the following event types with the correct event type (previously they were imported as "Other" with the type appended to the description field):
    • Citizenship
    • Employment
    • Funeral
    • Illness
    • Living
    • Obituary
    • Pension
    • Stillborn
    • Marriage Notice
    • DNA
    • Adult Christening as Baptism
    • Bas Mitzvah as Bat Mitzvah
  • ignore the _SDATE tag (used by at least one desktop package for a Sort Date) (previously, this tag was imported as a Secondary Date in the event description field)

These changes don't affect GEDCOMs uploaded prior to 26 Aug 2021.--DataAnalyst 15:03, 26 August 2021 (UTC)

I like to think that many members appreciate your work.
Let me appreciate you work by expressing
Thank you Janet !!!
Warmest regards, Ron.
woepwoep 08:45, 28 August 2021 (UTC)

Stenern, Bocholt, ..., Germany [31 August 2021]

hi all,

i found a record of someone born in Stenern. this is a suburb of Bocholt, Germany which in turn is a part of Kreis (community) of Borken.

so now i have Stenern, Bocholt, Westfalen, Preussen, Germany. which is one step beyond the max places

question: what to do?

i would like for future reference address the Stenern place as a redirect to Bocholt. please advise.

thx Ron woepwoep 05:34, 31 August 2021 (UTC)


Keppel [12 October 2021]

hi all,

i have a question re https://nl.wikipedia.org/wiki/Keppel_(gemeente)

how to add this municipality (gemeente) which no longer existed in the year 1900 ?

example Johan Bitters

thx Ron woepwoep 04:32, 24 September 2021 (UTC)


Usually I attach the municipality to the one that it joined or that replaced it with a #redirect. Then I make a note in the new [[Place: that it covers the former place. When you use the former municipality you can now describe it in a person's record as:
new town, state, country|old town, state, country--Goldenoldie 08:46, 24 September 2021 (UTC)

thx ! woepwoep 11:46, 24 September 2021 (UTC)

FYI related -- back in 2012 there was a question posed and briefly discussed about ghost towns: See >> https://www.werelate.org/wiki/WeRelate_talk:Support/2012#Quandary_about_Manlius_Township.2C._Allegan_County.2C_Michigan_.5B28_January_2012.5D . --ceyockey 23:24, 7 October 2021 (UTC)

wonderful ! to me, your post pointing at previous knowledge is key for me to what genealogy really is !
thank you, Ron woepwoep 03:51, 8 October 2021 (UTC)

We talked about Keppel 5 years ago here and the solutions suggested were similar. I think it would make perfect sense to have both 'Laag-Keppel, Hummelo en Keppel, Gelderland, Netherlands' (as Dorp) and 'Keppel, Hummelo en Keppel, Gelderland, Netherlands' (as Voormalige gemeente). To anticipate your next question, there is an explicit provision in the policies that source pages may use 3-part names with voormalige gemeente, so a page 'Keppel, Gelderland, Netherlands. Burgerlijke Stand' would be perfectly fine. Shall I create these pages? --pkeegstra 12:38, 9 October 2021 (UTC)

yes please !

OK, I can do that. Incidentally, I had the same problem in Zeeland a few weeks ago. Before there was a gemeente Rilland-Bath there was a gemeente Rilland (before 1878), but now Rilland is hard-linked to Rilland-Bath so it cannot be expressed as a voormalige gemeente of its own. (Bath exists separately, but not Rilland.) --pkeegstra 10:51, 10 October 2021 (UTC)

Place pages exist for Keppel and for Rilland, and each has associated Bevolkingsregister and Burgerlijke Stand. Ron, I edited the page for Johan Bitters as an example. --pkeegstra 17:43, 11 October 2021 (UTC)

Thank you ! woepwoep 08:13, 12 October 2021 (UTC)

Technical problems [26 November 2021]

Thanks for your patience during the technical issues the past few days. Dallan has been working to stabilize the site since Tuesday, when he blocked some crawlers that were overwhelming the site. As of right now, the site is working normally but if the server goes down again, Dallan will continue to investigate the root cause.--DataAnalyst 14:44, 14 October 2021 (UTC)

the message in my case is "504 Gateway Time-out"
woepwoep 16:41, 14 October 2021 (UTC)

and also in my case --Beatrijs 01:28, 15 October 2021 (UTC) + --Beatrijs 05:16, 25 November 2021 (UTC)


Thanks for the update. --GayelKnott 20:26, 14 October 2021 (UTC)

Search server should be back up now.—Dallan 05:39, 25 November 2021 (UTC)

Thanks very much for your help, Dallan! --Beatrijs 23:30, 26 November 2021 (UTC)

Also, the add person function is also working, thanks Dallan :) Jim- Delijim


1921 Census for England and Wales [29 October 2021]

This will be available on FindMyPast from 6 Jan 2022. It may fill up some empty spaces for you. /cheers, --Goldenoldie 11:45, 29 October 2021 (UTC)


WeRelate will require invalid dates to be fixed [9 November 2021]

I just asked Dallan to implement a code change that will require users to fix invalid dates (dates that cannot be parsed or that fail the date edit). You will no longer be able to manually create a page with an invalid date, and if you edit an existing page, you will be required to correct any invalid dates before saving. (Due to the way the GEDCOM uploader is written, it will still be possible for invalid dates to be uploaded, but a file with too many invalid dates will be rejected.)

Note: Just under 1% of existing Person/Family pages have one or more invalid dates (about .7% of all dates are invalid). Many of these are things other than dates in the date field (e.g., social security numbers, places, descriptions) that should either be moved to the description field or removed entirely. Note that if a person died as an infant but the date isn't known, you can enter (in infancy). If the person died young (i.e., before age 20) and the date isn't known, you can enter (young).

Another code change being implemented is to warn users of events out of order (e.g., death before birth). The warning will show up only if you edit an existing page with events out of order or if you select to preview your edits. You don't have to fix this problem, as there are times when sources conflict and you don't know which date is correct. However, this message should help to find typos such as 1853 when 1953 was intended.

Please let me know (here or in Support or on my Talk page) if you encounter any issues with these changes. Thanks--DataAnalyst 23:28, 6 November 2021 (UTC)


Thanks for these improvements. --ceyockey 00:35, 7 November 2021 (UTC)

You're welcome.--DataAnalyst 02:02, 7 November 2021 (UTC)

The change has been implemented.--DataAnalyst 02:02, 7 November 2021 (UTC)


Once again you're doing a wonderful job Janet. I think it is amazing how only a handful of people - including you, Dallan, jrm, to name a few - inspire us all here on WR to collaborate on creating one single page for every person who ever lived on this planet earth. Warmest regards, Ron woepwoep 03:21, 9 November 2021 (UTC)


change to order in Event Type dropdown list [13 November 2021]

When you select an event type for a person from the dropdown list, the event types Estate Inventory and Estate Settlement are listed in the African American sub-list. There is no reason for this. I plan to move these 2 event types to the main list, in alphabetical order. If anyone knows of a reason NOT to do this, please let me know. Thanks.--DataAnalyst 21:45, 13 November 2021 (UTC)


Periodicals that change name over time [4 December 2021]

This is mostly related to newspapers, which can change their name many times over the years, splitting, merging, succeeding, and ending - then restarting. A key resource for finding the "lineage" of a newspaper is Repository:Chronicling America Historic American Newspapers; for instance, you can trace back from here for one local newspaper > https://chroniclingamerica.loc.gov/lccn/sn96071070/ .

The question here is like the one for Book editions - how do we handle newspapers that change name or content over time?

My current thinking is that one newspaper source page should include all editions that are linearly related to one another, or closely inter-related.

Taking the example above as a start, there is Source:Herald & Review (Decatur, Macon, Illinois, United States). According to the Chronicling site, this title began in 1989 and was preceded by a single paper, The Decatur Herald & Review, for one year. This title was preceded by The Herald & Review, running from 1982 to 1988; which was preceded by The Morning Herald & Review, running from 1980 to 1982.

Looking at the predecessor to The Morning Herald & Review, things get a bit complicated. The direct predecessor is listed as The Decatur Herald, a long running paper from 1899 to 1980; there are earlier preceding titles, but I'll stop there. However, there are several "related" papers to The Morning Herald & Review: The Decatur Herald & Review in 1980; The Evening Decatur Herald & Review, also running only in 1980; and The Evening Herald & Review, running from 1980 to 1982.

This would be my suggestion based on this relatively simple history (compared to some) would be to have three source records:

Now, this seems complicated, and an alternative could be to have a single source that covers all of these titles, but there is a distinct separation between the paper starting in 1899 and the current title starting in 1989, 90 years later.

This might have been discussed elsewhere, but I didn't find it when looking before writing this.

Thanks for your thoughts. --ceyockey 17:09, 25 November 2021 (UTC)

First, thank you so much for taking on the effort to clean up some of the Source pages. Second, would definitely support having multiple entries for each title, as outlined above. Most of us are not going to look up the lineage of a newspaper when entering it as a source, so the multiple entries would be created in any event, and your suggested approach would keep everything cleaner in the end. --GayelKnott 17:43, 29 November 2021 (UTC)
Thanks for the support User:GayelKnott. --ceyockey 12:56, 4 December 2021 (UTC)

New ads [14 December 2021]

Ad revenue has been down lately so I'm experimenting with letting google place ads that it believes will increase revenue to see if that will help. As always, a $20 donation will remove the ads for a year.--Dallan 00:09, 5 December 2021 (UTC)

How do ads generate revenue? Does it require click on ad; or is disable ad-blocker sufficient? --fbax.ca 13:26, 13 December 2021 (UTC)
Ads require clicks to generate revenue. However, it's against google's terms for me to encourage people to click on the ads.--Dallan 05:54, 14 December 2021 (UTC)

Devon parish records transcriptions [15 December 2021]

New as of 13 December are Ancestry's transcriptions of parish records for DEVON, England’s 11th most populous of the original ceremonial counties. They were created from Anglican Parish Registers held at the South West Heritage Trust.

Ancestry’s collections are:
Devon, England, Church of England Baptisms, Marriages and Burials, 1538-1812 — 5,701,864 records.
Devon, England, Church of England Births and Baptisms, 1813-1920 — 2,450,290 records.
Devon, England, Church of England Marriages and Banns, 1754-1920 — 1,080,999 records.
Devon, England, Church of England Deaths and Burials, 1813-1920 — 536,763 records.

NOTE: Ancestry has no images of the original records. Images are available at Findmypast and in a somewhat limited collection at FamilySearch.

This comes from one of my favourite daily blogs: Anglo Celtic Connections. I have an idea a similar notice was made for SOMERSET parish registers a month or two back.--Goldenoldie 15:30, 15 December 2021 (UTC)

Thanks for letting us know! And Merry Christmas and Happy New Year!--DataAnalyst 16:28, 15 December 2021 (UTC)

Proofreading of surname list needed [31 January 2022]

Hello - I've transcribed surnames from three source indices and it would be useful to have another set of eyes review the transcription to correct errors via proofreading. The three sources are:

1. Source:Biographical Record of Whiteside County, Illinois

got as far as Hunter. J's, K's and first part of L's are missing. Let me know when you have added them and I will continue to proofread from there--DataAnalyst 22:21, 18 December 2021 (UTC)
I added in a missing set of 15 surnames - I must have skipped the end of one of the index columns. Thanks. --ceyockey 18:57, 19 December 2021 (UTC)
Proofreading complete (and marked as such on the Source page). I can tackle the others over the next few weeks if someone else doesn't get to them first.--DataAnalyst 19:26, 19 December 2021 (UTC)
Excellent - thanks. This helps to say "yes, this is an ok place to put a request like this" :-) --ceyockey 02:37, 25 December 2021 (UTC)

2. Source:Centennial Biographical History of Crawford County, Ohio

I proofread this one--DataAnalyst 23:41, 26 December 2021 (UTC)

3. Source:Davis, William W. History of Whiteside County, Illinois, from Its Earliest Settlement to 1908

I proofread this one today--DataAnalyst 23:55, 3 January 2022 (UTC)

I've put on each source page a note about the surname list not yet being proofread. If someone does the proofreading, then suggest that they replace the 'not proofread' note with one indicating that the surname list has been proofread and the date it was completed. Thanks for considering this ... or directing me to a better place to request a second set of eyes like this. --ceyockey 14:41, 17 December 2021 (UTC)


New feature added to "rename" function [17 December 2021]

As of today, there is a new button when you select the "Rename" menu item. If you are renaming a person or family page, and it has dates and none of the dates are before 1550, a "Standardize title" button will appear. If you click this button, WeRelate will populate the "new title" field with the WeRelate standard title. You then have to click the "Rename page" to complete the rename.

This is useful if you have edited a person's name and want the title to reflect the new name. You no longer have to worry about introducing new typos in the page title. It is also useful for users who aren't familiar with WeRelate page title standards.

Note: I haven't updated the Help yet - it might be a year or more before I get around to that.

To keep on top of upcoming and completed changes, please watch WeRelate:Roadmap--DataAnalyst 14:34, 17 December 2021 (UTC)


Thanks. So this reads content from the page to populate the new title, correct? --ceyockey 14:42, 17 December 2021 (UTC)

P.S. just used it - nice. --ceyockey 14:45, 17 December 2021 (UTC)


Three million persons! [1 January 2022]

I notice there are 3001680 person pages in WeRelate! Were there 3 million before midnight UTC?--fbax.ca 23:58, 1 January 2022 (UTC)

We hit 3,000,000 person pages about 16 Dec 2021. I updated the Home page 17 Dec.--DataAnalyst 02:12, 2 January 2022 (UTC)

More than one source [30 January 2022]

I, like many people, have a long-term project I am working on. For the last 24 hours, I have responded to several errors, and have not made any progress on my long-term project.

Big picture, I want to help document genealogy in an academic manner, and if I can do this in a way that is helpful to active users, that may be a better use of my time than my long-term project. So this is not de facto a bad thing. But it may have been unnecessary in these cases.

All the cases involved citing single marginal sources without confirming them, and all resulted in errors.

One involved an adopted daughter represented as a natural daughter, clearly wrong if birth, death or other records were inspected. But the poster relied on a single census record, and the coincidence of that single instant of time was used to presume the incorrect relationship.
One case used an erroneous record that misidentified parents without ever trying to confirm the information with the many other available record, including census records.
Two of the cases involved misidentifying the maiden name of a wife because only post-marriage records were used with no attempt to search for records prior to marriage, which in both cases showed the supposed maiden name was actually a middle name.
One involved invalid assumptions posted to WeRelate because the poster relied solely on a secondary source that did not show one of the marriages for the person in question, and the poster did not pursue the primary records that informed that secondary source, and further, apparently misread the secondary source.

All these problems were relatively easy to spot, three of them brought to my attention because their pages looked under-documented when shown in search results, a fourth uncovered working on one of the others, and a fifth suggesting more work was needed because only a secondary source was cited. So, with respect, I offer some suggestions:

How you know something is more important than what you know. Try to use good sources. Try to confirm facts with independent sources.
Specialize. Focus on a limited area so you can develop an expertise in history and a familiarity with available sources.
Don't be afraid to leave something unrepresented in WeRelate if you aren't pretty sure it is correct.

Sorry to be tiresome about this. Thanks, --Jrich 04:09, 16 January 2022 (UTC)


Hear hear! In working on pages of possibly living people, I've seen several families that appear to have been constructed almost exclusively from obituaries. In some cases, relationships have been misinterpreted, especially in terms of children vs. step-children and even siblings vs. in-laws.

And then I'll turn around and admit to being one of the people who have relied on a single source (usually online trees) in my project to eliminate pages for living people from WeRelate. I've done this to fast-track finding death dates for people born in the last 110 years so that their pages don't have to be deleted, but I'm well aware that I'm building a backlog of data that needs to be verified and properly sourced (if possible - in many cases it is impossible to find death records online for people who died in the last 50 years or so). Talk about long-term projects....--DataAnalyst 15:01, 16 January 2022 (UTC)

You are doing a great job, Janet !
woepwoep 15:32, 16 January 2022 (UTC)
Thanks for the support. I know I've made mistakes and it will take a while to find and fix them all. It's a balancing act between several priorities and I've chosen to work hard at preserving pages where I can, while trying to avoid being fooled by bad research or making my own poor assumptions. Some days are better than others!
Maybe now is the time to quote a potholder my husband and I picked up on our travels a few decades ago, because I certainly think of it frequently when I worry about the mistakes I know I must be making:
Wer wenig arbeitet macht wenig Fehler
Wer viel arbeitet macht viele Fehler
Wer keine Fehler macht ist ein fauler Hund
rough translation:
Whoever works a bit makes a few mistakes
Whoever works a lot makes a lot of mistakes
Whoever doesn't make mistakes is a lazy dog
 :) --DataAnalyst 16:23, 16 January 2022 (UTC)
I like your saying. But methodology also has an impact on the numbers of errors. Obviously cleaning up the same type of errors over and over in some of the old postings gets frustrating, especially knowing in many cases the poster is not active, and getting no feedback (i.e., notifications of changes) to help them learn and be a more valuable contributor in the future. --Jrich 21:10, 16 January 2022 (UTC)

Meeting our Unified Tree goal [31 January 2022]

If you've read the Home page and the linked Pando for genealogy page, you'll know that the original goal of WeRelate was to build a single unified tree. I just did some analysis of WeRelate pages and discovered that we are meeting that goal better than I had expected.

A full 80% of Person pages in WeRelate are connected into one large tree (2,410,703 Person pages as of last night). As with all genealogies, there are bound to be errors, and some people are in the wrong family and thus shouldn't be part of this big tree. However, this is still pretty amazing.

Other stats:

  • Another 8% of Person pages are in 790 additional trees, each of which has more than 100 Person pages.
  • There are 18,073 "trees" which have only 1 or 2 Person pages (and at least 1 Family page) apiece. This accounts for 1% of Person pages.
  • Just over 1% of Person pages are completely standalone - no links to Family pages (including through the Inlaws and Grandparents templates).

I thought that some others might be interested in these statistics. Let me know if you have questions or thoughts.--DataAnalyst 22:19, 17 January 2022 (UTC)

That's amazing! Thank you for doing this, and for all the work you've been doing to improve WeRelate!--Dallan 02:03, 18 January 2022 (UTC)
80+8+1+1=90 Where are the other 10% of Person pages? --fbax.ca 02:25, 18 January 2022 (UTC)
In 27,540 separate trees that each have between 3 and 100 Person pages (not mentioned in the stats above).--DataAnalyst 02:34, 18 January 2022 (UTC)
That's incredible, very pleased to read it. I have limited time to jump in and do much but am working to connect Australian immigrant families back to countries of origin, and also enter couple / branch information in a small attempt to try to connect in to existing information (or provide future points). Please feel free to highlight any Australian-related content that I can assist with. But for now, I can only join Dallan in thanking you for the work you've been putting in, from the smallest detail to a wider scale. It is very appreciated. --Paula 03:00, 24 January 2022 (UTC)

There are two definitions of "trees" on WeRelate and I'm wondering which is referred to here. One definition is based on actual family-person connectedness. The other definition is based on the clustering of pages within a "tree" that can have multiple independent family-person relationships in it. --ceyockey 20:07, 31 January 2022 (UTC)

I'm referring to connected pages - independent of how individual users cluster pages. The latter were renamed to "My Trees" about a year ago. I know it can be confusing, which is why I renamed user-defined groups to "My Trees".--DataAnalyst 21:49, 31 January 2022 (UTC)

Proofreading request [12 March 2022]

This is a source where the surnames were typed in the source and the list of surnames needs to be proofread:

Proofread 21 Feb 2022--DataAnalyst 02:09, 22 February 2022 (UTC)

This is a source where the surnames were handwritten and transcribed for the surname list

Hi. I started proofreading the first one, but found I had to do a lot of research, not just proofreading. The handwritten indexes are not always decipherable (e.g., "a" vs "o") and sometimes have errors, so it is frequently necessary to go to the actual pages and look at them. Looking in Find A Grave also helps, as I found memorials for several of the people mentioned in the records (and gravestones are generally easier to read than handwriting). I am not prepared to invest this much time on these sources when I have multiple other projects on the go. If you decide to do the necessary research, let me know when you are done and I'd be happy to proofread the results. If not, you should add a note to the pages indicating the work that is still required. Thanks--DataAnalyst 14:43, 12 March 2022 (UTC)

There is a Proofreading section in each indicating "not yet proofread"; if you proofread, please note that in this section. Thanks. --ceyockey 01:41, 2 February 2022 (UTC)


Place categories - Cemeteries [13 February 2022]

It would be useful, in my opinion, to suppress the automated category link additions to source pages that refer to a cemetery place. Example, redlink category for Place:Harris Cemetery, Fayette, Illinois, United StatesSource:Burials in Harris Cemetery in Fayette County Illinois.

And/or articulate a best practice not to create cemetery place categories; they are not intrinsically bad, but will be very sparsely populated if created.

Regards --ceyockey 15:20, 13 February 2022 (UTC)

Many times there has been discussions about red categories. The red goes away as soon as they are created, but I believe it was decided the red categories are still functional. If you click on it you go to a category page skeleton that could be saved. This case was automatically created because the cemetery has a place page and that place was listed in the place field, which seems intuitive enough. So delete the cemetery from the place field on the source, leaving just the town, or click on the red link then edit and save the category with one item in it.
Just as a matter of general practice, I think there is a general overuse of categories, and a danger of over-proliferation of them, making excessive work to manage them. In this case the addition of the category was automatic, but in general, few users are aware of categories as they edit, and so the population of those categories is probably very spotty and incomplete, perhaps often to the point of uselessness. They almost need an administrator to maintain them. But they are generally harmless unless implemented with a template that splashes a gawdy banner on the page. In terms of practices, I think categories should have enough of a definition documented so that any user (i.e., not just the creator) should be able to read that definition and objectively decide if the category is appropriate or not. So a person who lived their whole life in Vermont doesn't end up in a Texas study group category because their grandson moved to Texas (these things have happened). Like our general pages, I don't think there should be any particular ownership of categories, i.e., it should have a general value beyond one person, while trees should be used for personal grouping. --Jrich 17:00, 13 February 2022 (UTC
Is there a category for categories that do not have a definition or definition is ambiguous? I've encountered them here; but did not use them because I was unsure if it was appropriate. --fbax.ca 22:37, 13 February 2022 (UTC)

name variations [14 February 2022]

Where is that page that holds alternate name spellings, nicknames, other variations of names? I tried to find it using Help and have not been successful.--janiejac 15:15, 14 February 2022 (UTC)

This GivenName what you are looking for? --fbax.ca 15:44, 14 February 2022 (UTC)

Not really. What I am looking for - example: Sarah is sometimes called Sally, Mary is sometimes Polly etc. The page allows users to add variations as we find them. Thanks for your interest.--janiejac 16:07, 14 February 2022 (UTC)

If I recall correctly, that method of providing name variants (i.e. manually adding them to a list on a wiki page here) was changed when FamilySearch completed their integration of a name variation database, based on Soundex and user inputs, into the underlying wiki/Search engine code. I think that Dallan was involved with that project at the time, so it was also implemented here at WR. Please forgive me if I am mixing up some of the details - it was quite a while ago - but I think that is basically why we don't need those pages anymore. --cos1776 16:36, 14 February 2022 (UTC)

You are right; it was some time ago that I used that page. And perhaps WeRelate doesn't need the pages anymore, but I do. Just trying to find what may be the actual given name for someone who is recorded as 'Zina'. Whatever her name; it escapes me. That was a good page. Sorry it's gone.--janiejac 17:23, 14 February 2022 (UTC)

Hi, Janie. The page you are looking for is Special:Names. There are a number of computer-generated and Soundex variants for Zina, but none confirmed. --DataAnalyst 17:42, 14 February 2022 (UTC)

Yea! That's it! It's not really gone, just very hard to find. Thank you!!--janiejac 18:30, 14 February 2022 (UTC)


Families to merge? [19 February 2022]

I have a feeling that the following persons and families include a myriad of duplicates.

  • Person:Fry, Thomazine (1)
  • Person:Fry, Thomazine (2)
  • Person:Hill, Benjamin (5) ... Person:Benjamin Hill (5) OK (cey)
  • Person:Hill, James (42) ... Person:James Hill (42) OK (cey)
  • Person:Hill, Judith (3) ... Person:Judith Hill (3) OK (cey)
  • Person:Hill, Mary (85) ... Person:Mary Hill (85) OK (cey)
  • Person:Hill, William (73)
  • Person:Hill, Elizabeth (43) ... Person:Elizabeth Hill (43) OK (cey)
  • Person:Hill, James (41)
  • Person:Hill, Sarah (45) ... Person:Sarah Hill (45) OK (cey)
  • Person:Hill, William (75)
  • Person:Joudain, John (1)
  • Person:Joudain, Judith (1)
  • Person:Jourdain, Mary (1)
  • Person:Jourdain, Silvester (1)
  • Person:Jourdaine, Ignatius (1)
  • Person:Jourdaine, John (2)
  • Person:Jourdaine, Robert (1)
  • Person:Jourdaine, Susan (1)
  • Person:Jurdaine, Ignatius (1)
  • Person:Jurdaine, John (1)
  • Person:Jurdaine, Judith (1) ... Person:Judith Jurdaine (1) OK; added alt names of "Jourdain" and "Jurdain" with sources (cey)
  • Person:Thomazine, Unknown (2)
  • Family:Ignatius Jourdaine and Elizabeth Baskerville (1)
  • Family:Ignatius Jourdaine and Katherine Bodley (1)
  • Family:Ignatius Jurdaine and Thomazine Fry (1)
  • Family:James Hill and Judith Jurdaine (1) ... duplicate (cey)
  • Family:James Hill and Unknown (1) ... merged to Family:James Hill and Judith Jurdaine (1) (cey)
  • Family:James Hill and Judith Joudain (1) ... found not present (cey)
  • Family:James Hill and Judith Jurdaine (1) ... OK (cey)
  • Family:John Joudain and Unknown Thomazine (1)
  • Family:William Hill and Unknown (11)
  • Family:Unknown and Thomazine Fry (1)

The birth and death dates are all in the late 1500s and 1600s and they all lived at least part of their lives in Lyme Regis, Dorset, England. There are no sources that I have found. Details have been provided by at least two contributors back in 2007.

I know there has been a campaign to rid WeRelate of questionnable material, but I don't want to dispose of these entries without someone else's opinion. I don't even want to merge the likely duplicates.

Would someone (possibly someone with access to old sources) have a look at this problem? Thanks, --Goldenoldie 12:22, 18 February 2022 (UTC)

Took a quick look at FamilySearch Books for "Thomazine Fry". There'a a passage that goes "...Judith Jourdain, daughter of (30678) John and (30679) Thomazine (Fry) Jourdaine, born about 1550 in Lyme Regis, Dorsetshire, died there in 1620." The text doesn't seem to appear in WeRelate as a source; it's page (viewer) 48 of 67 of a supplement to "Ancestry of Seth LeMoyne Warner: The first eight generations". This seems consistent with info available via Person:Thomazine_Fry_(1). In other words, I think with some tome diving these can be filled in at least in part. --ceyockey 23:11, 18 February 2022 (UTC)
I've created a source for the text and will proceed to at least address that which I noted above. --ceyockey 18:58, 19 February 2022 (UTC)

Homosexuality in the year 1900 [14 March 2022]

hi all,

when i record a marriage record by -1- clicking a Person: page where this person has attribute: GENDER=FEMALE -2- clicking "Add another spouse & children" and entering the name of the other person (marriages usually go by the couple) -3- now i get a list of both male and female persons

i was born and raised in the NL. Netherlands have been known to welcome gay marriage, but not in the year 1900 ! So until the restrictions on recording marriages here on WR are beyond the year where gay marriages were allowed, i would like to see a list of spouses Fe/Male only where the Person suggested meets the - then demand - of the "opposite" sex.

Hopefully, more and more countries will abolish sex in favour of (fluid) gender. Until then, with the strict rules of WR, i request that when looking for a Person:person's marriage partner, He only shows Shes and Shes only accept Hes.

Thanks, Ron--woepwoep 10:46, 13 March 2022 (UTC)

I understand the request, but in my experience, lots of pages on WeRelate have an incorrect gender designation. Therefore, to meet the goal of ensuring people don't add duplicate pages, it will continue to display all pages that match the search criteria, regardless of gender.--DataAnalyst 14:56, 13 March 2022 (UTC)
Ah so now i understand. Does lots of pages mean more than 50%? woepwoep 15:54, 13 March 2022 (UTC)
Not likely, but of course, we have no way of measuring the number of errors because we can't tell which pages are wrong until we research them. But I know I have found (and fixed) lots.--DataAnalyst 16:33, 13 March 2022 (UTC)

I'm sorry, I don't quite understand the request. I probably glossed over something. When you "Add another spouse & children" the one name is filled in and so when you enter "the name of the other person" in the husband role because Jane Doe would occupy the wife role, don't you get a list of couples, not "list of ... persons"? Say I am looking for Jane Doe, GENDER=FEMALE, then I get a bunch of choices for somebody and Jane Doe, and Jane Doe is the correct role because the name started in that role when the request was built. Is the problem that a name may be assigned to both sexes? Even if I search for a name that is sometimes used for both sexes (in US colonial times, e.g. Experience) if I put it in the Wife's name, that is where the choices show it. It may show names that marginally match Experience (phonetic, soundex, etc.) but it showed none of the Experiences in the other role. Only if I search by putting it in the keyword field, which is a search for those words anywhere on the page (i.e., Family:John Doe in the search box in the upper left hand corner, for example) only then do I see a name in a role other than I intended it. --Jrich 16:36, 13 March 2022 (UTC)

P.S. In search for a Person, it appears that you can add "<gender>M" and "<gender>F" to the keyword field (quotes are part of what you enter) to force a match to one gender or another. --Jrich 16:43, 13 March 2022 (UTC)
I think I understand the request now, you are talking about using the Add Person function after the Family page has been built, and when you do the box comes up with the sex filled in but it apparently gets ignored in the search. So I think the answer above can fix that if you want. It does involve an extra step. However, I also think the policy stated is somewhat arbitrary and non-intuitive since 1) the request actually shows the gender as if it is going to be used as a criteria (parents were removed from an earlier version because it apparently caused people to think add person would generate the parents too, although specifying parents was an effective way to narrow your search and get your desired result to show at the top of the list), and 2) lots of other data is wrong and probably with a greater frequency that the gender field which can play havoc with the weighting of the results. --Jrich 22:02, 13 March 2022 (UTC)

@JRich this is very helpful ! It is exactly what i mean. When i review a family, one daughter gets married. So there pops up the form where i enter her husband's name and the marriage date. Next form shows possible marriages. I select one or press Add. Then the husband's name is in blue. I click on his name, and again, the next form shows possible persons. But in this form, the search criterium "gender=oppositeSex" is not included. So basically this is my request, to add the aforementioned filter (gender=reverseOfOtherGender) to the result list. Thank you, Ron woepwoep 06:08, 14 March 2022 (UTC)

Perhaps a bit of a technical question. What are the wildcard symbols? Could i for example use .gender.M as in regexp searches? woepwoep 06:16, 14 March 2022 (UTC)

Married Names [25 March 2022]

A married name that I had recently added was removed by another user due to WR "common practice". I think they can be helpful with searches, although I know that some users don't like them. Is there an WR "official position" on married names?--jaques1724 02:17, 25 March 2022 (UTC)

You don't need to enter a married name for searching. WeRelate automatically searches on the surname of a woman's husband. The only reason to enter a married name would be if you don't create a family page for that marriage - e.g., if the husband is living or if you don't have his first name or any other info on him and there were no children.
Entering a married name that is redundant with the info on the family page is discouraged. Data redundancy is generally considered to be a poor practice because information can get out of sync (e.g., if you discover an error and correct it only in one place). Even if you know enough to keep data in sync, it is more work to correct an error when there is redundant data.--DataAnalyst 02:42, 25 March 2022 (UTC)
I was the person who remove the married name. Agreed, that if a family record exists that would support married name as a derivative of the family, then it is "redundant". I've added my fair share of married names that given the current search paradigm could be removed, but I've not been hunting those down for extermination. Regards --ceyockey 03:05, 25 March 2022 (UTC)
I have entered married names at times, especially when the woman was well known by her married name, such as for Hannah Duston. There are also cases where the name she went by when married is not trivially obvious, e.g. a woman born Alice Barbara Cromwell married to Dumbkoff might go by either Alice Barbara Dumbkoff or Alice Cromwell Dumbkoff. I don't really endorse having information removed for general reasons like "WR common practice". --robert.shaw 19:37, 25 March 2022 (UTC)
The driving reason is not that it is WR common practice, but the reasons that this WR common practice was established. It is a data design principle based on minimizing data redundancy because such items tend to lead to incomplete edits. For example, if the the husband's page for Alice Barbara Crowell was edited to change her husband's name from Joe Dumbkoff to Joe Duddakoff, how would the editor know that an edit also needed to be made on Alice's page to change her Married Name field? It is not intuitive that each wife would need to have their page edited just because the spelling of the husband's name was changed on the husband's page. Until such time as the computer can be enlisted to automate this feature (if the feature is valuable enough to justify those changes), my opinion is that it is undesirable and likely to cause some (quantity unknown, probably not huge) out-of-sync pages. However, searching seems to work pretty well without the Married Name, so there doesn't seem to be an overly compelling case to do it. Certainly, citation of sources can include enough information from the source's presentation to communicate things like unusual married names, and similar facts. Entering data this way comes with the additional benefit that it would probably only be a factor in exceptional cases, and by putting it in a source citation, you are merely writing what the source says. Since the source would still would say that even if you find out that the source is incorrect, your citation of it would still need to communicate its content honestly. So this is not a blatant error of commission, the way an unchanged Married Name would be. (Obviously, a note calling attention to the error in the source would be a useful addition to the citation). Just my opinion. --Jrich 21:01, 25 March 2022 (UTC)
It would be useful to enshrine the "avoid redundant data" principle somewhere in the documentation as one of several basic tenets. A suitable place might be under the "General" section of the Help:Style guide. I've personally done edits that play toward perceived weaknesses in the search algorithms (and been admonished and have worked on reversing), but realize that this is like in the OpenStreeMap world "editing to the renderer" (you choose tags that look nice when interpreted by a map renderer rather than the correct tags for mapped objects). --ceyockey 23:08, 25 March 2022 (UTC)

Places in West Virginia [29 March 2022]

Just a heads up that many places in West Virginia aren't currently showing up in the place dropdown list. You can still type in the full name and it will be recognized. If you don't want to type in the name, you can search for it and copy the name from the Place page.

Sorry about this - a glitch from making changes to make the site better. This should be fixed within a few days.--DataAnalyst 16:18, 27 March 2022 (UTC)

This issue has been resolved.--DataAnalyst 14:26, 29 March 2022 (UTC)

where to add variant names? [6 April 2022]

Page https://www.werelate.org/wiki/WeRelate:Variant_names_project was last modified 23 June 2015

I found this page when i was editing https://www.werelate.org/w/index.php?title=Surname:Bosche&action=edit

So now i am confused. Where and how to add variants of a surname? Bosker, Bosche, ten Bosscher

Thx Ron woepwoep 03:58, 1 April 2022 (UTC)

Start at that page you found, WeRelate:Variant names project. Click the button labeled "Review name variants". Choose either Given Name or Surname, and fill in the name you're interested in. It will show what is set, and suggested variants that you can okay or exclude, and you can add variants. --robert.shaw 18:06, 1 April 2022 (UTC)
Thank you Robert. I tried variant names project with Given Name Bosche. This is a Dutch name. Variants are Bosker, Bossche, Boschker, te Boscher, ten Bosche. See example here. It seems that the variant names project does not work for Dutch names. Thx Ron woepwoep 18:18, 2 April 2022 (UTC)
Why doesn't it work for Dutch names? I just added the variants you mentioned. "te Boscher" and "ten Bosche" were added as "teboscher" and "tenbosche", which isn't ideal I realize, but I believe they will still be included in search results. Bossche didn't get added because it is a rare name with the same soundex code as Bosche, so it's already included in search results. I'm quite interested in name variants. (I'm actually working with FamilySearch right now on an improved name-variant search that will ultimately incorporate these variants as well.) If there's a problem I'd be interested to hear about it.--Dallan 00:19, 3 April 2022 (UTC)
Thank you Dallan. I will do some more research on this and share my findings. woepwoep 00:22, 3 April 2022 (UTC)
question for you @Dallan. the name "teboscher" is actually "te Boscher" where "te" and "ten" mean "at/at the" and "Boscher" is a place (usually a farm or a small group of farms ... a physical location. So they need to be two words. Thx R. woepwoep 02:00, 3 April 2022 (UTC)
Even though "Te Bosher" appears as "tebosher" on the variants page, the search appears to work correctly. When I search for "Bosche" now, a test person I just added with a given name of "Te Boscher" appears in the search results.--Dallan 04:07, 3 April 2022 (UTC)
Excellent! I will do some more testing. Thx Ron woepwoep 07:22, 3 April 2022 (UTC)

Only now do i see this message:

Variant names mensink has been updated.

The following rare names have the same soundex code, so they will be matched automatically: mensing

@Dallan would it make sense to add the soundex code names, like mensing for mensink, in the confirmed variants column?

Thx Ron woepwoep 07:44, 5 April 2022 (UTC)


The whole variant names project page is not easy to understand.

I have now added the variant Gierking to the given name Geurkens (search box name). Nowhere in the soundex variants column does this variant name appear. Yet when pressing the save button, WR website replies with this message:

geurkens has been updated.

The following rare names have the same soundex code, so they will be matched automatically: gierking


Given name geurkens Enter a givenname or surname to see variants Learn more ( view changes log )


I should have selected surname instead of given name, but the result is not any different. The soundex variant name is not visible until i try to add it as a variant name. woepwoep 08:04, 5 April 2022 (UTC)


I think a key to success here is that when you add or support a variant that you (the everybody you) should add a source comment. I think it would be VERY useful to be able to add source comments to previously created relationships, but this is not part of the current functionality. --ceyockey 20:33, 5 April 2022 (UTC)


What the message is trying to say is that since the name you entered is a rare name that has the same soundex code, it won't be added as a variant because it is *already* included in the search results. All rare names with the same soundex code are included in the search results.

The list of names in the soundex column is just a sample of names with the same soundex code. It isn't meant to be comprehensive. I will update the instructions to make them more clear, thank you.--Dallan 03:24, 7 April 2022 (UTC)


New Data Quality Issues Report! [17 May 2022]

Check it out! WeRelate has a new report of data issues. Here's where you can find issues in your trees, such as typos or children attached to the wrong parents (e.g., born after the mother died). The initial implementation (9 May 2022) lists only errors - other types of issues will be added soon. Be sure to read the Help page..

Thanks so much to Dallan for his patience in helping me with the technical details.--DataAnalyst 15:34, 11 May 2022 (UTC)

Thanks to DataAnalyst for all of the wonderful work she has been doing on WeRelate!--Dallan 04:57, 13 May 2022 (UTC)
  • Looks great. Is this planned to be, in part, a to-do list for people with time on their hands who want to help fixing errors? If so, would be useful to embed this in a standard page so that a talk page can be associated with it where error correction efforts can be recorded? --ceyockey 22:45, 12 May 2022 (UTC)
A regular page wouldn't work because there is no edit capability on the page. However, if volunteers wished to coordinate efforts on a new page (probably a Talk page - it doesn't have to have an associated Article page), I would be happy to add a link to that page at the top of the report. And, yes, volunteer efforts to correct errors across the database would be welcome.--DataAnalyst 23:24, 12 May 2022 (UTC)

Great tool ! Using it now to fix some century typos, e.g. 1917 instead of 1817, where the tool says: Husband older than 125 at marriage. woepwoep 04:42, 13 May 2022 (UTC)


When I selected Watched to limit the list to only pages I watch I get "504 Gateway Time-out". The URL it is trying to process is "https://www.werelate.org/wiki/Special:DataQuality?category=Error&watched=w&limit=50". Worse, all my werelate windows, even simple refreshes of already-display pages, behave the same way for several minutes (5-6). Tabs to other websites and other processes on the computer work fine. BTW,I have a large watchlist. --Jrich 05:30, 13 May 2022 (UTC)

@Jrich i noticed 504 several times yesterday and today. It is imho not related to this feature. When i just leave the tab open and refresh the page some time later, i get the results. Not sure what 504 means. Thx Ron woepwoep 05:37, 13 May 2022 (UTC)
Unfortunately, I am getting the same error message and timeouts from the site as Jrich when I try to run the report on Watched pages. --cos1776 13:04, 13 May 2022 (UTC)
Sigh! It's timing out for me as well. My apologies. I thought I had successfully completed performance testing offline, but I must have got distracted - the tests I ran offline are running too long today. For now, don't select by watchlist. I'll see if there is any way I can make it perform, and if not, I might have to remove that option.
If a query runs for a long time, you will get a 504 timeout message after a minute or so, but the query keeps running in the background. This prevents you from completing other tasks on WeRelate until the query is finished, but it doesn't seem to impact anyone else.--DataAnalyst 16:25, 13 May 2022 (UTC)
Large MyTrees (over 5000 pages) will probably have the same result.--DataAnalyst 17:02, 13 May 2022 (UTC)

Dallan or Janet, can you look into this, please.

Quoting from your instructions: "When you first open the Data Quality Issues page, the list reflects the entire database."

I wish it did. Setting the list to view 500 names at once I only got to the letter G. This would probably be at the 5,000 mark. The same problem occurs on the "What links here" at 2,000". There seems to be some built-in limit that prevents us from checking the whole of extra large databases.

Thanks, --Goldenoldie 10:50, 13 May 2022 (UTC)

Actually, I think it has to do with accented (or alternate alphabet) characters and how they are stored in the database. When you scroll to where the first title displayed is "Garnsey, Patience", you will notice that the last title on the page starts with "Gärtner". I can't explain exactly what is happening, but it appears that it can't find the next record correctly because it treats the "ä" like an "a" - although that doesn't completely explain the issue. At this point, I switched to 20 pages at a time, successfully scrolled and then switched back to 500 pages at a time and was able to keep scrolling to the end of the list.
I think (although I could be wrong) that the problem occurs when either the last title shown or the next title that would be shown (which you can't see) has an accented character or a character from another alphabet. So if you have problems scrolling, switch to a different number of titles at a time and see if that works. The same thing for the "What links here" list, which uses similar code. Not an ideal solution, I know, but I have to work on performance issues before I can investigate this further.--DataAnalyst 18:02, 13 May 2022 (UTC)

Changes were implemented yesterday to improve performance and add functionality. While performance testing was moderately encouraging, I am still unable to get results for my watchlist, and I suspect those of you with large watchlists (150,000+) will also have trouble. I suggest you limit scrolling to 20 issues at a time before selecting the "watched" filter.

I have a couple of additional things to try - one of which would be a marginal improvement, but possibly enough to make a difference, and the other may not pan out at all. I have other responsibilities on my plate so I don't know when I will get around to looking at this again. In the meantime, one way to improve performance is to reduce the list of issues, so I encourage (careful) investigation and correction of issues. Please read the updated Help page.

BTW: The change I made to improve performance also fixed the scrolling issue reported by GoldenOldie. But the same fix can't be applied to the What Links Here page.--DataAnalyst 17:01, 16 May 2022 (UTC)


I had a full and productive day today. Went for a hike, got a load of laundry done, and fixed 2 bugs!

The performance issue has been resolved. The list comes back within a few seconds when I filter on my watchlist. I've still left it limited to 50 pages at a time for now - I'll consider removing that restriction, but I don't think it is urgent. Also, the list stopped working yesterday after I deleted a page on the list. I fixed that bug so it won't do that again.

Let me know if you have any ongoing issues with the Data Quality Issues page.--DataAnalyst 01:40, 18 May 2022 (UTC)