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

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. . . . --Mike^Talk 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. --Mike^Talk 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. --Mike^Talk 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? [18 July 2022]

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. --Mike^Talk 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. --Mike^Talk 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. --Mike^Talk 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. --Mike^Talk 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. --Mike^Talk 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. --Mike^Talk 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)

Hello. I realize this is quite an old thread but I stumbled upon it recently as a new user and found it alarming. As an update: I understand that Dallan and DataAnalyst have rewritten the two functions threatened by the disappearance of Flash.

Some of the comments and complaints were interesting to me (and I should read this very long thread more carefully). I come here after several years on WikiTree. There are many things that I like much better here. To name a few: better organization, the Portals pages, nicer person page format, naming conventions, more data (event/fact) fields on the person pages, linking of sources to data elements.--Julie Kelts 20:02, 18 July 2022 (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.

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)

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)
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)! 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:

You will see:

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

--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! --Mike^Talk 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.) --Mike^Talk 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)

• https://www.werelate.org/w/index.php?title=WeRelate:Watercooler/Archive_2019&redirect=no
• https://www.werelate.org/wiki/WeRelate:Watercooler_talk/Archive_2019

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!

• FamilySearch born Winterswijk death USA - 1020 results
• FamilySearch born Winterswijk residence USA - 698 results

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^r, 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:

• source:The Decatur Herald (Decatur, Macon, Illinois, United States) > with a term of 1899 to 1980
• source:Herald & Review (Decatur, Macon, Illinois, United States) > this would include the current paper, and it's predecessors in a linear succession: The Decatur Herald & Review (1988-1989), The Herald & Review (1982-1988). Also include in here the The Decatur Herald & Review (1980-1980).
• source:The Morning Herald & Review (Decatur, Macon, Illinois, United States) > this would collate several titles: The Morning Herald & Review (1980-1982), The Evening Decautur Herald & Review (1980-1980), and The Evening Herald & Review (1980-1982).

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:

• Source:Portrait and Biographical Album of Whiteside County, Illinois

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

• Source:Fayette, Illinois, United States. Will Execute Record 1879-1908 Volume B
• Source:Fayette, Illinois, United States. Will Record 1859-1894 Volume A
• Source:Fayette, Illinois, United States. Executors' Record 1867-1869 Volume A

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 States → Source: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 [25 February 2023]

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)

In my name books, one has 'Zenia see Xenia' without information. The other has 'Xenia - from the Greek meaning "hospitable one". It is only occasionally found.' --Helen-HWMT 08:00, 25 February 2023 (UTC)

BTW, WeRelate still uses the data in Special:Names, and WikiTree does as well. I've spent the last year working on a new name variants list for FamilySearch, which they plan to implement hopefully this Summer. I will replace the "computer" variants in Special:Names with the new variants later this year, but the human-confirmed variants will remain the same.--Dallan 16:27, 25 February 2023 (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! [6 January 2023]

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)

The Data Quality Issues report is now available 3 ways (besides the link from here):

• Select Data Quality Issues from the My Relate dropdown menu. This takes you to the list of issues in your watchlist (expect to wait up to 10 seconds).
• Select My Trees from the My Relate dropdown menu, and select check beside any tree. This takes you to the list of issues in that tree (expect to wait up to 10 seconds).
• Select Volunteer (top right) and then Data Quality patrol from the list of Quality patrols. This takes you to the Help page for monitoring data quality, which has a link to the full list of data quality issues. You don't have to signup for the quality patrol - you can help fix the backlog of issues so that some day it will be feasible to simply monitor for new issues. Even fixing a handful of issues gets us to that goal faster. If you decide to continue, coordinate your efforts with others on the talk page (the link is above the filters on the Data Quality Issues page). Note that you can filter the list by century to focus your volunteer efforts where you feel most comfortable.

Would you consider adding some type of "Explanation or Summary" field to the Verified template that gets added to the Talk page? I feel like an explanation would be helpful and good record keeping as to what was done or why nothing was done, yet the issue was still "verified" - similar to the Defer template? I find myself wanting to go back to the Talk page to add brief explanations. Thanks, --cos1776 15:25, 17 June 2022 (UTC)

Sure - I'll look into it. I wasn't sure if anyone would want to add comments, but if you do, I'll add the popup to capture them. Maybe next week.--DataAnalyst 17:30, 15 July 2022 (UTC)

This is done.--DataAnalyst 16:28, 19 July 2022 (UTC)

I've done a cursory review of the Data Quality Issues (DQI) for pages that I'm watching. It seems to me that if I correct an entry; e.g., an error in marriage date that, when corrected, resolves the issue, the cleanest way to proceed is to mark that DQI verified, the history for that page reflecting the change. Any necessary additional explanation can be documented either on the Talk page or on the Summary associated with that change. If I don't hear any objections to that method, I will proceed with cleaning up what I can on my watched pages based on the above. --jaques1724 01:22, 11 July 2022 (UTC)

Hi. I'm glad to hear you're planning to use the list to find and fix errors. However, please DON"T use the Verified by me button if you fixed an error. The button will put a template on the Talk page that will be nonsensical and confusing the next time someone looks at a page - e.g., it will say that you verified that the person was born before their parents were married, when in fact they were born after their parents were married.

I realize that it can be annoying to wait a whole day (or more) for a fixed item to no longer show up on the list, but I don't have a good way to remove the item from the list before the next time the batch job is run. The Verified by me button is NOT intended for nor should be used for this purpose. You can keep track of what you looked at (and might have fixed) by the color of the link, and can use the Defer button to keep track of what you looked at but chose not to fix (yet) - you can always remove the template if you fix the issue later. If you fix one date that addresses multiple errors (e.g., a bunch of children born before an incorrect marriage date), you might be able to keep track by clicking on all the affected pages right away - or you can go on to a different family and follow up again after the DQI page has been updated.

The next time I take a look at the code, I'll see how feasible it is to indicate that an issue has already been fixed - I might be able to do this for at least some of the issues without impacting performance too much. Thanks for the feedback.--DataAnalyst 17:30, 15 July 2022 (UTC)

The list now indicates which issues have been fixed. If you just fixed an issue, the "Fixed" tag shows up the next time you refresh the Issues page.--DataAnalyst 14:39, 4 January 2023 (UTC)

Works like a charm ! Thx woepwoep 15:20, 4 January 2023 (UTC)

Thank you for the work!!! Very much appreciated, have been trying to chip away at several things --Paula 22:30, 5 January 2023 (UTC)

Thanks for the clarification. Long story short (I think), if it's a simple fix, not a verification of suspect data, fix it, move on, and let the system finish the cleanup, usually within a day or two.--jaques1724 01:10, 16 July 2022 (UTC)

You got it!--DataAnalyst 02:57, 16 July 2022 (UTC)

Minor suggestions: When you add the defer message to the Talk page, it might be useful for the reader if it included the error message that is trying to be resolved. --Jrich 00:10, 19 July 2022 (UTC)

