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


Twins, triplets, etc. [10 March 2019]

Has there been any fields, routines or categories added which help to document or highlight twins, triplets, etc? --ceyockey 01:24, 6 February 2019 (UTC)

Uncertain Maiden Names [4 March 2019]

Hello. I've created a category and matching template to highlight people (women) for whom it is unclear whether their preferred name here on WeRelate is her maiden / birth name or her married name.

Regards --ceyockey 17:08, 2 March 2019 (UTC)

Would be interested in having people weigh in on whether they think this is a good idea or a waste or something in between. Thanks. --ceyockey 03:05, 5 March 2019 (UTC)

I am not sure how you are expecting it to be helpful? In documenting that a maiden name is unknown, it would be useful to review things you have ruled out, what you know, so providing standard text on the page may save some time, it is not very complete. For example, Person:Lilly Yockey (1), did you look her up in the censuses from 1870-1940 to find out where she was from and lived, and with whom she lived, and search for marriage records. And what is anybody going to do with the category? I don't see how this is any different than a person whose parents aren't known, persons for whom there are no sources, etc., in terms of being an opportunity to contribute research. And most pro-bono research going on seems to be focused on cleaning up old Gedcoms, anyway. --Jrich 04:20, 5 March 2019 (UTC)

Wikpedia template updates [4 March 2019]

Hi. What is the trigger(s) which result in updating of content of the Wikipedia content templates? For instance, https://www.werelate.org/w/index.php?title=Template:Wp-Francis_Parker_Yockey&action=history , which shows last update in April 2015? I was considering updating it manually, but didn't want to break any automated process in place. Thanks. --ceyockey 13:55, 3 March 2019 (UTC)

Wikipedia templates update weekly. If I remember correctly, they intentionally select only the first few paragraphs of the Wikipedia entry.--DataAnalyst 15:14, 3 March 2019 (UTC)
Actually I thought Dallan had to hand-start it. I page through Contributions for WeRelate agent back through June 2018 with out seeing any wikipedia activity and a quick search for a bunch of wp-templates modified on the same day suggests it hasn't run since 5 Mar 2017? --Jrich 17:25, 3 March 2019 (UTC)

---I believe Jrich is correct. The details in many "place" entries taken from Wikipedia are out of date. For instance, about 2015 Wikipedia contributors were encouraged to update populations in the UK from 2001 census data to 2011 census data. Many of these have now changed in Wikipedia but remain the same in WeRelate. --Goldenoldie 19:40, 3 March 2019 (UTC)

I just did an 'empty edit' on the template that I brought up as an example above. If that triggers an update, good. I'll let you know if it shows up on my watchlist. --ceyockey 20:52, 3 March 2019 (UTC)

It used to be that "new" additions of wp templates were updated on Sunday morning, adding the content for the first time, but I think pulling updated content was generally manual.--Amelia 00:38, 4 March 2019 (UTC)

Unless Dallan can tell it to just do one type, I think the bot usually updates both kinds. Some have references to items outside the scope of what is copied and those templates tend to re-break every time leaving big red text in the middle of the copied text, e.g., see this history. --Jrich 02:55, 4 March 2019 (UTC)

Dallan confirmed that updating is a manual process and asked if we wanted him to do it. I said yes, assuming that was the intent behind this posting. I assume that some templates will break again, but it appears to be the only way to get updates.--DataAnalyst 01:22, 5 March 2019 (UTC)

"A manual process" ... does that mean that the bot just needs to be started manually? Would it be possible for Dallan to invest some others in the community to be able to trigger the bot so that it is not dependent upon him alone? By the way - I'm not very concerned with wikipedia content pull being out of date; such content is a nice to have here rather than an essential. In fact, I'm of the opinion that a link should be sufficient; however, the licensing model of Wikipedia is definitely compatible with the bot-based replication. --ceyockey 03:04, 5 March 2019 (UTC)

Disappearing uploaded GEDCOM? [25 March 2019]

Okay, twice yesterday I uploaded the same small GEDCOM (~85 people) for review. And both times, it appeared on the "GEDCOM Review" list, just as it should -- and then, an hour or two later, it simply disappeared off the list, never to be seen again. So I uploaded a different GEDCOM. Same thing. Anyone have any idea what's going on? --MikeTalk 10:23, 25 March 2019 (UTC)

Just to follow up. It turns out that I broke the GEDCOM uploader when I started the wikipedia update yesterday. Since the wikipedia update takes several days to complete, I'd like to let that complete. When it does, I will turn GEDCOM import back on again.--WeRelate agent 23:14, 25 March 2019 (UTC)
Thanks, I'm not in a rush. It's just good to know what happened, and that it will end before too long. God knows, I've got plenty of stuff pending to fill up the meantime. --MikeTalk 23:59, 25 March 2019 (UTC)

