WeRelate talk:Watercooler/Archive 2019

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)

• I've created Category:Multiple births pursuant to this question. --ceyockey 20:32, 10 March 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.

• Category:Uncertain maiden name
• Template:UncertainMaidenName

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

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)

Hi

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? --Mike^Talk 14:05, 1 December 2019 (UTC)

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

• United States 1900 Census
• Virginia, United States 1900 Census
• Northumberland, Virginia, United States 1900 Census

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