Defer is not issue-specific. If you choose to defer issues on a page, the code assumes that you fixed what you could and deferred all the rest. All the issues on one page should show up on the list together (barring the defect in sorting surnames with spaces, which I'll fix later), so you have an opportunity to be aware of all the issues you are deferring. And please don't ask for defer to be issue-specific - it would require creating more templates than I'm willing to manage.--DataAnalyst 16:49, 19 July 2022 (UTC)

Also, when adding a comment for deferred, I presumed Cancel meant cancel the defer, since it would be easy to simply erase partial comments which I don't like. However it still added the defer and the comment on the page ended up saying "(null)".--Jrich 16:01, 19 July 2022 (UTC)

When did this happen? The code was fixed last night and it should cancel properly now.--DataAnalyst 16:49, 19 July 2022 (UTC)

See Person:Asa Brown (14). The "birth" date used for the test was a baptism, so one year after death of parent is not strictly a valid test. Could argue that there should be a valid birth estimate before parent's death, but in this case, the father's page is not sourced (or found), so it doesn't seem wise to base an estimate on it. --Jrich 16:40, 19 July 2022 (UTC)

Technically, the date used was a christening date - the code ignores the date if it is entered as a baptism event. Christening means to name a child, and thus is assumed to have occured within a very short time after birth. If the baptism is later, the baptism event should be used, because it is not technically a christening. In most cases, WeRelate treats christening events and baptism events the same, but for intergenerational error checking, I'm not doing that, knowing that children were frequently baptized well after birth.

In the case of Asa Brown, however, I am very suspicious of the death date of the father, given that 3 children were baptized in different years after the father supposedly died. It seems unlikely that 3 children born by 1735 (a year after the death of the father) would be baptized in 1736, 1738 and 1741. My guess is that the dates were indeed infant baptisms (and thus, correctly entered as christening dates). The DQI report correctly highlights a probable error in the death date of the father. It is appropriate to defer the issues if you can't find better information. It would also be appropriate to add a comment to the father's page suggesting that the death date is suspicious.--DataAnalyst 17:09, 19 July 2022 (UTC)

For the message: "On 19 Jul 2022, user Jrich chose to defer resolution of issues on this page. Other users should feel free to resolve the issues if they have the appropriate expertise and access to sources. Please do not remove this template unless you are Jrich, or if all issues on the page are resolved." The person that sees this does not know what "issues on this page" is referring to. Does the poster need to add it as part of the comment? Why not add a parameter to the template for the issue description and if missing/blank use the message as above? Your code could easily build the template call with the problem description added as the extra parameter.

I think there should be (and I thought there was) zero difference between christening and baptism. Because in US and England most are actually called baptisms in the records, not christenings, and I know historically it has been discussed that WeRelate has not been correctly handling these according to the specifications of the various churches doing it. GEDCOM has CHRA for adult christenings, the description actually calling it a baptism: "The religious event (not LDS) of baptizing and/or naming an adult person". As opposed to CHR="The religious event (not LDS) of baptizing and/or naming a child", and BAPM="The event of baptism (not LDS), performed in infancy or later". It is not uncommon to see older children baptized several years after birth, when their parents did not belong to a church at the time of their birth.

You are right that in other cases, WeRelate treats christening and baptism the same. For the DQI report, I had choices to make. I could just consider the birth date and ignore christening and baptism, and treat it as an error (not just an anomaly that could be correct data). Or I could consider the other dates and treat it as an anomaly, because someone could certainly be baptized several years after both parents had died, and it possible that even a christening within days of birth could occur the year after the mother died (for now, I'm only checking the year, not exact dates). I probably should have split it and treated a birth date discrepancy as an error and a christening/baptism date as an anomaly, but I didn't think of that at the time. I'll consider making that change.--DataAnalyst 14:48, 21 July 2022 (UTC)

I am familiar with a variety of Christian religious practices. There are faith groups that "christen" in the sense of formally naming and dedicating an infant in a religious ceremony and then baptising at a later stage of life. So christening and baptism are not necessarily the same event. And I have seen many Person pages where a contributor erroneously entered a christening date as a birth date. The problem with the term "christening" is that it does not apply to non-Christian fiaths, whereas a more generic term like "Dedication" would be more generally relevant. However I acknowledge the Christian roots of the present Western genealogical conventions.

I think the logical relationship that could be enforced is BirthDate < ChristeningDate <= BaptismDate. I have previously commented on the futility of trying to enforce any of these relative to a parental marriage date. I do think as I have previously suggested, that child BirthDate < (mother's BirthDate + 10 years) or (fathers's BirthDate + 12 years) is highly implausible though not an absolute impossibility. In any case please do not conflate ChristeningDate with BirthDate or BaptismDate. --Jhamstra 04:50, 22 July 2022 (UTC)

The meanings of the GEDCOM flags are defined by the GEDCOM standard and obviously do not distinguish between Christening and Baptism with any precision. Since that is the form the data is imported in, and the form it is exported in, I think that must be how they are understood regardless of what it means in this religion or that. It is possible to add a CHR event and a BAPM event if you want, but once added, the ambiguity of the GEDCOM definitions means that overly precise uses will probably not be recognized correctly. --Jrich 05:46, 22 July 2022 (UTC)

GEDCOM is what it is. I prefer to do my updates in situ rather than using GEDCOM. My comments were directed to the WeRelate database not to GEDCOM. I beleive that my suggestions regarding consistency checking in WeRelate are valid independent of GEDCOM. --Jhamstra 22:37, 25 July 2022 (UTC)

I agree Asa Brown's father's death date is highly suspicious, but I did not post it, and am not going to erase it when I don't have a source contradicting it. That is why I deferred it. I can't fix it, I can't verify, what other choice do I have but defer it for somebody that has more insight or evidence than I do right now. Of course the culprit listed on the DQ report is the child, so it is in my list, but the child doesn't not appear to be the problem. [P.S. I have found hist death date, 1750/51, and corrected the father.]

I noticed that you corrected the father's death date - I had just found some probate papers showing the same thing. Thanks for taking the time to do the further research and fix this.--DataAnalyst 14:48, 21 July 2022 (UTC)

I added the comment about canceling defers the day after it happened to me: see [1] if you want to the exact date. I didn't know it was a recognized problem and if you fixed it, sorry to bother you. Haven't used it since. --Jrich 21:27, 19 July 2022 (UTC)

Not a problem.--DataAnalyst 14:48, 21 July 2022 (UTC)

I'll be making several fixes/enhancements to the report that I hope to get implemented in August. One is to treat birth date separately from christening/baptism date and one is to add the text of the issue to the deferred message. Another is to fix the sort for surnames with spaces in them. I appreciate the feedback to help the evolution of this page to be as useful as possible.--DataAnalyst 12:54, 26 July 2022 (UTC)

Item reported: Person:Holden, Isaac (2) b.1677 Born after mother was 50.

The mother has no birth date. I'm guessing father's birthdate was used? If doesn't violate father age criteria, shouldn't be reported? --Jrich 02:23, 29 July 2022 (UTC)

The mother's page has a birth year (1614). It just doesn't show up on the family page due to an old bug or edit conflict in WeRelate (I'm not sure exactly what the problem was, but this sometimes happened with old pages). Her birth year is clearly suspect.--DataAnalyst 02:30, 29 July 2022 (UTC)

Oops, obviously didn't notice that since no dates were shown on the Family page. Thanks. --Jrich 03:09, 29 July 2022 (UTC)

For anyone following this discussion and/or using the Data Quality Issues list, please note that I just updated the Help page related to the list to emphasize the expectations prior to marking an anomaly as verified. I hope the list doesn't give the impression that anomalies are meant to be verified - in most cases, they represent incorrect data and are presented so that bad data can be found and fixed. The only exception to this would be birth before marriage for some cultures (mostly European), where quite a lot of issues on the list represent correct situations. In all other situations, an anomaly should lead to suspicion that something is wrong with the data. True, exceptions occur, such as women giving birth before the age of 12 or after the age of 50, but these are rare situations, and if the data seems to claim such an occurrence, this is an opportunity to correct or verify the data (if sources are available), or provide a better estimate of a mother's birth year (in the absence of sources).--DataAnalyst 21:56, 29 July 2022 (UTC)

I'm sorry, but I'm going to argue that it is fundamentally impossible to know if the data is correct. All one can say is that it is supported by sources with no obvious errors. How many times was it correct to say somebody was married to Sarah only to find out they had two wives named Sarah. One new source comes along and it can change everything. --Jrich 04:34, 31 July 2022 (UTC)

I won't argue with that. All I was pointing out was that we shouldn't say we have verified a situation that relies on 2 dates (birth of mother and birth of child) when we only have sources to support one of the dates and the other date could easily be incorrect.--DataAnalyst 14:10, 31 July 2022 (UTC)

Depending on the source the other date could be incorrect. Virtually no page is ever done, and addition of new sources may well expose errors in the records, transcriptions, etc. so that even sourced dates can be wrong, not to mention issues concerning the quality of the source. Basically, even if "verified", the condition is still true, and may potentially signal an undiscovered error.

I like the report, but a little confused about the purpose of all the templates. We only flag the child not the mother. Most of my cases with this error are immigrants with parents born in another county. I watch the child, never touched the parents. Half the time, I doubt they are even the parents, because there are no sources, but someone posted it and I can't refute it. Wouldn't it be good to alert all watchers of the parents, not just of one child, there is a potential problem? After all, the problem involves data on their pages as well as on the child's page.

Also, I am trying to resolve the public nature of the templates, yet the personal action that is required. 4 people watching some page, and I verify or defer it. What does that mean to the other 3 watchers? Are they going to come along and do the same thing so we end up with a mixture of 4 verifies or defers on the Talk page? Or do they get fooled into thinking I am speaking for them, which I am not? It seems like I am cluttering up a public page with something that has a very personal focus (signal me that I have investigated this error to my satisfaction - deferred or verified not really material, so much as alerting myself I have already looked at it).

And since the Talk page never goes away even if you delete all the defers and verifys when you fix a problem, we are going to have a lot of pages that say see the Talk page, but the Talk page is empty. --Jrich 17:38, 31 July 2022 (UTC)

Sigh. I was afraid that I had either made things too complicated or had not explained things well enough. The Verified Template was meant to be on behalf of all contributors, not a personal statement. It means you have examined all the data and sources involved in the reported issue and determined that the situation, while unusual, is true to the best of your current knowledge (understanding, of course, that sources can be misleading or misinterpreted and the data is subject to change in the future). Maybe calling the button "Verified by me" was a mistake, leading to a misunderstanding of its intent. Maybe I should drop "by me". The Defer button, on the other hand, is specific to you - it means you cannot determine whether or not the issue is true at this time and you choose to leave it to later, let someone else resolve it, or just ignore it as being too trivial to want to resolve. A page with the Verified Template no longer shows up as an issue for anyone, unless they specifically ask to include verified issues. It is considered to be resolved, in favor of accepting the unusual circumstances as true. A page with the Deferred Template continues to show up on everyone's list but is only marked as Deferred for the person who added the template - that is, if you added the Deferred Template to a page, the issue would show up on my list without being marked Deferred.

An issue can be verified by more than one user - this might be useful, for example, if a newcomer were to verify several issues and someone unfamiliar with their work were to double-check and then track that they had also verified the issue. Maybe that is overkill. I don't know. Since verified issues don't show up on the report by default, double-checking and double-verification is unlikely, unless someone becomes very particular about the data they care most about. I wanted to have that as an option.

If you have a situation in which you have verified your contribution (one date) but not someone else's contribution (another date and/or a relationship), and you don't have the sources to refute or validate the other person's contribution, you should defer the issue rather than verify it. In your deferral comments, you can say what you verified and what you didn't. The issue continues to show up on everyone's list (encouraging someone to address it at some point in the future), but you can ignore it, knowing you did your best.

I appreciate your comment about the contributor who entered the questionable data possibly not seeing the issue because they're not watching the page with the issue. I hadn't thought of that. I doubt I'll change how the list works in the short term while it is still so long. In the meantime, you can always draw the issue to the attention of the contributor of the other data - if they are still around, which in many cases they aren't.

As for Talk pages still existing after templates have been added and then deleted - that already happens with the nomerge template and I have started deleting such Talk pages. If you encounter an empty Talk page, you can ask for it to be deleted (Request delete in the left-hand menu).

Please continue to help me understand the shortcomings of the list, the user interface and the Help. Maybe we can make things clearer while still providing users with essentially 3 options - "the data is right" (verified button/template), "the data was wrong and I fixed it" (no button/template), and "I can't tell whether or not the data is right" (deferred button/template).--DataAnalyst 21:06, 31 July 2022 (UTC)

I am thinking I might change all my verifies to defers because I do not want to cause people to not look at the problem for themselves. "The Verified Template was meant to be on behalf of all contributors, not a personal statement." I can only verify based on the sources available and my skill and understanding of those sources, so I think it is wrong to imply my verify means more than that - it is a personal statement and that is how I have been using it. I would recommend every user should verify all the items on their report to their own satisfaction regardless of what how I mark it. If you are going to insist on the "on behalf of all contributors" semantics, I will no longer have any use for verify.

I think the problem is that what I think I as a user needs, is a mechanism to tell me that I looked at the page so I can avoid wasting time re-checking a page. And that is how the buttons work, so I think it can work. I don't see other people's defers and by including verifies I can ignore other people's verifies and check for myself while ignoring my own verifies. So a new record will not be deferred in my report and will not be verified by me. But I can also get this functionality using just defer. --Jrich 23:04, 31 July 2022 (UTC)

Fair enough. The Verify Template was requested primarily for situations where children were born before their parents were married, in a culture in which this was reasonably common, so that the issues would no longer be reported.--DataAnalyst 23:35, 31 July 2022 (UTC)

I found the Data Quality Issues page on the My Relate menu. This is very helpful ! Will use it in the months and years to come. Thank you Janet ! Warmest regards Ron woepwoep 01:24, 31 July 2022 (UTC)

It looks like the code of the Defer button was adjusted today? If so, it appears to be adding a pipe to the template call with no following text? This causes the including description to be "" instead of "(see Data Quality Report)". --Jrich 22:33, 14 August 2022 (UTC)

Working now. --Jrich 05:19, 15 August 2022 (UTC)

Several changes were implemented last weekend and the report is being refreshed again (after being on hold for the periodic WikiPedia update this week).

• Invalid dates have been added to the issue list - and they outnumber all other errors. I debated whether or not to flood the list with these issues (many of which are just text in the wrong field), but since WeRelate attempts to find a year from even an invalid date, I thought it best to get these resolved so that other issues aren't created simply because of an incorrectly interpreted invalid date.
• Issue description is automatically added to the DeferredIssue template.
• "Event(s) before birth" has been expanded to "Events out of order" and moved from the Anomaly category to the Error category (it's always an error, even when it reflects conflicting sources and can't be resolved).
• Christening and baptism dates are now treated equally (as proxies when there is no birth date), and if they occur after the mother's death or more than a year after the father's death, they are categorized as anomalies rather than errors.
• Family pages are now being sorted by surname (husband surname, first name, then wife surname, first name).
• There were also a couple of other minor fixes/changes.

In addition, there is a new statistics page for those who are interested in how quickly we are addressing the backlog. The statistics start as of yesterday due to the changes mentioned above. (Over 1,700 issues were resolved or verified between 15 May and 19 Aug, the majority of these in the last month.)--DataAnalyst 18:36, 20 August 2022 (UTC)

Shared ancesters of genealogy researchers [19 June 2022]

I've composed a new article as a focus for discussion on a topic that I was thinking about the other day - given that another user is watching a page that represents an ancester of mine, how can I see whether that other researcher is actually related to me in some way or not? The page I composed is First Ashcraft Relatives and placed in the Ashcraft surname category. I believe the sharing that I've started is not a road to revealing personal information, but rather a new social element of WeRelate that is intrinsically genealogical. After I let this page cook in my brain for a few days, I'll decide whether to go forth and create a handful of other "first relative" pages for other surnames. Would be useful to hear feedback from others on this, in particular pros and cons that I've not yet considered. Regards --ceyockey 01:47, 16 June 2022 (UTC)

Just food for thought. Another way this could be accomplished is to add a "How are you related?" section to Person Talk pages and invite Watchers to add their relationship to the Person there. Strictly optional, of course. Many sites have relationship calculators that could be helpful. --cos1776 15:35, 17 June 2022 (UTC)

True, but I could see that leading to addition of "how are you related?" items to dozens of people reaching back through the ancestry. I was trying to avoid such a proliferation by focusing on the "first relative" relationship. --ceyockey 02:11, 18 June 2022 (UTC)

I've added a second at First Tish Relatives, where "Tish" is a quite rare surname in WeRelate. --ceyockey 03:30, 18 June 2022 (UTC)

• I'm not sure I'm completely seeing the intent here. Is the idea that the definitive way to check for the existence of such a page is to look at the surname category page? That's not so helpful for me because almost all my lines go back before the surname era in Friesland and Groningen, so they just have patronymics. Or should I go ahead and add my info to e.g. the earliest Keegstra in my line to use the surname? --pkeegstra 19:22, 19 June 2022 (UTC)

Data Quality Issues -- "Birth to an unusually old mother" [19 July 2022]

Those people dealing with this issue may find the following articles useful:

When Will You Reach Menopause?, WebMD
Before age 45 is considered early; average age is about 51.5 years and has been for decades; ethnicity is not a factor

What Is Menopause?, National Institute on Aging
Often begins age 45-55, can last 7-14 years

Menopause, Cleveland Clinic
typically occurs age late 40s to early 50s

Late-Onset Menopause: What Is Causing Your Delay?, healthline
Before age mid-40s is considered "early or premature menopause"; average age is 51; after age 55 is considered "late on-set menopause";
factors that may influence/lead to late on-set [other than genetic inheritance from mother], include obesity, and continuing to have children into early 50s

--GayelKnott 22:51, 19 July 2022 (UTC)

Baptism for the dead [3 September 2022]

I wanted to confirm something that I recall from a couple of years back, that we generally do not want to have baptism for the dead recorded in the person:baptism field. Is this correct? Thanks. --ceyockey 20:48, 3 September 2022 (UTC)

Yes, that is correct. In fact, it shouldn't be in any fact/event.--DataAnalyst 22:21, 3 September 2022 (UTC)

Ages, birth years and death years [3 November 2022]

Quite often I have to calculate with pen and paper the age of a person or their date of birth from other data. I keep a pad beside me for the purpose. Imagine my surprise the other day when looking through a set of very old tattered manuscript images on Ancestry to find a parish clerk from the 18th century using a blank page of the register to do the same! --Goldenoldie 10:11, 13 September 2022 (UTC)

i agree.

would be great to have some kind of service where you click on the birth date and it says Calc (back from the birth date)

I use the following technique:

if one has died July 1896 at age 56 then birthdate is ABT 1840.
if one had died June 1896 at age 56 then birthdate is ABT 1839.

Ron woepwoep 03:34, 3 November 2022 (UTC)

Nazi concentration camps [4 November 2022]

Have the Nazi concentration camps from WWII been added as places here? --ceyockey 03:31, 14 September 2022 (UTC)

I think so yes.

I searched for Dachau, as it is the first concentration camp.

Search term: "Dachau concentration camp".

First and only hit is a Template.

When i click "What links here?" i get a place Dachau.

Hope this helps, Ron woepwoep 03:20, 3 November 2022 (UTC)

Please note that according to the current rules, you would only create a Place page for a concentration camp if it is a cemetery. If it is not being used for a Burial fact, you would instead enter the location of the concentration camp in the Place field and the name of the concentration camp in the Description field. Unfortunately, a quick Search shows these Place pages which appear to have been created for concentration camps anyway.

At first glance, Place:Dachau, Dachau, Oberbayern, Bayern, Germany, mentioned above, looks like a page for the concentration camp because it only pulls in the Wikipedia text for the camp and not the town itself. We would have to dig into it some more to see if it is titled correctly and should also pull text about the town. --cos1776 14:53, 3 November 2022 (UTC)

Thanks for the feedbacks. --ceyockey 01:08, 4 November 2022 (UTC)

welcome ! i would love to think that a concentration camp is also a place of birth. woepwoep 01:17, 4 November 2022 (UTC)

Cemeteries and Cities [2 November 2022]

Has there been any discussion on the matter that it is likely that the number of Cemeteries on the planet outnumber the number of Cities/Towns/Villages? Curious about your thoughts. --ceyockey 02:50, 3 November 2022 (UTC)

Wikipedia-notice template suggested changes [15 December 2022]

Hello - I've made two suggestions related to this template, one in October and a second a few minutes ago; see Template talk:Wikipedia-notice. Thanks for taking a look. --ceyockey 02:51, 16 December 2022 (UTC)

Deceased children [6 January 2023]

I have two,children that have passed away as does my mother. If I can’t add myself or my mother how can I add them?--Pam41014 02:34, 3 January 2023 (UTC)

You could add them as individual person pages without connection to a family, at the least.

what follows is my opinion, and might be thrown aside by those who manage this site - but I've done some things like this, but not many times

You could create a 'technical family' which could have "Unknown Malesurname" and "Unknown Femalesurname" and associate the children's pages with that family. As far as your relationship to your living mother, you could in principle create another "Unknown Malesurname" and "Unknown Femalesurname" family, where you as "Unknown Femalesurname" is associated with that family.

the problem with this approach is that you would need to create a technical person page for yourself - and that is a problem; an alternative is to cross-reference the two technical families in their body text and avoid creating 'phantom people pages'.

A major point of not adding living people to WeRelate is a matter of privacy and not exposing potentially problematic information. However, obituaries typically do expose such information. In my opinion, if you can appropriately mask identities, via use of 'technical families' and 'technical persons', then a framework for future information filling is available without unduly exposing personal information while still accommodating one's desire to provide a genealogical record of the recently deceased.

--ceyockey 03:04, 3 January 2023 (UTC)

The problem with this approach is that pages are created for living persons which violates website policy. These pages should be deleted. —fbax.ca 13:06, 3 January 2023 (UTC)

Could I add them and “Link them” by listing them as the grandchild of their deceased grandparents?--Pam41014 03:34, 3 January 2023 (UTC)

See Template:Grandchild and Template:Grandparents; click "What links here" for examples. --fbax.ca 12:14, 3 January 2023 (UTC)

Hi. Please use this approach (the templates). Thanks. And my condolences on your losses.--DataAnalyst 12:54, 3 January 2023 (UTC) (volunteer administrator and programmer)

Looks like a great method. Thanks. --ceyockey 16:31, 3 January 2023 (UTC)

Thank you all,for your help. I will use the template method that was suggested. I am just learning how to navigate this site and want to do things correctly.--Pam41014 16:38, 3 January 2023 (UTC)

It might be, in the present case, that an additional template might be needed—Template:Greatgrandparents—if the children involved are young and the parents and grandparents are both still living. Would be rarely used, but might be used more over time as people's lifespans continue to lengthen. --ceyockey 18:56, 3 January 2023 (UTC)

Rather than create a new template; why not simply use the existing template and insert the word "great" before it? As in Person:Nathan Bax (1) --fbax.ca 17:19, 6 January 2023 (UTC)

how to rollback? [26 February 2023]

hi all,

i accidently renamed a person with no changes in the name.

as a result, the person got name(3) instead of his previous name(1)

see https://www.werelate.org/w/index.php?title=Person%3AJan_Klein_Mentink_%283%29&diff=27633775&oldid=27633772

when i tried to rollback (using 'history') it failed with following message:

Cannot revert edit; last contributor is only author of this page.

why is this so?

thx Ron woepwoep 16:15, 19 February 2023 (UTC)

I'm not sure. I renamed the page back to the original title. That should hopefully fix it.--Dallan 20:41, 19 February 2023 (UTC)

I only played with one example, so some confirmation of this may be needed.

When "Person:xxx (1)" is renamed to "Person:xxx (3)", it looks to me like the history is moved to "Person:xxx (3)", leaving "Person:xxx (1)" with no history (one history item showing the rename but as that one item is the current revision you cannot use it get back the old content). So presumably when you "tried to rollback (using 'history')", you were using the history of "Person:xxx (3)", and your edit of the past revision now looks like an edit of "Person:xxx (3)" to the system, i.e., it does not affect the page numbering. I could not generate the specific error you cited, but I could not find a revision in the history to edit that would restore the old numbering.

In my example, I deleted the redirect page named "Person:xxx (1)". After the rename, the redirect page will have no watchers, so I am allowed to delete it. Then I renamed "Person:xxx (3)", specifying explicitly that I wanted the new name to be "Person:xxx (1)" instead of letting the system pick a number. Since the page named "Person:xxx (1)" does not exist, this succeeded. This appeared to work for me.

Dallan would have to comment if this method has any danger to it. --Jrich 22:31, 19 February 2023 (UTC)

--- I recall having the similar problem a few weeks ago. DataAnalyst deleted the message on the Talk page and everything worked once that was done. --Goldenoldie 23:31, 19 February 2023 (UTC)

If this is a reference to "Merging two people where one has a block on him" on the Support page", that was an attempted merge when the talk page said nomerge. This is a different situation, this being a rename. Processing the nomerge directive on a Talk page is built into the operation of the merge process but should have no effect on a rename. A rename operation normally renames the talk page (though you can uncheck the box and leave it unnamed if not relevant to the new name). So it should just bring the nomerge directive to the new name. --Jrich 00:43, 20 February 2023 (UTC)

This approach appears to work. I didn't even delete Person:xxx (1) before renaming Person:xxx (3) to Person:xxx (1). As you say, I specified the (1) explicitly in the rename instead of letting the system pick a number. After the rename, Person:xxx (1) retained the history, and I could have deleted Person:xxx (3) if I wanted to.

I think the reason this works is under the covers when a page is renamed, two things happen: (1) the original page receives a different title but keeps its page id, history, and watchers, and (2) a new page is created with the original title that points to the new title. I assume there's another check that there isn't already a page at the new title, or that the page at the new title is just a redirect, but I didn't test that. Also, since "Rollback" in the history is for reverting to a previous page revision, and renaming a page doesn't actually create a new revision but just alters the page title, that's probably why rolling back didn't work. It's a confusing error message though. I just clarified it: MediaWiki:Cantrollback.--Dallan 00:34, 20 February 2023 (UTC)

Thx all for looking into this question.

I tried to reproduce the error but could not.

Here's what i did:

(1) The latest number for [person] is -1- by the action that Dallan executed

(2) On this page i press Rename and leave the new name untouched (e.g. no number added)

(3) now i get number -4- which makes sense since -3- was redirected to -1- and -2- is already taken by another person with the same name.

Now, from what i remember, the error occurred instead of step (3). but now i don't know why -3- was created anyway - in spite of the error message?

--woepwoep 08:06, 20 February 2023 (UTC)

As I understood your posting, the error occurred "when i tried to rollback (using 'history')", meaning step 3 completed and you were attempting step 4: rollback.

If you go to history, the description of the rename looks like this:

13:39, 19 February 2023 Dallan (Talk | contribs) Person:Jan Klein Mentink (3) renamed to Person:Jan Klein Mentink (1) over redirect (revert to original title) (revert)

This reflects Dallan's work correcting the original inadvertent rename, not what you would have seen, but it demonstrates the format of the history entry. I emboldened "revert" because in the actual message, it is a link, and I assume this is what you did while attempting to rollback the rename, and I presume it was that step that caused the error message. --Jrich 16:54, 20 February 2023 (UTC)

I'm likely missing something ... why does anyone care about the numerical identifier associated with a person page title? --ceyockey 16:44, 20 February 2023 (UTC)

No particular reason I suppose, though a long chain of redirects could be potentially confusing. But inadvertent renames could happen for other reasons (typos), too, I think. --Jrich 16:54, 20 February 2023 (UTC)

my preferred response from the system would have been to deny me to rename to the same name, e.g. the action is to rename John Doe to John Doe which is what i inadvertently did with this other person record.

the error mentioned that i could not revert the rename because i am the only user following this person record.

--woepwoep 10:30, 21 February 2023 (UTC)

I think this could be a good 'soft block', meaning it would give you the choice to rename to the same name or not, rather than a 'hard block' that would prevent it altogether. --ceyockey 02:56, 22 February 2023 (UTC)

Quite so. But that does not address the initial problem of not being able to reverse / undo / rollback the rename, does it? --woepwoep 07:10, 23 February 2023 (UTC)

Right. You can't rollback a rename. You have to rename it back to what it was (including the original number) instead. At least that's what I did and it seemed to work.--Dallan 05:05, 25 February 2023 (UTC)

Do you need to request deletion of the page title you want to move it to first? This would usually be a redirect, I think. --ceyockey 01:31, 26 February 2023 (UTC)

If the page you want to move it to is a redirect to the page you're about to redirect back, you don't need to request a deletion. Also, it's possible that if the page you want to move it to is *any* redirect then you don't need to request a deletion, but I haven't tested that.--Dallan 02:17, 26 February 2023 (UTC)

With all the very helpful comments thus far, i have come to the conclusion that - just as it is in accounting - you can not undo a booking, or in this case, a rename. Apparently it is just the way wikis work. Thanks all for contributing. Best regards, Ron. woepwoep 07:24, 26 February 2023 (UTC)

Place - Located In ... how to change? [25 February 2023]

Posting without first checking to see if this has been addressed before - apologies...

Consider Place:Burton Cemetery, Burton, Adams, Illinois, United States. The Cemetery is not located in Burton, but it is located in Burton Township. Is it possible to revise the primary 'located in' value? I don't see a way to do this via the standard input interface. Would the change involve renaming the place; for instance to Place:Burton Cemetery, Burton (township), Adams, Illinois, United States? Thanks for the information / assist. --ceyockey 03:03, 24 February 2023 (UTC)

Yes, you'd need to rename it, and then probably also remove the township from the "Also located in" places.--Dallan 05:07, 25 February 2023 (UTC)

Thanks. That worked. --ceyockey 22:09, 25 February 2023 (UTC)

WikiTree - what is WeRelate's relationship to WikiTree? [7 July 2023]

I've added a few things to WikiTree over time. It appears one way of contributing WeRelate content to WikiTree is through GEDCOM export from WeRelate and import to WikiTree. Is there a closer relationship between the two resources that can be leveraged? What, if any, relationship is there between the origins and management of the two resources? Thanks. --ceyockey 22:08, 25 February 2023 (UTC)

Chris Whitten (founder of WikiTree) and I are friends, and both of us make information on our respective websites available to others. (Data on WeRelate pages is available under a CC-BY-SA license.) A while ago Chris asked if it would be ok if WikiTree used the name variants database that we were maintaining and I agreed. If the communities wanted to have a closer relationship, I think both Chris and I would be supportive.--Dallan 02:29, 26 February 2023 (UTC)

Thanks for the information, Dallan. --ceyockey 16:41, 26 February 2023 (UTC)

What type of closer relationship would be useful, especially to WeRelate; but also, is there anything else that WikiTree wants now?--Julie Kelts 00:31, 27 February 2023 (UTC)

I'm not sure. I'll let others comment.--Dallan 05:10, 2 March 2023 (UTC)

Example: if i search for Johannes Schaapman on WikiTree, no matches are found. It would be very helpful if the search result on WikiTree would include the query results of a similar search on WR. And vice versa. Perhaps even import from one to the other on a per-person or per-family basis. Ron woepwoep 08:10, 2 March 2023 (UTC)

Interesting idea, Woepwoep. It would be useful to have a system cross-referencing links from each site to the other. How would importing from one to the other work?--Julie Kelts 22:13, 2 March 2023 (UTC)

For multi-person import there is gedcom. So obviously this is for adding or updating one single person or family. In the add form, instead of filling out the blanks, you can press the Find On WikiTree button with an optional field for the WT key. and upon selecting one of the records on WT, the add form is pre-filled with the data brought back from WT. Ofcourse you are still in add/edit mode so until you press Save Page, no data is added to WR. This is just one of many possible implementations brought up by your excellent question. Thank you, Ron. woepwoep 07:55, 3 March 2023 (UTC)

Thank you, Dallan. I'll try to limit my comments, as I am not impartial. I was thrown off WT last year for what I consider political reasons unrelated to genealogy. In my opinion, WT has lost its way in its attempt to be an accurate one-world tree, due to its focus on growth. And I am much more familiar with WT than WR, which I have more recently joined. That said, I think there are free-space pages on WT--if I may say so, some that I created--that would be useful for WR. Is there a way to easily import them? And WR has Source pages that WT lacks. I wonder if there is a way for WT to link to those (I am not in a position to learn whether they'd want to).--Julie Kelts 00:17, 3 March 2023 (UTC)

I've added material to WikiTree in the past and I just revisited the site and added a recent person addition to WeRelate. The philosophy between the sites is very divergent ... WikiTree goes for a narrative approach to describing a person and their life, while WeRelate goes for a data-driven approach. For the last few years I've been working (in a company) on a system that produces automated narratives from field delimited data. I can see a path forward for integration by developing an integration layer between the two resources that produces 'autonarrative' accounts of a person's life from the field-delimited data in WeRelate. Another observation is that WikiTree takes a more free-form academic citation style than WeRelate; the impact of this is that the citation styles of the two resources are sufficiently divergent to not be directly compatible. I'm seeing in the far future WeRelate being the wikidata of genealogy while WikiTree is a narrative and pedigree layer produced as an interpretation of the data in WeRelate. --ceyockey 02:39, 3 March 2023 (UTC)

nice one this last lilne suggestion of layers ! Ron woepwoep 07:55, 3 March 2023 (UTC)

The first thing that has to be done is decide what are the aspects of both sites that are central to their philosophy and which are merely cosmetic. I would argue that Dallan is well-positioned to do this. For example: free membership, the edit process (curated by manager, or open), source citations, etc. Presentation on the web pages is somewhat cosmetic though many pages in WeRelate have been specifically crafted to provide a coherent presentation when shown in WeRelate's format, and may lose some of that coherency if forced into a different presentation. If nothing different is deemed critical, it may be possible to combine. WeRelate suffers greatly from lack of numbers in my opinion.

The process of combining data may be difficult. For example, freeform sources versus structured citations, one site not capturing data needed by other (I haven't investigated, but possibly things like twins or adoptions could be built into wikitree data structures that WeRelate doesn't capture?), and there would be many people with different data that could conceivably cause duplicates, or multiple parents, etc.

Even trying to display both sets of data together (i.e., some sort of mirroring) on one page while keeping the two sites separate may be difficult for the reasons just mentioned. However, to the extent that commonality allows, it may be nice if both sites could 1) add a link to show that the data exists on the other site, or 2) flag those individual data items where the two sites disagree so the respective users could become aware of research they were not aware of, or communicate with users of the other site to resolve such discrepancies.