Endogamous Common Ancestors [27 March 2019]

I would be interested in hearing about this subject. Perhaps you already know it, but it is labeled differently. Here is a short text presenting it.

Endogamous Common Ancestors A complement to Most Recent Common Ancestor

Endogamous Common Ancestors are groups of people in which loose endogamy is common over long periods. Loose endogamy is less visible than strict endogamy (e.g. marrying a direct cousin). It was certainly common practice in regions where strict endogamy was prohibited. One major factor was distance. Most people were living at throwing distance from their place of birth and moved further only when obliged to. There were people leaving or joining a group on a regular basis, but most marriages were among in-group members. This situation fits a significant part of human history. That is how DNA companies identify groups (e.g. migrants communities). But it is also possible to identify it in genealogies. Collaborating allows to develop genealogies of places, including sub-groups.

This concept is especially useful at the crossroad of genealogy and genetics. In genealogy, one finds a Most Recent Common Ancestor (MRCA) with somebody else if both made their homework. It works well for the first generations. In genetics, one is connected to unknown people, sometimes living at the opposite side of the world. Finding MRCA with these people is always tedious and often unsuccessful.

If people could exchange Endogamous Common Ancestors (ECA), it would make further research much easier. For instance, I have two groups of ECA from different regions (there might be others).--Jpictet 10:11, 27 March 2019 (UTC)

Looking for famous (?) people [16 May 2019]

I was looking for the formal way of linking Queen Victoria to the parish of Crathie and Braemar, where Balmoral Castle is located. In "Search" I entered Victoria under First Name and gave the Keyword "queen". Finally found her at #17 on the list! So much for the importance of Keywords.

By the way, Queen Victoria (1819-1901) was never Queen of the United Kingdom. The United Kingdom didn't exist until 1927. --Goldenoldie 14:43, 15 May 2019 (UTC)

Wikipedia shows the United Kingdom of Great Britain and Ireland existed from 1801 to 1927, when it became the United Kingdom of Great Britain and Northern Ireland (the current formal name). --robert.shaw 06:11, 16 May 2019 (UTC)
A keyword only asks "is this word anywhere on the page in any context?" And I think it uses the raw representation, so this is probably before inclusions? Then the matches are ordered. So all 16 ordered before it had victoria in the given name and queen as part of the page title (as does Queen Victoria), ones following do not. So clearly being in the page title counts more than being elsewhere on the page. I would guess the next sort has to do with length of the page title (shortest first, the thought presumably being that this means less of the name is unasked for, making it a closer to an exact match). Queen Victoria's page title, taken from the wikipedia page AT THE TIME THIS PAGE WAS CREATED, is longer than the 16 names in front of it so sorted after them. (wikipedia has since changed the title of their page, our title a vestigal side-effect what they used to use, probably yet another reason not to build such close associations with wikipedia). --Jrich 20:26, 15 May 2019 (UTC)

I was looking for a method to bring the result up higher in the search results listing and found that searching 'all' with the title value "Queen Victoria" returned no results, even when unrestrictive using the 'partial' parameter. This doesn't seem right ... or is it to be expected? --ceyockey 03:28, 16 May 2019 (UTC)

When I search the All namespace, I don't see a field for "Title", so I don't understand what you did. Were you in the Article Namespace? If I search the All Namespace (it also works if I search just the Person Namespace) and I put Queen and Victoria, both words, into the given Name field, it comes up first in the list. Not sure why this is so, because on the page, Queen is actually in the Title field, not the Given Name field? If I put "Queen Victoria" in the keyword field instead, in quotes to indicate I want the phrase, it comes up third. I can search the Person Namespace as the original search did (Victoria in given name, and queen in keyword), but add any detail, even the ridiculously simple ones that the birth or death place is England, and it came up first. I'm not sure what this is all driving at, anyway. --Jrich 05:37, 16 May 2019 (UTC)
The search engine considers prefix as part of the first name and suffix as part of the last name. --cos1776 01:31, 17 May 2019 (UTC)

Search All [16 May 2019]

This is what I see (using Firefox).



However, if I start on a different search, then use the namespace dropdown, this is what I see - very different, but likely what you see:


--ceyockey 01:10, 17 May 2019 (UTC)

I use firefox. Yeah I see the second one when I do a search all, haven't been able to get the first one. Author and title and "Covers" appear to come from the source search? --Jrich 02:09, 17 May 2019 (UTC)

Slo-o-o-w connection today [27 June 2019]

WeRelate is remarkably slow in changing pages today. --Goldenoldie 18:22, 27 June 2019 (UTC)

It is running quite OK for me at this hour 11:49 PM Eastern Standard Time (US) on the 27th. --ceyockey 03:49, 28 June 2019 (UTC)

"source: Domesday Book (1985) p xx" [3 July 2019]

