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. . . . --MikeTalk 21:05, 5 September 2019 (UTC)

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

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

Source quality [26 February 2020]

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

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

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

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

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

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


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

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

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

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

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

Computer cloud trouble [20 March 2020]

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

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

Can someone have a look, please.

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

Disappearing census references [17 April 2020]

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

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

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

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

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

How long have we got? [9 September 2020]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Map View [24 June 2020]

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

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

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

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

user and edit statistics [1 July 2020]

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

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

Without much fanfare, the plot results.

Image:WeRelate editing trends 2009 to 2020.png

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

Some other stats, if interested are here:

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

broken link in homepage footer [30 June 2020]

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

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

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

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

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

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

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

Hi all,

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

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

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

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

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

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

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

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

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

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

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

Wishlist or logic? [20 August 2020]

Hi all,

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

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

[1 September 2020]

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

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

Bury may refer to:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Image:Family Tree diagram - link.jpg

You will see:

Image:Family Tree diagram - expanded.jpg

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

Image:Family Tree diagram - person popup.jpg

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

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

Nifty new source reference Copy feature [26 September 2020]

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

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

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

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

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

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

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

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


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

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

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

New date edits [1 November 2020]

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

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

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

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

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

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

Poor Law Unions [3 November 2020]

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

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

New gedcom review in beta [12 December 2020]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Acting like a pack [27 April 2021]

hi all,

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

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

Let me know your thoughts.

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

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

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

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

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

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

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