I have had poor experiences using page managers, but haven't used wikitree, so can't comment specifically of their approach. The need for so many page managers means that some will be poorly qualified for their role. I have experienced several cases where page managers are unwilling to do the work to verify to complex arguments for different facts and thus just ignore such contributions. --Jrich 15:21, 3 March 2023 (UTC)

Fair points Jrich. I think having a page manager is definitely *not* WR. So there can only be a 1->N relationship from WR to WT.

I've only just seen this comment thread and wanted to add my thoughts. I created the following page a few years ago - https://www.wikitree.com/wiki/Space:WikiTree_vs_WeRelate. I would very welcome anyone going in and enhance the page if you have any points to add in.

I personally 'defected' from WeRelate to WikiTree a few years ago. I decided many years ago to 'store' both my family tree and my OneName research on a public tree and I don't have the energy or see the value in updating multiple sites. Comparing the two sites I saw some key advantages in WikiTree (see article above for details). Size is key. The advantage of a pando is that you get to meet distant cousins and work with them collaboratively. That only happens with scale. I've met many more collaborators on WikiTree than on WeRelate - both distant cousins or people working on the same surnames and places. Finally size is also about sustainability - financial and technical. WeRelate growth has ground to a very slow pace and activity is significantly down. Inevitably this means income is down and the site has less capacity to keep going. One day this may lead to it stopping altogether - ultimately it was that fear that triggered my exit to WikiTree. The argument that size and quality are in opposition is bogus. The more people working on a site the more you have to maintain and challenge the content! AndrewRT 21:49, 7 July 2023 (UTC)