In numerous place-pages for English villages and towns, the Alt Names field gives old names for the place followed by the reference

"source: Domesday Book (1985) p xx".

All sources agree that the Domesday Book was originally published in 1086. The date of 1985 refers to a popular edition published in that year (I think our household has a copy somewhere.)

Shouldn't we alter our reference to "source: Domesday Book (ed. 1985) p xx"? Could this be done by revising a single reference somewhere in our database? I have looked under Sources and Templates and found nothing. --Goldenoldie 05:26, 3 July 2019 (UTC)

Aren't you supposed to cite what you're looking at? Seems unlikely that many people have access to the edition from hundreds of years ago.--Tfmorris 06:17, 3 July 2019 (UTC)

It's online: https://opendomesday.org/ --Goldenoldie 06:52, 3 July 2019 (UTC)

The present reference to the source infers that the original was published in 1985, but that was not the first edition. Editions can vary, transcriptions can have errors, particularly over centuries. --Goldenoldie 06:52, 3 July 2019 (UTC)

You're right that editions can vary, and that is why I think these citations should remain much as they are. The page numbers appear to be specific to the 1985 edition, so they need to be preserved along with the fact that they came from that 1985 edition. I don't agree that "Domesday Book (1985)" implies that it was an original source first published in 1985. However, if you want to take the trouble to update the citations to "source: Domesday Book (1985 ed.) p xx" that would acceptable, perhaps even a slight improvement.
I also consulted https://opendomesday.org/. I found that it does not present the text in general in readable or copyable form, but rather just as images of (what I take to be) an original manuscript. Between the typography in it and the Old English, I find the manuscript unreadable. There are entries for individual locations, with modern English. I looked at one example, for Place:Wye, Kent, England. The WR Place page references the 1985 edition, page 150 for an altname of "Wi". The opendomesday does not index the "Wi" name, nor can I find a "page 150". It does have an entry for Wye in Kent, but I can't perceive a "Wi". This I think shows the importance of keeping the original source (1985 ed.) and page (150). --robert.shaw 18:20, 3 July 2019 (UTC)

Inquiry about GeoHack [28 August 2019]

I've put an inquiry over at Wikimedia GeoHack about whether the underlying code can be used outside the Wikimedia house. See https://www.mediawiki.org/wiki/Talk:GeoHack#Use_outside_the_Wikimedia_house . Have others inquired about this in the past? --ceyockey 01:35, 29 August 2019 (UTC)

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)

RootsFinder [21 October 2019]

I did login and create a minimum tree based on information for my father and his parents in RootsFinder. The site is very responsive and pretty intuitive. The cross-reference lookup against WeRelate is essentially instantaneous. I haven't taken a look at adding non-core information (birth, death, parentage) yet, but there is a detailed interface for doing this. For those having problems with FTE, having a skeleton representation in RootsFinder might be a reasonable solution as it would present a navigational interface back into WeRelate. Just a thought, and I'm not familiar with the details of Gedcom export and import, so not sure how easy it would be to export a skeleton Gedcom and import it into RootsFinder. Thought I'd share my observations. --ceyockey 23:35, 5 September 2019 (UTC)

ceyockey said "The cross-reference lookup against WeRelate is essentially instantaneous.".

I created an account on RootsFinder and imported some data from FamilySearch that is also already in WeRelate. I don't see this "cross-reference" you refer to; where is it?--fbax.ca 21:16, 20 October 2019 (UTC)

I believe ceyockey was referring to the "Hints & ToDos" entries. If you go to a person's page, if RootsFinder has found matches there will be entries with green circles on the right, one for each source, e.g. WeRelate, FamilySearch, etc. If you click an entry, more stuff will show, including a link to the WeRelate page. --robert.shaw 22:11, 20 October 2019 (UTC)
Some of the people I imported from FamilySearch have "Hints & ToDos"; but none of them have "Hints & ToDos" from WeRelate. Everyone in the tree I imported from FamilySearch is also in WeRelate; yet there are no hints from WeRelate. Perhaps link to WeRelate from RootsFinder has been dropped? --fbax.ca 01:51, 21 October 2019 (UTC)
OK, I imported some more people; including K468-X5K. A Hint from WeRelate appears pointing to Person:Theodorus Van Leeuwen (1); should have found Person:Hendrikus van Leeuwen (2). I guess the matching code needs some work! --fbax.ca 02:02, 21 October 2019 (UTC)

Problems with accessing Sources [20 October 2019]

For the last week, off and on, I've had problems accessing sources. Today, I keep getting the error message There was an error processing your search, or the search server is down; please try a different search or try again later.. Is there some way this can be fixed? Thanks, Gayel--GayelKnott 16:36, 16 October 2019 (UTC)