Everybody is free to work on whatever websites further their goals as they see them. But at the time of my post above, I did a check of one ancestor (the first one who came to mind that was not trivial but not mind-numbingly complicated). My sample size of one was enough to find wikitree wrong. One wife is misnamed, so not correctly identified (shown by the fact that the alleged birth doesn't match the age at death), and the second is also misidentified as a widow who, sources show, wasn't actually a widow at the time of the alleged marriage. So, numbers are great, but not a guarantee of quality.

Of course, I did pick something other than a trivial case. But those are the ones that are important. I sent an email to the wikitree profile manager because mostly I am interested in the truth being known. After given the somewhat less than welcoming response "I am sorry if you disagaree with this but the sources and family files say otherwise .... If you have sources that can unprove this profile then submit them and let the Wiki genealogists figure it out. Until then the profile stands as entered." I would have thought the specifics I mentioned could be checked by an experienced researcher without hand-holding, but I sent a followup with several links to various sources disproving one wife and making the strong circumstantial case for the other (both for my choice and against theirs, the marriage record being non-existent). No response, but I notice nothing has been changed on the profile. Other profile managers may be more open to changes, but this case happens to fit my expectations based on past experiences with profile managers. --Jrich 04:24, 8 July 2023 (UTC)

1950 United States Decennial Census - Template and citing FamilySearch pages [2 March 2023]

I've been using the 1950 US Census for a bit now and thought it was time that a 1950Census template be created, so I've done that:

Template:1950Census

There's about as much text in noinclude brackets as there is presented on the page that uses it.

Also, FamilySearch currently does not have page-level citation information available for all the content. I've started a Talk page discussion related to creation of citations until a copyable citation is available from FamilySearch.

Regards --ceyockey 01:26, 26 February 2023 (UTC)

My Trees - Notable Trees [8 March 2023]

Hello. A proposal. I've added a number of notable (Wikipedia definition) people to WeRelate with surnames that are in my pedigree, and expanded these out where possible. Wondering whether it would be possible / desirable / of interest to set up a new Trees domain, like "Notable Trees". These could of course be included in "My Trees" if they do in fact intersect with our own personal ancestry, but they could be removed from "My Trees" if they are not so related. It's a proposal for a "Public Trees" domain.

I realized I was "solutioning" and not "eliciting requirements" (in this case from myself), so...

• Right now there is no way to remove a tree from "My Trees" (other than deleting it). What this means is that the list of selectable trees appearing below the "summary" input box available when editing a page can grow without (apparent) limit.
  • Feature that would be useful: ability to select which trees appear in the selectable list when editing a person or family page.
  • Feature that could be useful: ability to put trees into certain "public tree spaces". For instance, One Name Study Trees, Notable Person Trees, Orphaned Trees (for trees created against a username that has been decommissioned either through person actively leaving or dieing), etc.
• Special:ShowFamilyTree has a search box, but it only supports right-stemming from an input (and it is case sensitive); in other words, if I search for "Yockey", it will not find Ceyockey:Yockey family tree. Therefore, it is not possible with the current interface to find other users who have created trees that have "Yockey" in their designation, such as (theoritically) one for "ILUVgenealogy:My Yockey lineage".
  • Feature that would be useful: expanded search capability against Trees; maybe the easiest way would be to include their titles in the main Search facility as a new search facet like "Trees"?

That's all for now. Thanks for listening. --ceyockey 02:30, 8 March 2023 (UTC)

I don't use trees. Annoyed by the extra step managing which tree for what seemed like very little tree and it seemed like as long as I had more than one, I somehow managed to get new pages into the wrong tree. So now all one tree for me.

That caveat aside, trees are for personal organization. Something community wide, like wikipedia notable people should be a Category, it seems to me. Individuals can put them in which ever tree makes sense for the personal categories, but a category expresses an grouping that has more universal meaning. --Jrich 04:17, 8 March 2023 (UTC)

JRich is right - the purpose of My Trees is to group people of interest to you, and Categories should be used to group people of broader interest.

To address some of your other points:

• The Special:ShowFamilyTree page is essentially a standard administrative list page that lists all My Trees in the system, from which you can dig one level deeper and list all pages in a selected tree. Its very limited functionality is intentional - it is not the place where My Tree functionality exists. That is found in Manage My Trees (My Relate > My Trees).
• My Trees were designed for personal use. It was not intended that they would be a way to find other users whose interest overlaps yours. As you know, users have the ability to indicate the Surnames they are researching. You can find out who else has declared they are researching a Surname by searching in the User namespace and putting the Surname in the Keywords field. Alternately, if you propose a new Category, you can find out who else is interested in it. Or you can just ask on the Watercooler.
• You are right that you can't directly remove a My Tree from your list of My Trees. However, you can merge My Trees. If you have a lot of My Trees you no longer want, I would suggest creating a "junk" My Tree and merging all the My Trees you no longer want into it. That will reduce your list of My Trees. (You could use your Default My Tree for this if you don't use the Default My Tree). We should have a function on the Manage My Trees page to remove a My Tree (without deleting the pages in it). Add this as a Suggestion if you want any priority placed on this.--DataAnalyst 13:35, 8 March 2023 (UTC)

I did not know (being a fairly new WR user) that I could indicate what family names I am interested in. Would you please explain how that's done?--Julie Kelts 00:38, 9 March 2023 (UTC)

• If you edit your user page, there should be a section between the preview of the page and the text box for content entry entitled "Surnames and/or places you are researching". This is where you can add your surname and place interests. --ceyockey 02:17, 9 March 2023 (UTC)

"Users researching" search specificity [14 March 2023]

I took a look at the "Users researching" for "Yockey", and it returned three users ... none of which have "Yockey" in the surnames they are researching. This is a consequence of the default being "Exact and close match"; if I revise this to "Exact match only", nobody is returned - as I suspected.

Suggestion: make the "Users researching" search by default "Exact match only". I think this is what most people would expect.

Thanks for considering this. --ceyockey 02:26, 9 March 2023 (UTC)

Hi. Please add a Suggestion on the Suggestions page. I can't keep track of requests unless they are entered there. Thanks--DataAnalyst 03:29, 9 March 2023 (UTC)

Exact matches are already presented in BOLD (see [Special:Search Groenen]). I see no need to change current behaviour. fbax.ca 13:01, 9 March 2023 (UTC)

Given the guidance about BOLD formatting, I don't think it's necessary to go forth with a suggestion. Thanks, Fbax and DataAnalyst. --ceyockey 02:31, 15 March 2023 (UTC)

Umm, wow? 80 grandchildren [15 March 2023]

I'm transcribing an obituary and it notes that the deceased had "80 grandchildren, several great-grandchildren and six great-great-grandchildren." The person died in 1968 at the age of 86. That sounds like a LARGE # of descendants. Is it? Based on your experiences? Just curious. The person in question: Person:Wallace Ferguson (1). Regards --ceyockey 02:28, 15 March 2023 (UTC)

My grandparents, of a similar vintage, had between 55 and 60 grandchildren. One daughter never married, one son had no children and another had only 2, so it wouldn't be hard to get to 80. Farm families were often large - my grandparents had 12 children (all of whom survived to adulthood, which was somewhat unusual for the time) and their eldest son had 13 children. --DataAnalyst 02:47, 15 March 2023 (UTC)

Large numbers perhaps; my [gt-gt-grandparents] had 12 children, 90 grandchildren (several still living), 342 great-grandchildren, 542 gt-gt-grandchildren. For a valid comparison to your obituary, we should only count the descendants born before progenitor's death; but I'm not interested in that exercise.--fbax.ca 13:44, 15 March 2023 (UTC)

I can't resist adding my family statistics to these notes. Two couples in my great-great-grandparent generation (one on my father's side and one on my mother's) had 12 children. Dad's grandfather was a farmer on a land grant not far north of Toronto, Canada. His 12 all became adults. My mother's great-grandfather was a schoolmaster, also with 12 children, but that family lived in a town on a fairly large Scottish island. Only six lived to adulthood and, of those, only four had children. Me? I am an only grandchild and my two children have gone through their breeding years without marrying. I guess that's why I like genealogy. --Goldenoldie 12:19, 15 March 2023 (UTC)

Pedigree mapping in Miro [17 March 2023]

I use Miro at work (full license) and thought I would do a bit in the free personal version related to pedigrees and information visualization.

See https://miro.com/app/board/uXjVMe-mC6w=/?share_link_id=359456071718 ← you should be able to view the content here, but neither edit nor comment, unfortunately.

There is a frame on there for my Maternal Pedigree and Paternal Pedigree. I set out to determine a simple visual method to determine three pieces of missing information across the full set of direct and close relations: Cause of Death, Birth Details and Death Details; these I've highlighted with Red labels so I can quickly assess the extent of missing information. Plenty of missing information, unfortunately.