While it hasn't been an overly busy week for me, I have been on everyday, doing typical things, and for what it is worth, I haven't encountered this error once, nor have I seen it today. A similar complaint on the support page was made but claims it is fixed now. --Jrich 20:09, 16 October 2019 (UTC)
It comes and goes. Pat (GoldenOldie) said she had the same problem. It's annoying, and also worrisome, if it keeps happening. Gayel --GayelKnott 00:42, 17 October 2019 (UTC)
It has come again -- very, very frustrating.--Susan Irish 16:01, 19 October 2019 (UTC)

Me, too.--Goldenoldie 16:04, 19 October 2019 (UTC)

Still there -- for how long? And what happens as it spreads from sources, to people? Gayel--GayelKnott 01:42, 20 October 2019 (UTC)

Is anybody working on fixing this problem? --Susan Irish 03:50, 20 October 2019 (UTC)


The search server has gone done at least twice lately and Dallan restarted it both times (after some delay). He is aware of the problem and trying to figure out what's causing it. It is up right now. --DataAnalyst 23:05, 20 October 2019 (UTC)

Thanks. Having feedback is helpful/reassuring. Gayel --GayelKnott 02:24, 21 October 2019 (UTC)

Duplicate entries [27 November 2019]

Person:More II, Thomas (1) and Person:Thomas More (14) appear to be the same person. Would someone merge these records, please. I tried, but Person:More II, Thomas (1) did not come up as a match for Person:Thomas More (14).

[5 minutes later] Just found that Person:Mary Scrope (1) and Person:Mary Scrope (3), wife/wives of Thomas is also duplicated.

Thanks. --Goldenoldie 14:06, 27 November 2019 (UTC)

These have been merged.

Have a great Thanksgiving:)

Delijim 27 November 2019 (UTC)

Thanks, but it's not Thanksgiving here. We have to wait another month for turkey.

/cheers from England. --Goldenoldie 20:21, 27 November 2019 (UTC)

Strange source-naming error [29 December 2019]

I was creating a few new census sources this morning, preparatory to uploading a new GEDCOM that's going to require them. Doing the 1900 census for Norfolk, Virginia (i.e., "Norfolk (City)"), the system insisted on naming it for Suffolk County. I back-clicked and re-did the source and got the same wrong attribution. I finally just renamed the final result But then it did the same thing when I created the 1910 census source for Norfolk.

I can't even imagine what could cause this, unless it's some kind of weird linkage in the Places database. Anyone else have an experience like this? --MikeTalk 14:05, 1 December 2019 (UTC)

I've sometimes wondered why we need so many sources - a new source for each census district?

Why doesn't everyone use the first one with State and County in either the "Record name" or "Volume / Pages" field? Apparently I've used both of these fields: Person:Mary Sullivan and Person:Hazel Stevens. This applies to all census in all countries (USA, UK, Canada, etc); I just used these as an examples.--fbax.ca 22:41, 29 December 2019 (UTC)

I know some people here just cite "Census 1910 United States," and stick the rest of the citation in the details -- but most of us have always cited at the county level, because the film itself is organized by county. And also because that's the standard citation method required by the journals, and is also what Elizabeth Mills (among others) taught. I publish stuff, and I prefer to do it right the first time in my desktop software so I don't have to go back and change it later. --MikeTalk 01:03, 30 December 2019 (UTC)
I believe you may have to ask Amelia Gerlicher who seemed to architect a lot of the early source design with Dallan ("it's useful to have county level pages because free transcriptions generally exist at the county level, meaning it's useful to have county-level pages both as a finding aid and to discuss issues with a particular enumerator or transcription. I'm going to ignore the rest of the comments, since I'm done justifying a decision made two years ago" - from this discussion). I believe the number of counties that actually have any discussion is vanishingly small. Possibly the original concerns are obsolete because there is such ready access to online scanned images of census forms. I do it because that is what the help page says to do Help:Source page titles#United States.
Speaking from a very US-centric point of view, I think all 1900 censuses, to pick an example, used the same form, were administered by and are owned by the same agency. So I agree, the location could be in the record name field and you would still have a citation that names the census to the county level. This is what I do in my personal practice, and judging from various new pages I run across is what most people do, whether for the same reason or it isn't easy for them to cite censuses to the county-level.
It would be relatively easy to have a bot convert the current form to a form that treats the whole census in a single year as a single entity (remove county and state from title and place in record name field). Alternately if the current form is kept, a bot should create standard pages for all the counties. Most of the time I work outside of New England, the county's census records are only half populated, or less, which subliminally suggests the commitment to county-level census specification isn't all that great. Big picture, I would like to see "Census" be a Source Type on a par with MySource and Source, and bring up a popup that insures/encourages good citations and not just "1900 U.S. Census Population Schedule" with no link to an image, no ED and sheet number, leaving the reader to guess when they might have located the cited record. But software changes aren't happening much these days. --Jrich 01:29, 30 December 2019 (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? [25 May 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)