There is also a frame entitled "Birth and Life by County" which has a county map of Illinois and some iconography for birth and residence in different counties and the distinction between maternal and paternal ancestry. Funny thing is that the only place where the two residencies overlap is in Macon county and only comes from my parents, which might be how many people's pedigrees look.

Just sharing this to illustrate one of a bazillion ways to visualize information, albeit manually. Most of the time was done in tweaking the formatting decisions - coloration, codings, card content. Now that I've got the iconography set, could if I so wanted do it relatively quickly for other families. If there is any interest in having the symbol palette I've made, let me know here and I'll set about setting up a small portion of the diagram as a portable symbol set (I've not done that yet).

Regards --ceyockey 20:47, 17 March 2023 (UTC)

Preservation of content via Internet Archive [18 March 2023]

This is something of a follow-up to a posting I made back in 2019; see WeRelate talk:Support/2019#Preservation of content via Internet Archive [7 February 2019]. I was looking about for information about WeRelate-related blogs and ran across the old discussion and thought I would write something.

I took a look at the WayBackMachine and find that the homepage of this site has been saved 830 times between 2 Apr 2006 and 16 Mar 2023; however, the VAST majority of saves in 2022 and 2023 are shown as redirects and not direct saves, as a 301 error is encountered and there is redirection to /wiki/Main_Page . Looking at the /wiki/Main_Page , there have been 600 saves between 14 Jan 2006 and 14 Mar 2023, the VAST majority of these being "real" saves. Looking at the Summary for the host site, it appears that there have been about 930,000 captures across 653,000 pages between 2006 and the end of 2022. Based on Special:Statistics, there are about 8 million pages in the database. If I'm reading my stats right (doubtful), this means that only about 8% of the pages have been archived to date. Now, this is sooo simplistic as to be silly as the real desire would be to determine the number or or proportion of person, place, family, and source, etc. pages which have been archived.

You can get some sense of whether a particular domain within werelate has been saved with any frequency. For instance, looking at https://www.werelate.org/wiki/Person: returns the first 10,000 URLs captured; this uses the "URLs" view via https://web.archive.org/web/*/https://www.werelate.org/wiki/Person:* . Following is shown in order presented in "namespace" dropdown in the Search WeRelate form; the numbers are the number of unique URLs captured, not the total number of versions captured:

• Person and Person_talk >10,000 each
  • >30 million person pages in WeRelate
• Family >10,000; Family_talk 1,084
  • >11 million family pages in WeRelate
• Portal 24; Portal_talk 19
  • 22 Portal pages in WeRelate
• Article 20; Article_talk 0
  • 5,062 Article pages in WeRelate
• Image 3,107; Image_talk 8
  • >79,000 Image pages in WeRelate
• Place >10,000; Place_talk 4,245
  • >450,000 place pages in WeRelate
• Mysource 3,009; Mysource_talk 216
  • >100,000 MySource pages in WeRelate
• Source >10,000; Source_talk 3,860
  • >945,000 Source pages in WeRelate
• Transcript 228; Transcript_talk 8
  • 3,598 Transcript pages in WeRelate
• Repository 1,260; Repository_talk 162
  • 3,007 Repository pages in WeRelate
• User 3,068; User_talk 969
  • 5,685 User pages in WeRelate
• Category 9,258; Category_talk 219
  • >56,000 Category pages in WeRelate
• Surname 7,242; Surname_talk 122
  • >100,000 Surname pages in WeRelate
• Givenname 81; Givenname_talk 4
  • 17,610 Givenname pages in WeRelae
• Help 183; Help_talk 100
  • 156 Help pages in WeRelate
• WeRelate 388; WeRelate_talk 222
  • 349 WeRelate pages in WeRelate
• Template 370; Template_talk 30
  • ~120,000 Template pages in WeRelate
• MediaWiki 171; MediaWiki_talk 186
  • ~1,900 MediaWiki pages in WeRelate

Personally, I do try to archive Person pages and Family pages which have reached some "reasonable state" of maturity, but there are many pages that I watch which have not been archived. One of the most pressing concerns in the previous discussion was the potential archiving of living person information. There is likely a mechanism for purging an archived page from WeRelate; I've not dug deep enough to find this yet.

From a community point of view, I think I'll look at WeRelate and Help pages and ensure there is 100% coverage of these in the Internet Archive. A greater # of pages in Internet Archive than are currently active in WeRelate is indicative of retention of copies of pages which have been deleted, renamed, or otherwise decommissioned. Also, I'm considering whether we should have some WeRelate collection designated in Internet Archive rather than just having all of our URLs float in the general sea of internet content; I'll take a look into some of the pros, cons and possibilities there.

Hope you find this interesting. All the information here is from standard user queries in Internet Archive and WeRelate and does not rely on any "back end" access. Regards --ceyockey 02:07, 18 March 2023 (UTC)

Of relevance is that I expect that by 2024, WeRelate will have virtually no active pages for living people.--DataAnalyst 02:21, 18 March 2023 (UTC)

That's great to hear. Thanks. --ceyockey 13:21, 18 March 2023 (UTC)

suggestion about RSS Help page [18 March 2023]

See WeRelate:Suggestions/Update_Help:RSS_page --ceyockey 14:27, 18 March 2023 (UTC)

Languages used in pages - English, French, German, etc. [7 April 2023]

Hello. I saw that some recent place pages have been entered in French. This is not a bad thing. It got me thinking about language handling in WeRelate. I did a bit of pecking around in the WeRelate:Talk space and this topic has come up before, primarily in the context of English being the predominant language used here and that creating problems for adoption outside the English-speaking world.

Problem: How do you know the language of a page before you visit it?
Problem: Given any particular search result, it's unclear in the search results which pages are in one language and which in another.

At present there is no 'tag' which indicates the language a page is in, so that it cannot be used, for instance, as a list-display or filter option, nor a search option, nor an on-page indicator. There has been a suggestion that Person and Family pages have English-language versions if originally entered in non-English. I'm not sure if that is a good idea or not, but it is an idea. However, at present, there is not a way to indicated on a French-language person page that an English-language version is available, nor vice versa.--ceyockey 13:43, 7 April 2023 (UTC)

Having two separate pages for a person in different languages goes against the philosophy of WeRelate. Therefore, there is no concept of a page being in a given language. For royal and noble lineages, it is common for the name to vary from one language to another. If so, alternate names can be used, and the decision on the primary name often (but not always) depends on who created the page. Narratives in one language can be translated to another - if so, the results can follow the original text.--DataAnalyst 13:54, 7 April 2023 (UTC)

'Cemteries of' categories [28 May 2023]

I'd posted at Help talk:Categories#"Cemeteries of" categories .5B28 May 2023.5D 5 years ago on the topic of retiring these categories, but did not receive any input. Thought to edit that posting now to "refloat" it and post an xref here for attention's sake. Thanks. --ceyockey 00:47, 29 May 2023 (UTC)

We are listed as one of the best 101 genealogy websites by Family Tree Magazine again this year! [8 June 2023]

Here's the complete list. In addition, Family Tree Magazine has a special giveaway where people have a chance to win a genealogy websites-themed prize pack worth over $100.--Dallan 08:02, 8 June 2023 (UTC)

England & Wales birth and death records [7 July 2023]

Hi everyone. I found this note on Canadian blog that I regularly subscribe to:

"The General Register Office (GRO) has launched a new scheme allowing instant access to 1837-1922 birth records and 1837-1887 death records by downloading them as digital images.

"The digital images cost £2.50 (about CDN$4.25) each, and they are available to view immediately after purchase.

"Family historians previously had the option of ordering records as either a print record for £11 with a GRO index reference supplied or a PDF for £7. It took up to four working days for these orders to be sent.

"Before searching these records, you first need to register or log in. (Scroll down the GRO web page to find the section, Register or Login.) After logging in, select Order a Digital Image.

"According to some people who have already taken advantage of this instant service, there is a wee downside.

"Unlike the pricier PDF images, some say the faster JPG images only provide the record line from the register. Apparently, the image doesn't contain the four top rows of a certificate, such as Superintendent Registrar's District, Registrar's District, Death Year, County, and the column headings."

Notice: marriages are not included--probably because finding both the bride and the groom would be slower and less trustworthy, even for a computer program.

/cheers, --Goldenoldie 14:12, 7 July 2023 (UTC)

2 similar sources [22 August 2023]

Hi - not sure if these are effectively the same source and therefore one has to go.

Source:Utah, United States. Abstracts of Deaths and Marriages Notices in the Deseret News Weekly of Salt Lake City, Utah (1852-1888)

and

Source:Davis, Kent. Deseret News Weekly Death Notices and Marriage Index 1852-1888

Thanks in advance for the help and / or advice.

--Paula 09:38, 21 August 2023 (UTC)

The first is an Ancestry item titled as if government/church records, the second is a familysearch film titled as if a book (familysearch catalog entry). An index and a set of abstracts is not necessarily the same. Do they contain the same material and same page numbering? Someone that knows will have to say. I have access to neither. --Jrich 13:50, 21 August 2023 (UTC)

No, these Sources should not be combined. To be combined, sources should be effectively word-for-word versions of each other (as with image-based reproductions of a printed source) in my opinion. When sources are not verifiably the same (so that a researcher can find the same information given locators such as page numbers), then they should be kept separate. However, if they clearly (or are reasonably likely to) have the same content or closely related content, it is good to add a separate "See Also" section to each source containing a link to the other.

In this case, the URLs in the sources were dead, so I have gone ahead and corrected those and added See Also sections with cross-links. --robert.shaw 19:33, 22 August 2023 (UTC)

Thank you both for your answers and efforts, I will be more learned next time! --Paula 00:58, 23 August 2023 (UTC)

WeRelate's Wikipedia article [19 September 2023]

The article is remarkably out of date. I am not a Wikipedia contributor, but I hope someone who reads this post is and has a little time to update the article. (I don't think there is a rule prohibiting involved members from doing edits as long as they disclose their connections.)

Also, I would like to view the 2007 interview of Dallan Quass by Dick Eastman, but the link in the article does not lead to an available site. If anyone knows whether the interview is still online anywhere, I'd appreciate a link. Thank you.--Julie Kelts 20:03, 14 September 2023 (UTC)

I've done some editing on the article, but it certainly needs more work. Here's the current page statistics view: https://xtools.wmcloud.org/articleinfo/en.wikipedia.org/WeRelate . --ceyockey 01:42, 20 September 2023 (UTC)

How to deal with changed name spelling over the years? [21 September 2023]

hi all,

i was wondering about the change of spelling over the years and how names should be entered here on WR.

example: Aleijda Reierinck

the ij in the given name has changed to just i over the years. and the inck in her surname has changed to ink.

i usually add the person with today's spelling and use alt name for original spellings

is this a correct way of working? how do you deal with changes in spelling?

thx Ron woepwoep 04:32, 21 September 2023 (UTC)

Other related issues may include spelling variations. A general problem. I think the WeRelate guideline was to use most common variant. I tend to favor the modern spelling. As suggested, use alternate name if the difference is so great that the WeRelate search engine may not recognize the spelling as a variant.

Some names I work with had one spelling in 1600s, a different spellings in the 1700s, and both survived into modern times. A friend's family tree has 32 different spelling of his last name. Often the modern version isn't what you see in literature, so one may be tempted to pick the literature version, thinking that is the best spelling for matching searches. But often that literature merely reflects how that one author chooses to spell the name, or is only based onthe one generation of the family that their article covers, and still, original documents may differ from the literature.

In U.S., older names were phonetic, and varied from document to document, so difficult to find an "authoritative" source. People could get born, married and died, all under different spellings. But even when I feel it is appropriate to use different spellings in different eras (i.e., Americanization of Sonntag to Sunday, or my subtree connects to an existing tree that spells the name differently), I generally try to have all the children on a family page reflect the same surname, else the page can look kind of raggedity, and could make people think the research was superficial. If there is a different spelling to be used, I try to have it be the father. No answer is perfect. I try to consider what I think is simplest for the reader. --Jrich 16:56, 21 September 2023 (UTC)

thank you Jrich. I see that you struggle with the same issue. in my example it is also true. phonetically Reijrink and Reierinck are one and the same. woepwoep 17:22, 21 September 2023 (UTC)

The end of the "fh" links [14 October 2023]

Out of curiosity I just clicked the "source: Family History Library Catalog" link that appears on most Place pages in WeRelate. I was greeted with the message

"We are sorry, but the page you requested is no longer available. If this was a record, the record may have been removed. If you arrived here from a bookmark, please delete your bookmark."

I feel sorry for the team that took the trouble to add these sources to all our Place pages back in 2007, but I have been suspicious for a long time that these links served no purpose. Regards to all, --Goldenoldie 12:43, 11 October 2023 (UTC)

It appears that the link syntax has changed.

An old link looks like www.familysearch.org/eng/library/fhlcatalog/supermainframeset.asp?display=localitydetails&subject=198434&columns=*,0,0

A new link looks like www.familysearch.org/search/catalog/results?count=20&placeId=198434&query=%2Bplace%3A%22United%20States%2C%20Illinois%2C%20Coles%2C%20Mattoon%22

What needs to be done is to update Template:source-fhlc. The passed parameter is preserved in the new link (highlighted in urls above), so changing the template should be sufficient rather than editing each page individually.

--ceyockey 15:46, 14 October 2023 (UTC)

On further looking it's not as simple as at first thought. The link does not work without the "query" parameter, which suggests a need to parse the page name into the URL. I've tried some variants, but it seems the URL is quite picky about what is passed in the "query" parameter. --ceyockey 16:07, 14 October 2023 (UTC)

Places [17 November 2023]

"Newton was incorporated from Cambridge in 1681."

One would think these situations, of which this one is only one of many, should not need to be documented on each page that involves such a place. The history section of the place pages should indicate this.

The other half of this question involves whether to use Newton, Mass., or Cambridge, Mass., as the place name.

Clearly Newton did not exist prior to 1681. So should Newton ever be used for an event before 1681? I think there are reasons.

Years ago I tried to find what impact the place name had on the system or was it only a link to a Place page. The one other function it seems to have was when you map places on the Pedigree maps. Are there more?

The maps don't seem to work now. Or else they are so slow they might as well not work. Are they going to be fixed?

Because use of the place name for mapping suggests that Newton should be used so the location of the even maps correctly even though Newton as a name did not exist prior to 1681. If you use Cambridge, presumably you will get a dot that is in the center of modern day Cambridge, which would specifically not be in Newton. If people lived in the part of Cambridge that became Newton, then using Newton would give a more accurate mapping.

The other reason is that using Cambridge before 1681 and Newton after 1681 is that it makes it look like people relocated, when they likely stayed in the same residence the whole time.

Given that determining location can be difficult, i.e., a baptism in Wakefield, Mass., does not mean use Wakefield since that is where the first church that served all of Reading was. And it may require studying of deeds to determine where people lived when places weren't called by modern names. But if somebody has determined it, which is the correct way to handle it? --Jrich 15:42, 17 November 2023 (UTC)

Silencing Warning [11 March 2024]

Is it possible to silence the warning "Questionable information identified by WeRelate automation To check: Grietje de Boer (14) Born before parents' marriage"?

Yes. See instructions on this page Template:BirthBeforeParentsMarriage.--DataAnalyst 16:15, 3 February 2024 (UTC)

On the family page where I am seeing this warning right now, the transcript explicitly says "Bijzonderheden: Legitimatie van twee kinderen" so yes, the sources confirm that two children were born before the date of the marriage. --pkeegstra 16:04, 3 February 2024 (UTC)

Thank you! The terms I used for searching didn't appear anywhere on that page. --pkeegstra 19:11, 3 February 2024 (UTC)

My own opinion is we should ditch this warning. Many, many children have been born to unwed parents. And in some more rural places and times in the world weddings as we know them are not common or not practiced at all. Consider meso Americans as just one of many examples. I don't think we should impose Western cultural mores on those whose family histories are memorialized on WeRelate; in the case of this warning those whose "common law" unions were later memorialized according to more modern customs.--Jhamstra 23:04, 3 February 2024 (UTC)

Agreed about 'many, many children have been born to unwed parents' ... but the family page structure implies that marriage is a prerequisite for calling a parent-child relationship a "family". Agreed this should be loosened or revised in some fashion to expand beyond Western traditions. This isn't a call for burying Western culture, but for treating it as one of many ... particularly as our user base has expanded over the years. Thanks for considering this. --ceyockey 02:59, 11 March 2024 (UTC)

Would it help if the message text was changed - maybe something along the line of "Check to see if assigned to the correct parents"? Of a few records with this message I researched this morning, I corrected 2 marriage dates and 1 birth date - they all had typos - and moved 4 children to a previous marriage or relationship of one of the parents. I also verified that 1 record was accurate. The main purpose of this message was to find misplaced children so that they can be fixed, but a lot of typos show up as well.

Maybe a compromise would be to show the message only on the Data Quality Issues list, so that situations that are actually wrong can be found and fixed, but not to display the message on the person or family page. This means a user might enter a typo and not be given an immediate warning about it, but would be less annoying for those of cultures where birth before marriage was common.--DataAnalyst 17:15, 11 March 2024 (UTC)

I consider this warning message helpful, therefore I think DA's first suggestion is a good compromise, perhaps with the addition of simple instructions for removing the warning and documenting the reason in cases where it doesn't apply. --cos1776 17:59, 11 March 2024 (UTC)

Départements, in France [24 March 2024]

Hello ! Please, could you give your opinion on my wish in this discussion ? --> https://www.werelate.org/wiki/User_talk:DataAnalyst#Renaming_..._.5B16_March_2024.5D

Thanks ! - --Markus3 10:36, 17 March 2024 (UTC)

Markus3 could you please provide more specifics and some examples about your proposal on this page? For example,

• Currently, places in France are organized into the hierarchy they were in 1965. What year do you propose to change this to?
• I believe you want to rename Basses-Pyrénées to Pyrénées-Atlantiques. Can you provide some other examples?

--Dallan 20:43, 17 March 2024 (UTC)

Hello, Dallan !

Le choix d'une date (date butoir) remplaçant 1965 n'est sans doute pas nécessaire.

1) Le robot WerelateAgent est resté totalement inactif quand j'ai actualisé "Basses-Alpes" pour "Alpes-de-Haute-Provence" (198 communes). J'avais donc pu renommer sans problème ce nom quand toutes ses communes avaient été "vidées".

2) WerelateAgent s'est "réveillé" pour annuler mes modifications incomplètes (environ 520 communes sur 546 pour "Basses-Pyrénées" / "Pyrénées-Atlantiques"). --> Je pense que je n'aurais pas dû laisser une dizaines d'heures avant de terminer.

3) Le 3ème département nécessitant une modification est "Côtes-du-Nord" pour "Côtes-d'Amor" (348 communes).

Je vais tester (sans faire de longue pause de plusieurs heures) si le robot réagit à nouveau.

(GoogleTranslate)

The choice of a date (cut-off date) replacing 1965 is probably not necessary.

1) The bot WerelateAgent remained completely inactive when I updated "Basses-Alpes" for "Alpes-de-Haute-Provence" (198 communes). I was therefore able to rename this name without any problem when all its municipalities had been "emptied".

2) WerelateAgent "woke up" to cancel my incomplete modifications (around 520 municipalities out of 546 for "Basses-::Pyrénées" / "Pyrénées-Atlantiques"). ---> I think I shouldn't have left ten hours before finishing.

3) The 3rd department requiring a modification is "Côtes-du-Nord" for "Côtes-d'Amor" (348 communes).

I will test (without taking a long break of several hours) if the bot reacts again.

- --Markus3 07:14, 18 March 2024 (UTC)

How are things going? When you updated Basses-Alpes for Alpes-de-Haute-Provence, did you add Basses-Alpes as an also-located-in place so researchers could see that the places were also located in Basses-Alpes at some point in the past?--Dallan 05:20, 24 March 2024 (UTC)

Date field not working today [30 April 2024]

Birth, Marriage and Death dates are being deleted during the save process. --Susan Irish 17:56, 30 April 2024 (UTC)

Thanks for the heads-up, Susan. I can see what the issue is and have sent it to Dallan to fix.--DataAnalyst 18:35, 30 April 2024 (UTC)

This has been fixed. (I don't think any data was actually lost - dates just weren't being displayed.) --DataAnalyst 19:50, 30 April 2024 (UTC)

Entries not being Indexed [9 May 2024]

New people entered 12 hours ago are still not indexed. Example Lois Maxson --Susan Irish 06:24, 9 May 2024 (UTC)

It looks like indexing is working now.--DataAnalyst 16:02, 9 May 2024 (UTC)

Temporary change to page display [18 May 2024]

Over the past few days, an Alibaba bot has been very active on WeRelate, resulting in unacceptably slow response times. Dallan shut down the bot for now, but another could start from another location at any time. To address the issue, Dallan made a temporary code change to avoid slow response times. As a result of the code change, you will notice that page displays are not as usual. In particular, events, marriages and family members don't always display in date order, and dates of family members don't show up. Also, a few dates will display unformatted (e.g., all caps). These are all temporary situations as we work out the best long-term solution to the problem.--DataAnalyst 14:58, 18 May 2024 (UTC)

This has been resolved. The dates display and sort correctly now. We don't anticipate any further performance issues, but please let us know on the Support page if there are.--DataAnalyst 21:04, 18 May 2024 (UTC)

Volunteer for a New Advisory Council [17 June 2024]

Interested in guiding the evolution of WeRelate? I am looking for a few people to sit on a new Advisory Council to discuss how WeRelate might evolve to better serve its users by facilitating unified reliable well-sourced genealogy. The Advisory Council would propose and discuss ideas on a variety of topics and review suggestions submitted by users. It would make recommendations to guide and prioritize the work of volunteer administrators and software developer(s).

This isn’t a hands-on working committee, but a group to generate ideas and provide advice. If you are interested, please let me know by the end of this month (June). I will choose a few council members and plan to hold our first meeting in July.

Some possible topics to discuss include:

• Style guidelines and templates (keep, replace, add, remove?) so that Help pages can be improved (Help page redevelopment is a significant project that needs some advice)
• Improving functionality (features)
• Defining/consolidating source pages for confusing situations (e.g., overlapping transcriptions of the same original data)
• What to do with old data that doesn’t meet WeRelate goals
• What else is on your mind?
• Virtual meetings will be held approximately 4 times a year after the initial 4 or 5 meetings, which are expected to be approximately every 6 weeks.

Volunteers for the Advisory Council will be expected to:

• Have significant experience with genealogy
• Be committed to WeRelate’s goal – a unified tree of reliable well-sourced data – and have some insight into what it would take (e.g., software, standards, community) to achieve it
• Be open to multiple viewpoints and willing to listen
• Be willing to offer opinions
• Be willing to build consensus

Thank you--Dallan 22:46, 16 June 2024 (UTC)

hi Dallan, how to apply for membership into this Advisory board? i am not a professional genealogist. however i do subscribe to the goals of WR (one - wikipedia like - page for every person who ever lived, maintained by 8 billion people). thx, Ron woepwoep 02:51, 17 June 2024 (UTC)

I should have mentioned that. You can leave a message here as you have done, or people can email dallan at WeRelate.org—Dallan 08:20, 17 June 2024 (UTC)

Problem logging on to WeRelate using Chrome [3 July 2024]

Anyone else having this problem? For three days now I get the message "This site can’t be reached Werelate.org refused to connect..." I have a fairly new computer (Mac) and as far as I know all my systems are up to date. I can still log on through Safari.--Julie Kelts 21:20, 2 July 2024 (UTC)

I can sign in using Chrome (and Microsoft Edge).--DataAnalyst 22:05, 2 July 2024 (UTC)

It's back for me this morning. I don't know what changed (nothing I did), but all is well now.--Julie Kelts 17:17, 3 July 2024 (UTC)

Any update on the fate of WeRelate? [19 December 2024]

Wondering as the years have passed, any additional thoughts on the short and long term fate of WeRelate? It would be useful if this data site could be merged in some way with the more user-friendly output format of WikiTree. --ceyockey 04:07, 12 October 2024 (UTC)

WikiTree ... more user-friendly output format ? ---> No !

ceyockey, some arguments, please ! --Markus3 08:52, 12 October 2024 (UTC)

Je vais essayer de participer à cette passionnante discussion, mais mon anglais est vraiment très faible. Je dois utiliser GoogleTrad qui est fort médiocre.

I will try to participate in this fascinating discussion, but my English is really very poor. I have to use GoogleTranslate which is very mediocre. --Markus3 09:25, 12 October 2024 (UTC)

User interface preferences vary from person to person, which is one of the reasons it makes sense to have more than one option. I can't use WikiTree because I find it takes too much effort to pick out relevant information. I much prefer WeRelate, which is neuro-divergent friendly. Also, my understanding is that support for entering source citations is stronger in WeRelate.

Merging data with similar sites such as WikiTree could be a good thing - but also a significant amount of work. In the meantime, records can be cross-referenced.--DataAnalyst 13:15, 12 October 2024 (UTC)

Is the new Advisory Committee considering such questions?

I don't know what "merging the data" would mean. Is that the same thing as merging the two sites? People should take a good look at the policy differences before coming to conclusions. In my opinion, WikiTree has been gamified and trivialized and wouldn't be compatible with what I see as the more serious WeRelate. For one thing, WT has essentially an "anything goes" policy for sources on post-1700 profiles. Just my opinion, of course.--Julie Kelts 14:46, 12 October 2024 (UTC)

The Advisory Council has been focused on other things, so far (an enhancement and some guidance for refreshing Help). I'll suggest at the next meeting (in a couple of weeks) that we put out some form of communication.--DataAnalyst 15:03, 12 October 2024 (UTC)

I tried both WT and WR. I would not have found WR if WT would have sufficed. So there is something within WR topping WT. woepwoep 09:06, 13 October 2024 (UTC)

Rapidement, quelques qualités et défauts :

• • WikiTree

1) pages trop bariolées
2) gadgets inutiles et encombrants (exemples à suivre)
3) manque de traçabilité (perte de l'historique des modifications)
4) trop raccoleur

• • WeRelate

1) Sobriété et grande clarté des pages
2) Ergonomie efficace
3) Contributeurs encore trop peu nombreux
4) Logiciel "moteur" de base MediaWiki permettant facilement la création de pages annexes touchant à l'histoire locale et la sociologie (en lien direct bien sûr avec la généalogie)

(Google Translate) Quickly, some qualities and defects :

• • WikiTree

1) pages too colorful
2) useless and bulky gadgets (examples to follow)
3) lack of traceability (loss of modification history)
4) too touting

• • WeRelate

1) Sobriety and great clarity of the pages
2) Effective ergonomics
3) Contributors still too few in number
4) Basic MediaWiki "engine" software allowing easily the creation of additional pages relating to local history and sociology (directly linked of course to genealogy)

• • --Markus3 10:20, 13 October 2024 (UTC)

WeRelate costs roughly $500/month to run. Our ad revenue from MyHeritage and Google combined with occasional donations allows us to break even but we don't have any excess. We talked this over in the last advisory board meeting and decided it would be a good idea for us to start building a reserve in case ad revenues drop.

To help us build up a reserve I committed to do two things before the end of the year.

1. Increase the annual donation to remove ads to $30/year from $20/year. It's been $20/year for over a decade and it's time to increase it.

2. Create an easy way to set up recurring donations on Paypal and Patreon. If 40 people donated $5/month our financial situation would be a lot more secure.

--Dallan 02:02, 25 October 2024 (UTC)

i changed from 19 USD to 90 USD per annum. Hope this helps. Thx Ron woepwoep 23:34, 18 December 2024 (UTC)

Thank you. It helps.--Dallan 04:59, 19 December 2024 (UTC)

I think the answer to the original question is two-fold:

• We are committed to maintaining WeRelate because we believe it has a distinct role from other genealogy wiki's:
  • Strong focus on source citations
  • Some very strong "genealogical spaces" with excellent data quality and sourcing, such as early New England and New Amsterdam, some continental European
  • Ability to identify situations warranting a closer look so that we have a chance to improve data quality in other "genealogical spaces"
  • A user interface that suits many people better than more busy user interfaces
  • A low-key interaction culture (e.g., less gamifying, less prompting for thank you's) that also suits many people better than other approaches

• We currently have the financial resources to keep operating WeRelate, but would like to strengthen our ability to weather the future by building a reserve (see Dallan's comments above). We don't see finances as a risk at this point, because we believe we have many supporters who would be glad (and able) to give a small monthly donation, but haven't been asked to do so in several years (until now).

To support WeRelate's long-term future:

• A few volunteers recently received training in supporting operations.
• Most of you are aware that I continue to enhance the features of WeRelate (albeit sporadically). See the Roadmap for the status of changes.
• A couple of us are refreshing Help (restarting a stalled project from a few years ago) with the ability to seek advice on data entry conventions from the new WeRelate Advisory Council.

In relation to some of the comments above about merging or cross-referencing with WikiTree or other sites, I believe that cross-referencing individual pages between sites and picking up reliable sources and data from each other can make the whole online genealogical world stronger (as long as we're careful about proper matching and not picking up unreliable data). However, we have no specific project to move this forward at this time.--DataAnalyst 03:02, 25 October 2024 (UTC)

I'm very happy to hear that WR believes it has a distinct role to play in the genealogy community. Regarding the contribution required to avoid ads, I think the increase is very reasonable. I would give a lot more. One comment--for people who want to send checks, I think it would help to provide a telephone number for the Foundation. When I tried to set up a payee for my Schwab checking account, they wouldn't do it without a telephone number for contacting the vendor.--Julie Kelts 21:58, 25 October 2024 (UTC)

Planned Maintenance Nov 20-21 [24 November 2024]

Notice of downtime: WeRelate will be unavailable for searching, adding, and editing starting approx. 7:30 pm (MST) on Wed Nov 20 and continuing until the following afternoon (MST). This is to facilitate the implementation of a change in sort order for Person and Family pages, requiring a full re-index of the site. (See the roadmap for this and related changes.)--DataAnalyst 21:00, 5 November 2024 (UTC)

This is a reminder that WeRelate will be unavailable for adding and editing starting approximately 7:30 pm (MST) today. Code changes will begin as early as 7:00 pm (MST), after which time you may notice that the last change date shows as a date in 1970. This is due to one of the code changes, and will be rectified by the re-indexing of the pages. During the re-indexing (which we expect to take more than 15 hours), both sort by name and sort by date last modified will not work correctly.--DataAnalyst 15:35, 20 November 2024 (UTC)

Also, the site may become "read only" in order to help the indexing go faster.--Dallan 17:54, 20 November 2024 (UTC)

Searching is down for a while.--DataAnalyst 02:38, 21 November 2024 (UTC)

The site is available again. Thanks for your patience.--DataAnalyst 12:35, 24 November 2024 (UTC)

It's that season [20 December 2024]

Merry Christmas, everyone!

--Goldenoldie 12:47, 20 December 2024 (UTC)