WeRelate talk:Watercooler/Archive 2017

Return to current Watercooler page

WeRelate Page Growth Statistics [13 July 2017]

For anyone who is interested, WeRelate has grown from 2,750,000 Person pages (July 2016) to over 2,824,000 Person pages (July 2017).

During this time, a significant (and ongoing) effort to comply with the "no living persons" policy and to improve data quality overall has resulted in thousands of pages being deleted, merged or updated.

A couple of rough measures of data quality improvement are:

The percentage of Person pages with first name Unknown has been reduced from 2.02% (July 2016) to 1.70% (July 2017).

The percentage of Person pages with no birth country has been reduced from 36.99% (Dec 2016) to 35.68% (July 2017).

--DataAnalyst 03:00, 14 July 2017 (UTC)

Based on your statistic above, I'm guessing you and cos1776 are working in opposite directions regarding the use of "Unknown" as a first name, e.g., Person:Unknown Triggs (1), and Person talk:Unknown Seaver (18). --Jrich 16:38, 12 February 2017 (UTC)

I don't think so. As far as I am aware, the reduction in the name Unknown is due to finding names for pages. At least, that is what I have been doing.--DataAnalyst 22:09, 12 February 2017 (UTC)

He is converting many pages to have given name Unknown, so increasing the number. Your choice of it as a statistic to measure and report on suggests you don't believe that is a good thing, that it is a measure of bad quality. The pages are, in the two cases cited, and many other, names that were never given, so not precisely unknown. To truly reflect pages where the given name is unknown, meaning under-researched, as opposed to never-knowable, the latter case should be given a different value or else they will always remain "Unknown", inflating the count. There are various practices that have been employed on this website for this special case, I believe Unknown is not appropriate. --Jrich 22:51, 12 February 2017 (UTC)

Metrics need not be perfect to be useful - particular when used to show change over time or some other variable.

I would certainly like to know if there's a different custom for a first name that is unknown at the moment versus something that is asserted to never be knowable. I treat both as "Unknown" at present, and suspect that's what folks have done for years. I suppose the key question would be whether there's a generally accepted best practice for such given names in GEDCOM files - if so - we would presumably want to follow that.

More generally - I looked for some other common forms for an unknown first name (typically in the case of stillbirth or infant death). Searching in the first name field: "Child" - 673, "Female" - 641, "Male" - "580", "Infant" - 1302, "Baby" - 537, "Boy" - 266, "Girl" - 224, "Stillborn" - 155, and "Unknown" - 30,628. So there may be another 1/10th of a percent that neither measure accounted for - but I assume the defect was approximately the same in both numbers so the delta is still meaningful. --jrm03063 18:28, 13 February 2017 (UTC)

Daughter - 846; Son - 837. "so the delta is still meaningful": some of the alternate forms are being changed to unknown. So while one set of cleaners is reducing unknowns, another cleaner is add unknowns, so the delta understates how much cleanup was done. Besides the question this raises about the validity of the statistics, the use of alternate forms has been intentional on many pages specifically to distinguish from unknown, and changing it to unknown loses that information. --Jrich 19:00, 13 February 2017 (UTC)

I wasn't aware that other ambiguous forms were being substituted in preference to "Unknown". My memory is that we never distinguished between unknown at present and unknowable - and that the proper form in either case was simply "Unknown". But no matter - the question remains whether there's an accepted GEDCOM best practice on this. Also, does historical guidance here at WR suggest different variants of unknown? --jrm03063 19:27, 13 February 2017 (UTC)

Keep going... we also still have roughly

• Dochter = 36
• Zoon = 39
• Levenloos = 152
• Levenloze = 60
• Doodgeboren kind = 14
• Wife = now 61, but was abt 150 that have either been sourced with a name or changed to Unknown
• Fru = 5
• Frau = 5
• Hustru = 2
• Vrouw = 2
• Miss = now abt 380, but was 432 that have either been sourced with a name or changed to Unknown
• Husband = 62
• Man = 5
• Mann = abt 20 where it means "husband"
• Første Mann = 2 (first husband)
• Unk = now 0, but was abt 200 that have either been sourced with a name or changed to Unknown
• FNU = now 0, but was 124 that have either been sourced with a name or changed to Unknown
• GNU = 3
• Unnamed or (Unnamed) = abt 225
• Naamloos = 4
• Not known = abt 50
• Not used = 2
• Not named = 9
• NN or N.N. = abt 1249 (Nomen Nescio)
• Anonyme = 19
• Inconnu = 1
• Unbekannt = 6
• Onbekend = 7
• Don't know = 2
• Young = abt 25 that are suspect
• and on it goes ...

There is no standard convention for this. Entry is based on user preference. Yes, I have cleaned a lot of this up and been mostly standardizing page titles to "Unknown xxx" when the given name is unknown for any reason as opposed to one of the words in the lists above. That is what our program defaults to when the field is left blank and the logical place to look for Unknowns in our wiki page lists. Most of these pages came in with old GEDCOMs, have zero sources, and haven't been touched since 2007-2009. For our site, the "quality" of a page is not only measured by the amount and type of genealogical proof attached to the data, but also by the ability of that data to function with our program and with other programs (if it leaves). Improving both of these is important.

Entering the simple word "Unknown" in the Given name field, as was pointed out, has been acceptable here since the beginning. Now, if you want to talk about that convention, I'd be glad to, because I would also like to see it changed. However, not in the way that is being discussed. In a nutshell, name fields are for names only! We should not be entering any placeholder words or made up names into any Given name or Surname fields for which we don't have a sourced name - not "Unknown" or "Unnamed" or "Stillborn Daughter" or "Levenloos kind" or anything else. When we do not know a particular name part, the corresponding field should remain blank. So, following this convention, the correct way to enter children with no given name, for any reason, is to enter just the complete surname they inherited from their parents in the Surname field and to leave the Given name field blank. Our software handles that just fine, as do other programs, and any confusion about what is being implied or in a different language, etc. is eliminated. There are other data fields on the page better suited to clarification when it is needed. --cos1776 01:26, 14 February 2017 (UTC)

Things like wife and husband should translate to unknown. Presumably if they lived long enough to marry, they had a name, and the poster didn't know it. This would seem to be exactly the definition of unknown. But that is different than the situation where a name was not believed to have been given, as in Unknown Seaver, female, formerly (female) Seaver who was born in 1865 with no name listed in the birth record and not listed with her family in the immediately following census in 1870 and had no gravestone in the cemetery where other family members are found on Find A Grave. Maybe there is no desire to distinguish between the two cases the result in having no name to post, but I am pretty sure distinguishing exactly that was the intent of the poster in using "(female)" as opposed to the unknown he uses on other pages.

Of course, there is no convention, and as will always be the case when there is no convention, that means everybody does something different. So the first step is to decide if this is significant, then, if it is, how to distinguish it from simply unknown. The fact that dataAnalyst was using Unknown as negatively correlated to data quality suggests it is significant. Maybe because users that are likely to be unaware of this rule can upload GEDCOMs, or because language variants provide too much variability, it is believed pointless to try. That is for the group to decide. Distinguishing data values don't have to be in the name field but that of course has the advantage of getting propagated to the infoboxes and erased automatically by the name if it ever gets discovered that a name was given. But there are other ways, one of them being the various title fields, or add a new fact type, or adding some template to the Narrative (a la nomerge}.

This is a relatively trivial matter, but for that reason, probably a good chance for the Overview Committee to start developing a process for developing such conventions and notifying the user community (is there one page everybody should be watching?) Date conventions are fairly detailed, but there are lots of other conventions that could use some serious discussion, like Married Name, like handling Intentions, like what data is best posted on the Person page and what data is best posted to the Family page. Wikipedia, as an example of a more mature wiki, has its usability is greatly enhanced by the fact that most town pages have similar outlines, most kings are presented in a similar style, etc. I believe similar attempts at standardization are needed here. --Jrich 02:35, 14 February 2017 (UTC)

Well, this is a case where a GEDCOM best practices document would help (for example, I'm pretty sure the GEDCOM spec is silent on the question of whether dates before 1000 should have a leading zero - and no one would want to write a GEDCOM interpreter that required a leading zero there - but a best practices document would give guidance on which form was preferred). So if GEDCOM proper doesn't dictate what Unknown ought to look like (I don't think so at least - unless their idea is that it should be empty). We should first make sure that guidance isn't lurking somewhere in that spec. If GEDCOM leaves specification of unknown up to the application/user - then we should probably look at conventions used by the more common Genealogy systems out there. Both web sites and desktop applications. This seems like a common enough situation that some practice will be found to be a little more prevalent than the others - and we should therefore follow whatever practice seems most common. Do GEDCOMs in the care of LDS follow a practice? If so, then, etc.... --jrm03063 18:54, 14 February 2017 (UTC)

I applaud the efforts of people working in the Data Quality Improvement project. This is the single best chance for WeRelate to make a difference in my opinion. Every time I investigate other sites, spoken highly of by various people, I continue to find inferior quality, and decide to stay right here at WeRelate. This particular project is the one that I think most adds value to WeRelate, and hope that at some time, the percentage of quality data might make this the site the one primary place where people will go to share new discoveries for review, to correct long-standing myths by providing evidence, and where we can build a culture that says what you know is not as important as how you know it. --Jrich 03:25, 21 December 2016 (UTC)

Thanks. I agree that quality has become somewhat of a focus of the collaboration efforts at WeRelate, and I'd like to see us fit that niche of where you go to find trustworthy data. We're still a long way from there for some of the old GEDCOM data, but where there is a high degree of interest in data (e.g., early New England and New Netherlands), I think we've got some pretty good quality. And where we're fixing up the old GEDCOMs, I know that we are ending up with parts of trees that are better researched than anywhere else available online.--DataAnalyst 13:11, 21 December 2016 (UTC)

Excellent ! Thx, Ron woepwoep 08:45, 21 December 2016 (UTC)

I also appreciate that there are folks willing to clean up whatever needs it. But when it comes to 'Unknown' I wonder about that as I use it a lot! And on occasion I've used terms such as Son or Daughter. Perhaps I've studied pre-1850 census records and know they had a son in the prior time but have not discovered the name of the child. At least Son or Daughter with est year period gives some info that I wouldn't want to lose by just saying Unknown. And to remove a page for a wife where the only name is Ann Unknown would really be destructive. Please tell me you are not removing that type of unknown page. On second thought that could be acceptable IF there were no children AND IF her first name is given on her husband's page. --janiejac 03:42, 13 March 2017 (UTC)

An aside: My computer says it is only 12 March 2017; 11:49PM --janiejac 03:50, 13 March 2017 (UTC)

I believe the UNKNOWN and multiple related usages of unknown names are an open discussion topic at this point. I think it is a maintenance issue which needs to be addressed because it strays from the WR standard. I'm not sure the use of "Unknown" is fully appropriate for all cases, but the list of unknown names above certainly shows that various usages need to be pared down to a more acceptable use standard.

Please consult this article about your off-topic aside relating to the use of UTC. --BobC 13:42, 13 March 2017 (UTC)

May I request that you move this discussion to a separate page, and offer a draft policy? I still do a lot of cleanup and would appreciate better guidance. --jrm03063 15:31, 13 March 2017 (UTC)

Ancestral File Number - perhaps not completely useless [13 April 2017]

Until this year, I had been preserving AFN numbers, even though I hadn't seen a use for them. I had changed that practice, but another contributor suggested that they have some worth. Digging in, I found that I was able to create the AFN template that turned the bare number into a (potentially) useful link. Examples of use include Person:Edward Gilman (1) and Person:Jacob Gates (17). If you're cleaning up a page, it's nice to at least use the template to make sure that a retained AFN actually corresponds to that person (I've found several incorrect AFNs). Valid AFNs seem to have a seven character syntax of the form "llll-ll". --jrm03063 21:28, 1 March 2017 (UTC)

Nice addition. Will you be adding usage and example to the Template page?--khaentlahn 21:39, 1 March 2017 (UTC)

Should...but won't prevent anyone else from doing so either... --jrm03063 22:02, 1 March 2017 (UTC)

As I've previously noted, I don't have a strong opinion on AFN. I formerly thought them utterly useless and dropped them when I had a Wikidata reference number to substitute. Another member of the community offered however, that they should be retained for the sake of folks familiar with LDS materials. That's ok by me, and seemed even more reasonable when I found that I could wrap them in a template, that turned them into a link to corresponding LDS legacy content.

Since then however, I've had a couple of such facts I wrapped deleted for reasons that seem arbitrary (not just the template, but the entire fact).

Honestly, I don't care a lot on this, but I want the community to weigh in. I don't want to waste time on them if they're worthless - but I'm not sure how worth is defined here. If the AFN maps to a corresponding name in the LDS world - that seems like it should be retained.  ??? --jrm03063 15:27, 13 March 2017 (UTC)

HEY - SOME HELP HERE? I'm trying to do "the right thing" regarding AFNs - but the community hasn't articulated what that might be. To my mind, that means keeping them when they point somewhere. One other person, is of some other mind. I'm only keeping them because other members of the community have expressed interest in their retention.

To look at pages where we have an AFN template, see this page

Unless something like a quorum chimes in - I'm going back to my old practice of blowing them away whenever I add anything substantive to a page where they exist. --jrm03063 17:43, 12 April 2017 (UTC)

The way AFNs work seems to have changed since most of the AFN references were posted, which may limit what can be done. But that said, given the way they work now, the template creates a useless citation. On Person:Roger Strange (1), the template gives you a search yielding "247 results for Ancestral File Number: 83TZ-QT". So the reader has no idea which of the 247 AFNs provided the data for this page. Undoubtedly the original poster had one AFN in mind, probably the first result listed. But wouldn't it be better then to unambiguously specify one item by using the URL that takes you right to it? Again that is assuming we have correctly identified which of the 247 items the poster meant.

That is all prior to considering whether it is worthwhile to even cite AFNs. Which has been hashed out before, but proper genealogical practices says if no sources are specified, then no, if yes, then it is better to inspect the sources and cite them, making the AFN superfluous.

I think it is wrong to delete an AFN before providing alternate sources for the information. There have been pages where it is necessary to locate the AFN in order to figure out what the intent of the poster was, i.e., the WeRelate page has little or no identifying information on it, and you need to find who the AFN says the person is related to, etc. But that is an immature page, and I think on a mature page, there should be no need for an AFN citation. --Jrich 18:34, 12 April 2017 (UTC)

I'm one of those WR users that would prefer keeping the existing references to the AFN. For the most part I look at the AFN as a "Finding Aid" for the individual referenced rather than a "Source" in itself, so why go to the extra work of deleting a finding aid for a person that may provide other users the ability to reference legitimate sources identified by using the AFN? So what if it points to 247 results. That tells me there may be 247 potential sources to add to the individual's record. The Wikidata number, of which you are taking tremendous time and effort in adding to WR person pages, in and of itself is not a source either, but it points to a compiled record of sources for that individual referenced in other places.

I say leave them be where they are unless they point to nothing. --BobC 19:20, 12 April 2017 (UTC)

The problem with this is the AFN is not a unique number identifying all instances of this person. For example 2CT3-857^? only brings back 1 instance of Roger Strange as opposed to the above. I also think finding aids should be listed on various portals, but not listed on individual pages. If every finding aid was to be listed, one could devise a query of all worldconnect databases that mentions an a person, and call it a finding aid. They tend to be of as at least as reliable as AFNs. Virtually everybody is in AFN, so why do we need to put a finding aid on all the page? The value people can bring to WeRelate is to process this type of data, turning it into information by culling it down, vetting it, and presenting it with credible evidence to support it. Citing AFNs is simply passing all that work onto the reader, meaning they may as well skip WeRelate and simply go search familysearch.org. --Jrich 20:39, 12 April 2017 (UTC)

Here's my $0.02. If there are no other sources on the page, I support leaving AFNs alone temporarily. I am guilty of removing them in the past, because of their lack of uniqueness, but I will leave them alone going forward if others wish to retain the ability to use them as a potential path to true sources. I don't think the template adds much in this case, so I will probably not spend time adding it. Once sources are added, AFNs become no more useful than other online tree links, so I would support removing them at that point. --cos1776 20:17, 12 April 2017 (UTC)

I've seen lots of strings represented as AFNs. Not all of them are - or at least - they're not all AFNs defined by LDS. I'm for wrapping an AFN in a template reference to show that I've verified that the string actually goes to a corresponding LDS page (and to make it easy for someone following me to see what I saw). When AFN strings don't resolve to anything - I definitely throw them away. The template could also be useful in letting us systematically find our way back to pages that have limited documentation (if that's what we're going to call an AFN situation).

If we're going to have a rule that AFNs can go away, when a page is more substantially sourced (or the person identified - which seems the real purpose of AFNs), it would be helpful to at least define a few examples of things that rate as "more substantial"? Presumably, a Wikidata identifier is a better identifier than an AFN, so perhaps we would drop it then. A cite to Cawley or History of Parliament is probably better. Even Find A Grave if an image of a contemporary memorial is provided. --jrm03063 16:47, 13 April 2017 (UTC)

I didn't know it was good practice to cite rather than point, so i am glad i am doing the right thing.

I don't think one is exclusive of the other - depending on what you're working with. --jrm03063 16:47, 13 April 2017 (UTC)

Some time ago i asked my premier source, www.geldersarchief.nl, if they have something like a permanent link to each of their records. They said yes we do - more or less - and then told me how to retrieve it. Still some of the records are duplicate information registered in different records for some reason.

So i like to copy the info from one or more of those duplicate records and referring to the source that www.geldersarchief.nl is also referring to. The different info is for example the many ways Anthony was written (Antoni, Antonij, Antonius, Toone, etc).

Thx Ron woepwoep 07:08, 13 April 2017 (UTC)

Stranger Than Normal Pipe Redirect [12 March 2017]

To whomever is in charge of these types of situations, I had a very strange pipe redirection happen. I attempted to enter a cemetery name (Mount Pleasant Cemetery, Brilliant, Marion, Alabama, United States -- which at the time did not exist) into the Burial field of a Person page. I refreshed the Person page and went to create the cemetery. Imagine my surprise when I was met with the attempted creation of Mount Pleasant Cemetery, Brilliant, Marion, Fort Rucker, Dale, Alabama, United States. I went back to the Person page to remove the pipe and test whether it was possibly user error that caused the fubar. No such luck. The pipe was created automatically by the system.--khaentlahn 03:17, 13 March 2017 (UTC)

FREE access this week to Irish records [16 March 2017]

In celebration of St. Patrick's Day, Ancestry.com has free access to their Irish records until 11:59 p.m. EST on 19 Mar 2017.
Happy Hunting, --cos1776 21:09, 13 March 2017 (UTC)

Information about Edward Thornton born 1644 Richmond Co Va died Accomack Co VA 1703

married Patience unknown family/children: Yes Go to site of Eastern Shore Public Library : www.ESPL.org, then select genealogy, then Miles Files, then Surnames, click on Thornton and scroll down results to Edward. Interestingly, none of your early family information is recorded here but takes it forward from Edward to my paternal grandmother Beatrice Louise Thornton, who married John Walter Young, parents of 4 sons (to include my father Norris John Young). Enjoy capturing this lost information for the We Relate site's benefit.

Leigh Chase, Sanford FL--LeighChase 22:23, 15 March 2017 (UTC)

Follow up - comment copied over to Edward Thornton's talk page, Person talk:Edward Thornton (1). --cos1776 18:17, 16 March 2017 (UTC)

Uploaded GEDCOM taking a long time [18 March 2017]

I must have been wrong when I assumed I had rights to get my GEDCOM accepted w/o admin review. It was always accepted so quickly before but today it is taking a long time. I uploaded it at 2:20 this afternoon and still is not accepted so that I can review it. I realize we're short handed or maybe my status has changed??? --janiejac 22:05, 16 March 2017 (UTC)

It looks like it may be stuck on Waiting for analysis. Normally I can review GEDCOMs just fine, but it's currently in a state where I can't do anything. It may need to be re-uploaded, but I'm really not sure.--khaentlahn 22:11, 16 March 2017 (UTC)

Janiejac - your admin rights have not changed. I put a request in to Dallan to take a look at that file, so hopefully we'll have an answer soon. He is still the go-to person for files that are stuck in the automated part of the process. In the meantime, can you re-create your GEDCOM under a new name name and try uploading again. If the 2nd version processes normally, please proceed with that one, and leave the 1st version as is. If the 2nd version gets stuck as well, please contact either Dallan or me and we'll go from there. Thanks, --cos1776 11:46, 17 March 2017 (UTC)

The system won't let me upload a renamed GEDCOM. I get this msg:

You have a GEDCOM already in process
Before importing a new GEDCOM you need to wait for your earlier GEDCOM to finish importing
I'll copy this exchange to Dallan's talk page. --janiejac 23:17, 17 March 2017 (UTC)

Follow up - Issue resolved earlier today. Server needed a re-boot. --cos1776 01:00, 19 March 2017 (UTC)

FREE access until Apr 25th to probate records [20 April 2017]

fyi - AmericanAncestors.org is granting free access to their probate databases Apr 18-25 to those who register as a guest (no further obligation). Happy Hunting! --cos1776 11:53, 20 April 2017 (UTC)

I believe some of the probate records are free all the time because of various agreements that were made while getting access to the records, either with the government agency or the Mormon church who is a partner. Since I am a member of americanancestors, it is not obvious to me which records are restricted, so I cannot give any insight into which areas are particularly benefited by this special promotion. I know some counties in Massachusetts are always free.

Since I feel probates are one of the best tools of genealogical research, not just the wills but receipts and distributions, I will also add that many probate records are always free at familysearch.org. Go to catalog search, enter the place name and subject probate. Find the entries whose author is a government agency and browse the list of films. If the icon is a solid film reel it is viewable online by clicking the icon. If the icon is an empty film reel, you can still order it to be viewed at your local Family History Center. None of this requires any affiliation with the church, though ordering films will require creating a free account and a small rental fee per film.

The viewable probate records are rarely indexed so you have to search the old fashioned way. Use the film of the index to get a case number, then go to the film of the dockets and find where all the documents for that case are recorded. Then click on the film for each record volume and jump to the indicated page. Some counties do things slightly differently. If your county has files, you can probably find all the original documents in one place, instead of jumping through several films reading copies as recorded by the clerk. --Jrich 13:40, 20 April 2017 (UTC)

I will also add that typing a transcript or abstract of a will from a film is a big service to the entire genealogy community, not just WeRelate, as it makes something that is non-searchable into something that search engines can process. So if you read a will and it doesn't help you, it is still worthwhile to post the information on the appropriate person page. Include the link and future readers of the page can add their insights into the often challenging task of interpreting handwritten documents. --Jrich 13:46, 20 April 2017 (UTC)

Problem with display of Duplicates page [27 April 2017]

There seems to be a problem with the display of the Duplicates page ( http://www.werelate.org/duplicates/families.html ) It starts : "I+and+Morning+Unknown+%281%29">", and is very truncated. Can this be fixed? Thanks, --GayelKnott 18:24, 27 April 2017 (UTC)

I have made some tweaks, but since that report only gets updated every 24 hours (I think that's right), I am not certain sure if my tweaks have improved the situation yet. Let's check back on it tomorrow. In the meantime, it is ok to work on the pages you can access. That shouldn't adversely affect anything. Thank you for staying on top of the duplicate report. Your help is much appreciated. --cos1776 21:20, 27 April 2017 (UTC)

Excellent tweaks! Thanks, Gayel--GayelKnott 00:16, 28 April 2017 (UTC)

Wikidata - in case you're wondering... [21 September 2017]

By now, I expect that most active users have seen me placing references to a Wikidata template on Person pages associated with people found in Wikipedia. From time to time I have offered partial explanations of what I had in mind - but nothing systematic. I would usually indicate that my idea involved some level of software supported analysis.

I was reluctant to go on too much about this previously - because I didn't have a handle on all the pieces I expected to need.

I've now reached a point where I've established a subset of content and created an initial support program. People interested in seeing a more complete explanation of what I'm doing can find it here. --jrm03063 22:03, 9 May 2017 (UTC)

Thanks for the explanation. --GayelKnott 00:26, 11 May 2017 (UTC)

Highly interesting blog post on "Library Metadata Techniques and Trends", by Thom Hickey. As a practical matter, we have been using English Wikipedia as a subject registration service for WeRelate. When we source a page from the English Wikipedia, for the sake of a Person: page, we're making a strong assertion about EXACTLY who we mean by the person for that page. This arose naturally from the rationale for the original Wikipedia Person project - trying to de-duplicate and make sense out of large spaces of older era genealogy that were uploaded with almost no practical source support. The blog entry offers an explanation of the relationship between Virtual International Authority File (VIAF) and English Wikipedia - and explains their shift from English Language Wikipedia to Wikidata. This explanation is very much what I might have hoped to offer this community, substituting WeRelate for VIAF.

I see an important opportunity here for the longer-term relevance of WeRelate, in the WikiMedia information universe. The various language versions of Wikipedia have created many thousands of useful biography pages. Wikidata has appropriate properties and is well suited to objectively representing the genealogical connections among those pages. However - efforts to obtain the genealogy information from the various language Wikipedia pages have been haphazard. A lot of information has been obtained to be sure - particularly for pages where templates nail down parents, siblings, children, partners, etc. - but vast numbers of biography pages are not equipped with that organization. The effort to bring in English Wikipedia to WeRelate Person: pages - for the pages so included - gets past that problem in the MediaWiki information space.

Using WeRelate Person: pages tagged with Wikidata identifiers - I have been able to determine and create 4000 new genealogy claims in Wikidata. Another 5000+ claims are pending a more efficient process of uploading them to Wikidata. As more WeRelate Person pages are tagged with Wikidata IDs - we will be able to easily recognize missing genealogy claims from the Wikidata/WikiMedia and generate dumps for automatic upload to Wikidata.

Without even becoming a MediaWiki project - WeRelate could yet become important to genealogy in the MediaWiki space. Perhaps - we need not choose between a slow fade to irrelevance or surrender to the WikiMedia collective??? :) ? --jrm03063 18:24, 7 July 2017 (UTC)

21,500 "Person:" pages associated with unique Wikidata IDs for instances of "human" with matching gender. 4870 "Person:" pages still to visit ("source-wikipedia" is present but "Wikidata" is not). --jrm03063 21:32, 26 July 2017 (UTC)

25,080 "Person:" pages associated with unique Wikidata IDs for instances of "human" with matching gender. 2660 "Person:" pages still to visit ("source-wikipedia" is present but "Wikidata" is not). --jrm03063 19:46, 29 August 2017 (UTC)

And how many are like Person:Josiah Byles (1) who has no identifying information, whose wikidata corresponds to no Wikipedia article, and who is shown married to a person without showing that he is her second husband or giving her name at the time of marriage or the location of the marriage. How many people like this exist that people like me that practice genealogy to honor our ancestors, as opposed to people that practice genealogy for purposes of self-aggrandizement, have to clean up? --Jrich 02:34, 31 August 2017 (UTC)

A property Property:P4159 for Werelate has now been created in Wikidata see example Albert Einstein Wikidata Q937#P4159 - Salgo60 20:38, 10 August 2017 (UTC)

Unfortunately, Albert Einstein is a relatively poor example of a WeRelate page to link between the two sites to show the benefits and features of using WeRelate as a Wikidata resource property. As one commentator wrote in the Wikidata Person ID discussion page, the WeRelate version is only a mirror of the Wikipedia page (true in the Albert Einstein case). I added a couple other page references at Wikidata's WeRelate Person ID page to try and show WeRelate's strengths and usability features, highlighting pages that show the incredible versatility here, our emphasis on recording source citations, and which display some unique aspects of linking to WeRelate pages. --BobC 16:08, 13 August 2017 (UTC)

I don't really expect WeRelate pages - that correspond with WP pages - to offer much beyond the WP page proper. They could of course - but I don't see that as their immediate value. Instead - they allow a user to drop into a genealogical context that is as large as anyone cares to create - without notability limitations. Information on Albert Einstein proper isn't going to be all that hard to find. Information more than one immediate relationship beyond on the other hand... --jrm03063 17:20, 13 August 2017 (UTC)

Quite true, and that was the unwritten context of my remarks that I probably took and expected others here to take for granted, that the primary focus here would be on the genealogical rather than the historical. And as I see it, that is the value of having WeRelate being identified as a Wikidata resource link. The linked WeRelate page, ideally, could/would provide that genealogical resource niche that may be unavailable, unimportant or under-stated in the historical resources used --- which the Albert Einstein page here does not do in any way, so in my opinion is a poor example to use in highlighting our site's strength and uniqueness. The page has no identified family members shown, has no "What Links Here" connections, and is basically a useless placeholder until family links are added. --BobC 17:47, 13 August 2017 (UTC)

I added a suggestion that also the SQUID interface to Wikidata is a good option for learning about a profile see Template_talk:Wikidata As we have the Wikidata Q number it's easy to link to SQID Q202266 that I feel is an easier way to read Wikidata - Salgo60 10:55, 14 August 2017 (UTC)

Reason we don't see a clickable link to WeRelate I guess is because the WeRelate property is new in WIkidata and we have to wait on next batch run SQUID does.... - Salgo60 10:58, 14 August 2017 (UTC)

Status update 2017 aug 17 Wikidata property:4159

1. We did a test load of 1000 more profiles ==> we have 1562 entries in Wikidata connected see blog for search
2. A Wikidata Database_reports Constraint_violations report on P4159 has been run
   1. We have some duplicates - "Single value" violations - that I will fix...
   2. We have set up requirement that we should link to xxxx ==>
      1. human who may be fictional (Q21070568) - found 2
      2. mythological king (Q6949213) - found 2
      3. legendary figure (Q13002315) - found 1
      4. Norse deity (Q16513881) found 1
3. I did a small test with a template that links to SQID a more userfriendly user interface see
   1. Template:WikidataSQID
   2. used on Person:Pontus_De_la_Gardie_(1) ==>
      1. link link SQID Q202266
      2. compared link Wikidata Q202266
      3. compared to link Reasonator Q202266
4. A new dump of SQID has been done so the link to Werelate should work

- Salgo60 13:21, 17 August 2017 (UTC)

Status update 2017 aug 22 Wikidata property:4159

1. Now 25 178 Werelate profiles are connected to Wikidata see blog. Some cleaning is needed - Salgo60 11:26, 22 August 2017 (UTC)

• Properties also found in WIkidata connected to WeRelate query result query

?property wdt:P31 wd:Q19595382

Properties about authority control for people - Salgo60 13:24, 22 August 2017 (UTC)

• As Wikipedia is updated rather fast we also can now query if any WeRelate connected profiles has died see Recent_deaths_WeRelate

Status update 2017 Sep 21 - the Wikidata tagging effort is approaching a milestone! Unique Wikidata tags are present on almost 1% of the total set of Person pages (28,270 of 2,843,074). The list of Person pages returned by a search for "+wikipedia-notice -Wikidata" has been exhausted (the remaining dozen or so pages are associated with a WP pages that are not biographies). Futher pages will be tagged - or added and tagged - on the basis of information from my WeRelate <-> Wikidata comparison program. The program tentatively indicates 9700 family connected person identifiers on Wikidata - which are not yet present on WeRelate. The program also reports - on the basis of WeRelate family connections - that WeRelate could contribute about 14,960 new relationship claims to Wikidata. Work continues... --jrm03063 23:35, 21 September 2017 (UTC)

Crowdsourcing Challenge Update [2 August 2017]

Since the WeRelate Crowdsourcing Challenge page is being followed by only about a dozen users and has gone through some changes over the past year, it was suggested to me that I should promote the page here to a wider audience and encourage other users to participate.

Last month's Challenge highlighted historic Memorial Day personalities, General John A. Logan, who proclaimed the first Memorial Day observance in 1868 (then known as Decoration Day), and Ms. Moina Michael, who conceived the idea of wearing red poppies on Memorial day in honor of those who died serving the nation during war. WeRelate users Khaentlahn and Btomp made the most additions and changes to the two pages and were awarded Challenge Badges.

This month's Challenge focuses on two patriots who were instrumental in creating and celebrating the United States flag, Philadelphia seamstress Betsy Ross, who as legend has it sewed the first stars and stripes flag 240 years ago this month, and Wisconsin dentist Bernard Cigrand, who is credited with being the "Father of Flag Day," which celebrated on June 14th every year.

All users, new and experienced, are invited to participate in the Challenge. The Challenge is intended to be a fun, educational and rewarding way for WeRelate users to strengthen their genealogy research skills, enhance wiki-page proficiency, work toward data-entry mastery, and provide practical experience in validating and substantiating factual events with supporting sources in a friendly, collaborative, crowdsourcing environment. Highlighted pages now change monthly. (You can view some of the past subjects and winners the contest/challenge has highlighted over the past five years.)

Come join the challenge. --BobC 13:56, 1 June 2017 (UTC)

User:Sorghumgrass got the Oscar for last month's WeRelate Genealogy Challenge by winning all four challenges, making the most edits to the leading men of actress Olivia de Havilland's movies of the 1930s. Olivia celebrated her 101st birthday in July.

This month's challenge should be a delight to all beer drinkers, highlighting the family history and lifetime achievements of Eberhard Anheuser and Adolphus Busch. Everyone is invited to join the fun and collaborate in bringing life to the WeRelate pages on these two renown beermakers. --BobC 01:01, 3 August 2017 (UTC)

There seems to be a computer problem with the Duplicate Families Report [17 June 2017]

For over a week, the report appears to be truncated, cut off at "Multiple Parents R". Among other things, this means the multiple spouses on the same page are not being reported. --GayelKnott 14:47, 15 June 2017 (UTC)

Follow up: "Multiple spouses J" is listed in yesterday's report, so I think this issue is resolved. It still cuts off at "Multiple parents R", but I think that is accurate for now. If that is not the case, please just let us know, and thank you again for staying on top of the Duplicates report. --cos1776 12:10, 17 June 2017 (UTC)

Thanks. It still seems shorter than it should, but at least it is picking up some of the Multiples Spouses. --GayelKnott 01:51, 18 June 2017 (UTC)

Where is the request features page? [29 jun 2017]

hi all,

i am very fond of the http://www.werelate.org/wiki/Special:ListPages/ pages. i was wondering if i could have another page beneath where i could find my family pages?

where should i post such request pls? i could not find such page from the main page

thx Ron woepwoep 21:55, 28 June 2017 (UTC)

You did already. WeRelate:Suggestions/List of families. However, with a large backlog of suggestions and apparently no software development going on, it may be a long time coming. --Jrich 22:01, 28 June 2017 (UTC)

thx @Jrich

any way i can help?

i am wondering if wiki is the right way to enter the future.

is it still on course with developments like MVC and DDD?

don't know, just asking.

thx Ron--woepwoep 22:11, 28 June 2017 (UTC)

Try using the Search page. Put Family in the namespace and your user name in the keyword field. --Judy (jlanoux) 00:21, 29 June 2017 (UTC)

This (pretty much) works if you use the prefix and exact user name ("User:Woepwoep"), but not just user name ("WoepWoep"). If you are logged on, you can get the same result, it appears, by skipping the keyword field but choosing "Watched only" from the drop-down list at the right. --robert.shaw 01:13, 29 June 2017 (UTC)

yes thx. the list is so great because it allows me to search for ABT while ordering dates old to new. woepwoep 02:53, 29 June 2017 (UTC)

Consensus on features to implement this Summer? [3 July 2017]

Can the group come to a consensus on a list of features to implement this Summer? An ordered list of 3-4 suggestions would be great.--Dallan 03:13, 29 June 2017 (UTC)

+1

a list of families, like a list of persons, would be my #1

alternative = that in the search box i can search for the string 'ABT' (case insensitive) combined with following gives me the list of people and families to further investigate.

thx Ron woepwoep 03:31, 29 June 2017 (UTC)

I've also had a request to filter out cemeteries when entering a place name for any fact other than Burial or Alt Buria--Dallan 04:04, 29 June 2017 (UTC)

Source text boxes allow a simple carriage return to define a new line. The Personal History box does not, and I wish it would. I am forever adding <br> to other people's gedcom-delivered notes to make them more readable.

Alternately, the Personal History box has icons for bold, italics, links, etc. The Source text boxes don't. Bold is useful in Source Text to identify the Person in question in a list of family members taken from a census.

Regards, --Goldenoldie 09:45, 29 June 2017 (UTC)

Not sure of the coding reasons for this, but functionally these two boxes are different and some of those formatting functionality is in recognition of those differences, e.g., listing census records versus writing flowing prose. But this is probably not the best place for a discussion of the pros and cons of each user's favorite ideas. I know DataAnalyst recently did an extensive review of the suggestion list, and suggest getting her input. What is the method for establishing consensus? I thought the number of people watching suggestions was going to provide a measurement of this. --Jrich 13:28, 29 June 2017 (UTC)

Could we have a "form" similar to the one used a few years ago ? Once the list is determined, all of us can check the features we prefer, beside our user name. On the Find A Grave Template, I'd like to see something other than "Vol/Pa" in the space where the Grave link is placed.--SkippyG 15:34, 29 June 2017 (UTC)

Jrich is correct. We already have a process for submitting and voting on Suggestions that works pretty well when the resources are available to do the programming required for most of them. That has been the missing piece for a while. The good news is that we have some help on the way now, so please take some time to review the WeRelate:Suggestions list again, both to vote for or update those that already exist and to add your new suggestions to the list. Many date back a few years and may no longer be relevant. It would be very helpful if we could get a more accurate idea of what the community considers to be most important today. Thanks for your help, --cos1776 16:09, 29 June 2017 (UTC)

Is there any possible way to get a list of all the suggestions that I'm watching? If so, would make it easier for me to put them in some kind of priority list. But, yes I thought the number of watchers kind of created it's own priority list. But I realize even that list has to be filtered by what is doable and suggestions too complex or time consuming will drop off the list. So the 'most watchers' list should be compared to our personal 'would be most helpful' list to create a final list for us to 'vote' for with Dallan having the final say. --janiejac 23:25, 29 June 2017 (UTC)

Yes, it is possible to see all the suggestions that you are watching. Do this: Go to the Search dropdown "All" page; on that page, select the "WeRelate" namespace; in the "Page title" box add "suggestions"; check the "condensed" option; select "Page title" Sort-by option; select the "Watched Only" option; and press the Search button. --robert.shaw 21:32, 2 July 2017 (UTC)

Thanks! That does help. Since I like/watch so many of these, I want to better prioritize my wish list. Since we can't have it all perhaps it will help if we all pick our 10 most wanted. Such a condensed list might be more reliable than an just counting watchers on the older list. If everybody would post your 10 most wanted list, I'd be willing to help count and sort everybody's list for DataAnalyst. --janiejac 01:11, 3 July 2017 (UTC)

The highest priority based on "votes" (people watching) is to remove cemetery places from all place prompting other than for burial/alt burial facts. There is no discussion that would make us hesitate to do this one, so I would suggest that Dallan start with this while we allow the community to prioritize the rest through the "watching" system.

Based on a recent analysis, I would suggest that to-date, the other priorities that are ready for Dallan to work on are:

• change handling of edit conflicts (8 watchers)
• ability to merge MySource pages with regular sources (7 watchers)

By the way, I recently merged several MySource pages with Sources with seemingly no problem.--SkippyG 23:52, 2 July 2017 (UTC)

Other priorities either do not require programming work (e.g., Assertions, which I believe requires agreement on conventions), require a bit more work to settle on the exact request, or require extensive work (e.g., upgrade Wikimedia).

The assertions don't need any programming support - nor do I think there's any special benefit (for them) in the wikimedia upgrade (though I support upgrades to SW infrastructure in general). They could benefit from a slightly more nuanced fact sort - that made use of both date and fact type. For example, the reference number fact really belongs at the end of the fact list display. A residence fact, even absent a date, should appear after birth and before death, etc. Beyond standardizing the input and display of some types of facts, the assertions can be used by software that works over the WeRelate database. At present, I rely upon the Wikidata and CohabitationWithoutFormalities assertions for a program that compares WeRelate information with equivalent content in Wikidata. The "TwinBirth" template isn't presently used by software, but could be used to recognize when multiple simultaneous births are not in error. --jrm03063 17:43, 30 June 2017 (UTC)

If anyone has a strong objection to having Dallan starting with the 3 suggestions above (cemetery places, edit conflict and merging MySource pages), please add your comments to an alternative suggestion (not this page) to champion why it is important, and/or watch if it is already explained adequately. I will try to find time over the next few weeks to review suggestions with more than 5 watchers to determine the extent of consensus and to see if we can make the requests crystal-clear where there is reasonable consensus.

Stay tuned.--DataAnalyst 01:46, 30 June 2017 (UTC)

French accented characters [5 July 2017]

Can someone tell me how to present French accented characters (like "é") in WeRelate? Right now I am using copy-and-paste, but it is not always convenient.

Is this a topic in a FAQ somewhere?

Thanks. --Goldenoldie 12:54, 1 July 2017 (UTC)

i use keyboard US-International then when i type ' followed by e i get é--woepwoep 13:02, 1 July 2017 (UTC)

I have a "Cheat Sheet" page in my user profile. I made this many years ago when I was new at the wiki. In there, I have a list of all the characters and what to type for them. For example: your é is typed: & eactute ; (all joined together) (Can't get nowiki to work!) If you know the names of the characters,this is pretty quick and you don't have to change keyboards. --Judy (jlanoux) 13:56, 1 July 2017 (UTC)

Many thanks. Judy, I have bookmarked your cheat sheet. The vitals ones have been copied to mine. BTW, your link to Excel to Wiki is now dead.

/cheers, Pat --Goldenoldie 14:52, 1 July 2017 (UTC)

I usually just copy-paste from http://www.ascii-code.com/ which contains what I need for doing transcripts. -Moverton 16:53, 5 July 2017 (UTC)

Do you wish that WR pages loaded faster? [4 July 2017]

This is a shameless campaign for votes for the recent request WeRelate:Suggestions/Site speed - request for faster loading. If you are tired of waiting and waiting (some days) for pages to load, open or save, please consider casting your vote to implement the suggestion above by going to the page and clicking "Watch" in the left menu. If improvements can be made, we can all be more productive.
Thank you for your consideration and Happy (almost) 4th of July, --cos1776 15:03, 3 July 2017 (UTC)

Already voted! The length of time it takes for pages to load more often than not is a major pain. Would also appreciate an explanation of why. --GayelKnott 15:11, 3 July 2017 (UTC)

Would this improve the following. Sometimes when I get "on a roll" entering a dozen or so children on a Family page, I get a message saying I'm entering info "too quickly", or is this another issue ?--SkippyG 00:26, 4 July 2017 (UTC)

I think that may be another issue having to do with the page change limits set by the program as a way to stop spammers. I am not certain if page loading time is part of the calculation, but even if it is, the rate is usually set such that humans do not normally achieve it. Personally, I have never encountered that message. You must be really fast! :) Has anyone else encountered that message and does it happen on a regular basis? --cos1776 17:50, 4 July 2017 (UTC)

Suggestions: Upgrade MediaWiki [13 September 2017]

Concerning the Suggestions/Upgrade MediaWiki. After reading the current status on this suggestion, I feel the need to comment that those who favor this suggestion need to 'sell' the rest of us on the idea. It might be a great idea but it will be expensive and need community support. So if you really want this to be implemented, tell us the advantages and disadvantages of it. Tell us why we should rally around this idea. Or not. --janiejac 23:04, 3 July 2017 (UTC)

Even if it's perfectly functional - older software infrastructure becomes problematic as time goes on. People won't be testing it with and alongside newer systems - it gets harder to find people who really want to work on it. If you encounter bugs - there's really no chance of getting them repaired. All that is true even if we don't take advantage of any of the capabilities of a more modern version of MediaWiki software. I believe that newer MediaWiki software has a programming API - which would certainly facilitate things that I've been trying to do. I can do most of what I want with some brute force approaches - but newer software running the WeRelate server might make my life and tasks easier. --jrm03063 23:46, 4 July 2017 (UTC)

jrm - I hope you don't mind that I added a link to your comment (no objection - --jrm03063 :) ! ) 16:49, 5 July 2017 (UTC)). Right now, WeRelate is like a VCR player. You might have a TV setup at home that still works fine with the VCR and you might only have a little trouble finding a repairman around who is still willing to work on the VCR if it breaks. But when you go to upgrade your TV, you are going to find that most will not connect to your old VCR without special adapters and some will not connect at all. If you can make a connection, you might find that the video quality is not as good as it used to be, and the only VCR tapes you can find are at yard sales and second hand stores. In a few years, you will no longer be able to find any TVs that can connect or any repairman who can help and you will no longer be able to watch videos using your VCR. Our database is like the video and our infrastructure is like the VCR. Those who wish to upgrade the infrastructure recognize that if we want to keep being able to access the database that we have all worked so hard to create, we must keep upgrading our method of access. If we say that we are not going to upgrade, then we are agreeing eventually to be obsolete.

Rather than rejecting an upgrade completely, I wish we would explore alternative solutions. WeRelate has been heavily customized which makes it more difficult to upgrade. At one time there was talk of re-examining many of those customizations to see if anyone is actually using them or if they could be stripped out or modified. I don't think that was ever fully fleshed out. If we want to open up this conversation again, I would recommend that we begin there - what do you use most frequently and what can you live without? I'm sure the answers will be varied, but I would bet that we can settle in on some features that can be eliminated to streamline an upgrade. Would y'all like to open up that conversation again? --cos1776 15:57, 5 July 2017 (UTC)

It's definitely appropriate to see what features have really proved useful - and which ones didn't pan out. That would important even if we were not looking at an upgrade - it might let us cut down the size of the code base that we have to maintain. But fortunately and unfortunately - WR has so blended in with what's in an ordinary Wiki - it's not easy for those of us (who don't know the code base) - to know what parts/modifications WR carries beyond the base MediaWiki software. Of course there's the explicit support for GEDCOM-style content in customized Person and Family pages - along with code that automatically creates reciprocal family links (for example - adding a child to a family automatically adds a link from the child to the family). But what else is out there - and how does it work? Is there a list of upgrades that constitute how WR upgrades the base Wiki - such that we can discuss the utility of different parts of the system? --jrm03063 16:49, 5 July 2017 (UTC)

Seems like I remember such a list from a few years back, but I am on my way out the door, so will have to do some more digging later. In the meantime, the base code is posted at Github. --cos1776 17:02, 5 July 2017 (UTC)

Does somebody need to set up some kind of list of features that we could check off - like yes I use this, or no I don't use it? For example, I never use the Family Tree Explorer function. Maybe I'm missing something good, but it just never clicked with me. --janiejac 02:57, 9 July 2017 (UTC)

Janie - I believe that FTE is the only way to copy a tree from one user to another. So when you share your tree with someone else, they have to use FTE to copy it so that they are watching all the pages (without having to watch each manually). That is about the only thing I use FTE for.--DataAnalyst 03:36, 9 July 2017 (UTC)

It would be nice if someone could define the cost. I assume there would be parallel development until all of the existing features of WeRelate are incorporated into the current version of MediaWiki software, followed by moving the data over to the new system. -Moverton 17:04, 5 July 2017 (UTC)

Cost - see the updated suggestion - it is in there. Given the limited resources for software development, I would assume that if we could raise the funding for this, all other development would halt until the upgrade was complete and critical bugs introduced by the upgrade fixed (preferably as much in the Sandbox as possible, rather than on the live system).--DataAnalyst 03:09, 8 July 2017 (UTC)

Is any attempt being made to develop a contingency fund for when we do need major upgrades just to stay viable? Personally, I would rather forego smaller upgrades, or pay for them through an annual fund raising campaign, while also trying to build up the funds that will be needed for a major upgrade.--GayelKnott 04:35, 9 July 2017 (UTC)

I'm with Gayel on this. We may be concentrating on small suggestions and improvements while ignoring the risk of becoming obsolete because we failed to update the software. I don't know programming but this talk of VCRs becoming unusable brought home the importance of staying up-to-date. We don't know how much Dallan envisions being available for summer improvements. Perhaps knowing how much is available to work with would help the discussion. Just looking at the suggestions list, I realize that software updating is high on the wish list! Maybe we should look into this a bit deeper before writing it off as impossible. --janiejac 17:48, 9 July 2017 (UTC)

Ouch! I should have read that suggestion more thoroughly! That cost is a big hurdle! No volunteer programmers around??

I encourage others to join me in making a recurring financial commitment to WeRelate. I don't know that we have anyone around with a spare $5K-10K in cash or services - but more people making a regular monthly donation could really add up. I don't like formal pledges like they do with public broadcasting - this is just deciding to cut an additional tiny check at monthly bill time. Using my credit union's bill payer system - a couple mouse clicks and done - no surprises on your credit card bill. Routine, pain free, and easy to document as a charitable donation at tax time!

Look at it this way - Dallan's wife (I think?) cashes the checks I send each month. She's already going to the bank - so go ahead - send a $5 or $10 check! --jrm03063 14:57, 10 July 2017 (UTC)

Sounds as if the software update is the most important thing we should do, but I don't think we'll get the donations to tackle it in the next month or so. If some others are like me, I pay my "No-ad" fee and add a little extra as I can afford; I can't do a monthly (perhaps an additional donation), even though $5 or $10 doesn't sound like much. Should we have a year-long campaign, with donations earmarked "general" or "upgrade", and see where we stand at the end of the year ? In the meantime, improvements that are less dependent on the upgrade could be done now. Neal--SkippyG 17:07, 10 July 2017 (UTC)

I only offer the recurring donation suggestion so that people will think about whether it's something they can do. I realize that won't be everyone... --jrm03063 18:10, 10 July 2017 (UTC)

As a matter of curiosity, is there any way to count the number of 'active' members? A year or so ago when folks were so upset about embedded ads, there appeared to be enough people willing to donate something in order to take care of the site, but when nothing came of that, now I wonder how many are left to be still interested and willing. Any way to tell? There is a big difference between the potential to raise $ from 500 people compared to 30 people. So what are are chances?

Could we accumulate some pledges? I'm willing to pledge to give a certain amt if and when there are enough accumulated pledges, but would hesitate to give and then discover there wasn't enough interest to go ahead with the plan. --janiejac 17:56, 16 July 2017 (UTC)

Janie, an interesting idea. For what it's worth, I'm rather like Neal (Skippy), above, in that I do make a couple of reasonable donations a year. If there was an on-going campaign to raise funds for up-grading software, I could probably squeeze more out of my fixed (and sometimes limited) income. --GayelKnott 18:17, 16 July 2017 (UTC)

Recently i learned about use cases. If we go from scratch, these use cases might help.

For example: one of my most basic use cases is to add a person page to WR. Another one is to add a family page to WR. A third use case is to edit a person page. A fourth would be to merge two persons' pages into one.

This way we could find out who uses what, without going into detail yet. woepwoep 05:31, 9 July 2017 (UTC)

I've been having a bit of a look again (after a few years' absence) at the WeRelate codebase. I've got a pull request open to merge the MediaWiki history into WeRelate's history, so we can more easily step through the 23 versions between 1.7 and the modern era. I'm also examining the differences that WeRelate code has from upstream 1.7.1. At the moment I'm not sure what the best path forward is, but I'm keen to at least get a demo site up and running (which itself isn't super easy, given that WR seems to require PHP 5.3). There's a bit of discussion over on the wikimedia-genealogy mailing list about this. — Sam Wilson ( Talk • Contribs ) … 07:09, 13 September 2017 (UTC)

Active member count [17 July 2017]

Janiejac asked an interesting question - "is there any way to count the number of 'active' members?"

Interesting challenge!

I have tried to answer this by starting with the threshold used on wikipedia of five edits per month. I tried to get as long a list as I could by revising the "Recent Changes" query to show 30 days, namespace "Person" and the last 5,000 edits (the most it would show). [1]

This actually shows only a week's edits, but hopefully will give the start of an idea of how many active editors there are on WeRelate.

Copying the result into a spreadsheet (pasting as "unformatted text"), it can then be manipulated to show the users. The simplest one is where there is a single edit, such as this:

N    21:43 Person:Samuel Colburn (7) (diff; hist) . . Jrich (Talk | contribs)

Here I have used a formula to identify the username, located between ". ." and the "Talk". I'm using OpenOffice, but the syntax in Microsoft Word is similar:

G3: =FIND(". .";A3)
H3: =FIND("Talk";$A3)
I3: =IF(ISERR(G3);"";MID(A3;G3+4;H3-G3-6))

For multiple edits, they are in the format:

     20:34 Person:Leslie Steiner (1) (5 changes; Page history) [Sorghumgrass; Delijim (4×)]

or, if it's multiple edits from the same user:

     20:33 Person:Mary Hutchings (10) (2 changes; Page history) [RichardK (2×)]

I have only identifed the first user for simplicity, although I acknowledge this will give an undercount overall.

J14: =FIND("[";$A14)
K14: =FIND(";";MID($A14;J14;100))
L14: =FIND("(";MID($A14;J14;100))
M14: =IF(I15<>"";"";MID(A15;J15+1;IF(ISERR(K15);L15-3;K15-2)))

Combining both single & multiple edits into a single column:

N14: =IF(I15<>"";"";MID(A15;J15+1;IF(ISERR(K15);L15-3;K15-2)))

This gives me a consolidated list which, using a sorted PivotTable gives me the following totals:

1 Susan Irish 346
2 Jrich 245
3 KleiHMv 190
4 DataAnalyst 176
5 Jaques1724 85
6 Loughner 85
7 Goldenoldie 68
8 Neal Gardner 61
9 Sorghumgrass 58
10 Beatrijs 50
11 Delijim 43
12 Kdrost 29
13 RichardK 29
14 White Creek 26
15 Moverton 24
16 Amelia.Gerlicher 21
17 Bolan 18
18 RolandHenryBakerIII 17
19 JuliaHogston 16
20 Melderick 16
21 GayelKnott 15
22 Grey 13
23 Jrm03063 11
24 Bronquest 10
25 Normiejac 10
26 Burgjoh 8
27 Pahawkins 8
28 Rebejackson 7
29 Acurley 6
30 Babo 5
31 Btomp 5
32 Rebekah Carlisle 5
33 Samples 59 4
34 Dbarton19 3
35 Diane Terpstra 2
36 Maximiliano 2
37 Pkeegstra 2
38 Sjoerd Jelle 2
39 Ts 2
40 Cos1776 1
41 Dskousen46 1
42 Jbigwood2 1
43 Julia Hogston 1
44 Mz28yo 1
45 Tlc356 1

So, depending on how exactly you want to define "active user", there were 39 people in the last week who made two or more non-minor edits to WeRelate Person pages.

I have bolded those on the above list who are also commentators here. The method clearly isn't infallible as my list is missing the following other users:

woepwoep - looks like I just missed him in the cut-off
janiejac - her only edits recently were all marked as "minor"
BobC - just missed in the cut-off
Khaentlahn - just missed the cut-off
Dallan - no recent contributions

At a guess, I would say that makes around 45 regular contributors. Not sure if the summer holidays understates that number. AndrewRT 22:55, 16 July 2017 (UTC)

Thanks for all your work to come up with an answer to my question!! That required talents that I don't have!! Perhaps the upcoming voting on suggestions will also give us some idea of how many folks are interested in getting those suggestions implemented. I think Dallan is planning to use the money from ads and/or donations from 'please no ads' to fund the summer improvements. But I'm also thinking having an ongoing list of pledges toward upgrading mediawiki is going require more participation than just these active people. A pledge list wouldn't involve actually handling any money, but what about someone with the talent setting up a separate page to describe what we're trying to do and let people sign up as a pledge to be given when the totals reach a pre-determined amount. You could somehow hide the amounts as it's not a good idea to be public with that; but show the total promised as of the current date. (I know, situations change and some will back out, but hey, it would be a start!) Any comments on the advisability of doing this? Or am I having wild ideas? --janiejac 02:00, 17 July 2017 (UTC)

I think we need a projection here. At one time Dallan gave us a basic idea of how much income is generated by ads, and general operating costs. Perhaps someone knows where this was discussed - 2016 or 2015, 2014 ? I think we need a $ goal, and an average monthly amount to achieve the upgrade, especially if we are projecting the upgrade for 2018. Perhaps we could encourage "ad-free" contributors to add that $5 or $10 amount to their next payment; I think most of the "ad-frees" are in a 2 or 3-month period and may be a similar list as generated above. I just paid mine at the end of May and believe most are in a period surrounding that month. Neal--SkippyG 14:04, 17 July 2017 (UTC)

Also, do we tell new contributors how they can remove adds from their account ?--SkippyG 14:16, 17 July 2017 (UTC)

I think Dallan has already given a projection of from $5,000. to $10,000. Perhaps because I'm a (retired) bookkeeper, I think of fund raising for the one-time wiki upgrade should be separate from the funds available for normal suggested improvements. If we don't keep it separate with a specified estimated goal, how are we, or Dallan, to know if or when the goal was reached? And unless I can see that there are enough folks interested in this to make it even feasible that we might be able to raise $10,000 then I'm not motivated to even begin. So, yes, this would be a long-term project. It has taken two years just to accumulate enough funds to activate the normal suggestion list. If we don't separate or designate the funds, the normal suggestions will probably eat up any extra funds. I'm willing to pledge funds to a visible list. If others add their names and I see that yes, it will be possible, then we can go for it. But I'm not willing to just give a bit more each time I donate hoping that sometime in the far future, those funds will be used for the upgrade. I'm talking about motivation to give; I guess I just need a specific project to give to; not a generalized list of hoped for suggestions. --janiejac 14:56, 17 July 2017 (UTC)

@SkippyG - per Dallan's Watercooler posts (May 2016) [2]:

"... WeRelate makes roughly 75% of its income from ads and 25% from donations. Specifically, it's about $600/mo from ads, about $50/mo in donations, and $2,000 from the fundraiser last Summer. ... It costs roughly $350/mo to pay for the servers. The ads are a necessity to keep WeRelate running. WeRelate does not get enough donations otherwise. A $20/year donation exempts you from ads. ... " ... and ... " ... If things keep going as they are, the MyHeritage ad is on track to generate over $1000/mo - almost twice what the google ads are generating. ..."

We have not been updated on the $1000/mo projection to know if it panned out, so that is something to pursue. Also, we do not currently include information about removing ads in the standard Welcome message to new users. We certainly could, and I think that is a great idea! --cos1776 15:48, 17 July 2017 (UTC)

So, if I'm taking everything into consideration correctly....we need an updated figure for WR's monthly income with a rough figure of how much, if any of that income could be earmarked for "Update", giving us a rough figure per month needed by donations...followed by a decision of how long we hold this campaign; 6 months, 12 months, 18 months ? In addition, can we afford, in the meantime, to make smaller improvements ? Or hold off, and see how the campaign goes ? If we have current monthly income $1000 or plus, we might have a shot at "updating" sometime next year. Neal --SkippyG 16:37, 17 July 2017 (UTC)

Request List [28 July 2017]

A list of potential software improvements has been created and needs to be prioritized by community voting. Please see the request list for more information. Note that voting is open, but some items will not be ready to be voted on for another day or two. In the meantime, you may wish to review the requests.--DataAnalyst 02:18, 18 July 2017 (UTC)

All items have now had points assigned. Note that one new request was added as well. Please ask for help if you have trouble figuring out the voting system - I can't tell if I made the explanation clear enough. Thanks--DataAnalyst 02:08, 19 July 2017 (UTC)

I would prefer to have Dallan vote my "points". He has better visibility into what makes the most sense from a development perspective. --jrm03063 14:44, 19 July 2017 (UTC)

For anyone who might have been away from emails for the last couple of weeks, I want to draw attention to the fact that Dallan has indicated we could get some improvements made to WeRelate this summer. A request list has been drawn up and voting is open until tomorrow. Thanks to those who have already voted.--DataAnalyst 18:03, 28 July 2017 (UTC)

Suggestions: you get 12 Votes [19 July 2017]

Come on folks! Let's get this done! DataAnalyst has done a major job laying it all out for us. A bit tedious yes, but we've been waiting for this chance to get some of these suggestions implemented. So use your 12 votes wisely - spend them on the suggestions most important in your opinion to either improve the functionality or professionalism of the site. See this link to vote! --janiejac 16:20, 19 July 2017 (UTC)

Ok, well let me express my appreciation for the opportunity to vote - and the effort put into providing a way to do that. It does matter. I'm committed to WR and contribute as I can. That said, the suggestions available for implementation strike me as very distantly second to getting us to a newer Wiki software base. I suppose it would be nice to see "reference number" facts sort to the end of the fact list - but that change won't make anything I'm doing easier. So I'm inclined to abstain and/or defer my vote to Dallan. Thanks again for the opportunity, and please don't interpret my non-voting as lack of appreciation or interest in WR. --jrm03063 17:31, 19 July 2017 (UTC)

I appreciate the thoughts given by jrm03063, and respect his choice to defer to Dallan...however only 4 of us have expressed opinions re: improvements. I personally hope that I don't have that much power {;>). Even if you only vote for one improvement, please help make this a group decision. ANYBODY can chime in. Just Neal--SkippyG 23:06, 19 July 2017 (UTC)

With all due respect Neal, voting just started this morning. Many items were not weighted until then meaning one could not partition their 12 votes until then. Not clear what the deadline is since one doesn't seem to be stated (did I miss it?), but I suspect many people may only log in once a week due to work, etc. --Jrich 23:43, 19 July 2017 (UTC)

DEADLINE: Sat. 29 Jul 2017, as it says at the top of the Request List page and the talk (voting) page. I agree it's rather early since what's being voted on just settled down on the 19th. --robert.shaw 23:56, 19 July 2017 (UTC)

Just an encouragement, folks, not a command. --SkippyG 00:16, 20 July 2017 (UTC)

Obituaries [29 July 2017]

I have a request regarding obituary citations. In the last year, two reviewers have made adjustments to, and now a third has suggested changes to, my postings, even when I used previous suggestions. My request is that there be a standard/required way to cite and include obituaries in postings that is used by all of us.--Diane Hosler 17:17, 23 July 2017 (UTC)

I'm sorry that happened to you...

I don't know that we'll get to the point of having "just one" way to manage obituaries. But we ought to be able to narrow things down to a couple generally preferred forms - perhaps one for people who want the content on the Person page for the subject of the obituary - another if you're creating a MySource to use for multiple Person: pages. If you want to push the community on this - you might offer a draft of an obituaries section for Text Tutorials? Then people would be somewhat on the hook to hash this out... --jrm03063 23:06, 26 July 2017 (UTC)

Please forgive my late reply. I have been out of town again. I am the 3rd reviewer that Diane refers to above. I do not know who the other 2 reviewers were or what they did, so I asked Diane to let us know, so that we might see what that is about. I think that there is a misunderstanding or miscommunication going on about the difference between MySource and Source pages. I did try to explain the difference on the talk page in question, but I may not have provided a clear enough explanation.

In this case, a MySource page was created during Diane's GEDCOM upload in 2014 for a newspaper in which several of the obituaries she has cited appear. Since 2014, a regular Source page was added to our database for this newspaper, so I updated the citation to link to that regular Source instead. A few weeks later, Diane edited the citation again to change the link to a different MySource page (MySource:Diane Hosler/Obituary) which was less specific than the previous MySource page for the newspaper, so I asked her about that change.

The point of the my initial edit was to link the Person page to the Source page. It was not about specifying one citation format over another. Diane's initial GEDCOM had already provided the proper amount of information to adequately cite the obituary, so there was no problem there. The problem had been on our end, when the source matching part of the file review had not been adequately completed, and a MySource page had been generated where a Source page should have been. The initial idea behind this site was to link persons not only to each other, but also to common places and sources. I don't know if all of this linking has helped anyone to bust through some of their brick walls, but that was what the original developers hoped would happen, so I continue to try to follow it. --cos1776 04:30, 29 July 2017 (UTC)

Request for feedback on site speed [5 August 2017]

Dallan has requested some feedback on this to help him identify the problem areas and when they occur. Specifically, he wants to know: What functions are slow? Is it always slow or only sometimes slow? If only sometimes slow, do you notice it only at certain times of the day or night? It is most helpful to have this input in a list format. I'll start us off with a couple. If you would like to provide input, please add your names, comments and any additional functions you think should be on this list as well. Thanks, --cos1776 13:44, 1 August 2017 (UTC)

Function: Loading Person and Family pages (initially)

• Usually slow. Don't notice correlation with time of day. --cos1776 13:44, 1 August 2017 (UTC)
• When slow, the left-hand menu does not have the usual words. For example, it says "Discussion" where it usually says "Talk", and "Move" where it usually says "Rename". No correlation to time of day. Is anyone besides me noticing this problem?--DataAnalyst 13:51, 1 August 2017 (UTC)
  • Yes, I see that often as well. "Discussion" and "Move" used to be the names of those menu selections way back when, so I thought it must be similar to how older pages are not updated with some of our auto-updates until they are opened again for editing. Similar to how we have to open/close (null edit) some pages occasionally in order to update the display of links that were changed on other pages to which they are connected. I think this is a separate issue from the speed issue, but I agree with you that it might appear when pages are timing out. --cos1776 14:20, 1 August 2017 (UTC)
    • For me, this behavior is tightly coupled to site speed - it only occurs when the page is slow to load. I will start keeping track of exactly when it is occurring and which page I am loading, to see if that helps with research. If others can do the same, that might be helpful.--DataAnalyst 15:15, 1 August 2017 (UTC)
      • This is one of the "speed problems" I've had, but it's highly variable. Like DataAnalyst, I suspect greater specificity is needed in reporting it.--GayelKnott 20:09, 1 August 2017 (UTC)

Same "Discussion" & "Move" appears, usually evening, Eastern U.S. time--SkippyG 15:09, 1 August 2017 (UTC)

Function: Opening page in Edit mode

• Usually slow. Don't notice correlation with time of day. --cos1776 13:44, 1 August 2017 (UTC)

Same. Any time of day.--SkippyG 15:09, 1 August 2017 (UTC)

• Not sure if it matters, but I usually use Google Chrome as my primary browser when accessing WeRelate. I notice the slow spinning wheel in the window tab title usually while in Edit & Save modes while on my desktop, and the grayed out inaccessibility screen on my MS-Surface laptop that lasts up to 5-10 seconds. This has been the case for about a month or more. My wife often reminds me to close some of the multiple Internet windows I have open on my computers when she notices me sitting waiting for the window to clear or the edit and save processes to finish, but I don't think that is the primary issue. I think we have gotten used to instantaneous responses, so the slow processing speed and delays have been noticeable. Can't say I've noticed any time of day when it is better or worse (faster or slower). --BobC 12:08, 2 August 2017 (UTC)

Highly variable occurrence. Will try to track timing, context.--GayelKnott 20:09, 1 August 2017 (UTC)

Function: Saving changes to a page

• Usually slow. Don't notice correlation with time of day. --cos1776 13:44, 1 August 2017 (UTC)

Same. Any time--SkippyG 15:09, 1 August 2017 (UTC)

• Often a series of slow completions, followed by faster ones. Most frustrating between 7 and 8 am BST (British Summer Time)==2am EDT --Goldenoldie 19:37, 1 August 2017 (UTC)

Highly variable occurrence. Will try to track timing, context.--GayelKnott 20:09, 1 August 2017 (UTC)
10:00 pm Pacific Daylight Savings Time. Had just made a number of changes, saved, made changes on a different page, than more changes on first page, saved very slowly.

Function: Selecting Place from dropdown menu

• Menu is often slow to appear. Don't notice correlation with time of day. --cos1776 13:44, 1 August 2017 (UTC)

Same. Any time.--SkippyG 15:09, 1 August 2017 (UTC)

6:22 pm EST: Page "timed out" for a Massachusetts location.--SkippyG 22:36, 1 August 2017 (UTC)

Highly variable occurrence. Will try to track timing, context.--GayelKnott 20:09, 1 August 2017 (UTC)

Function: Selecting Source from dropdown menu

• Menu is occasionally slow to appear. Don't notice correlation with time of day. --cos1776 13:44, 1 August 2017 (UTC)

Same. Any time.--SkippyG 15:09, 1 August 2017 (UTC)

Function: Selecting Dashboard from dropdown menu

• Just want to add to my comment above that I just noticed the following screen after I finished saving my entry and accessed my Dashboard. I have seen this screen occasionally before, but it was more noticeable now after reviewing this topic. Thought I would save the image and add it here to see if it might be related to speed and timing issues highlighted above. --BobC 12:25, 2 August 2017 (UTC)

• I've seen this fill-in failure too at random times. --robert.shaw 15:21, 2 August 2017 (UTC)

Someone correct me if need be; I think this happens as new figures are being added. At times I notice new items on my Watch List just after the above happens. --SkippyG 19:31, 2 August 2017 (UTC)

Follow up [11 August 2017]

Thank you for the feedback on site speed. The site was upgraded to a faster server this morning. You should see an overall improvement in speed, including those functions above. If you do not see an improvement, please let us know. --cos1776 17:38, 5 August 2017 (UTC)

Probably minor, but it just took a fairly long time to find North Providence, RI. --SkippyG 17:51, 5 August 2017 (UTC)

Further follow up: On Aug 9, Dallan found and fixed the issue that caused a pause and then display of old labels (e.g., Discussion instead of Talk). I have not experienced the display of old labels since then. If you see the old labels again, please post here. If not, it appears that one of the issues causing slow page loading has been resolved.--DataAnalyst 11:44, 11 August 2017 (UTC)

Vital that we deal with Flash Player issue [8 September 2017]

It is probably over a month since I became unable to use WeRelate normally. The problem is with the site's reliance on Flash, and with Flash Player. Flash content is now blocked by most browsers. The most obvious manifestation is failure to launch FTE, this being replaced by a link to download Flash Player (even if you already have it).

We have 3 machines at home, namely a desk top running Windows 7, an Android tablet, and a Mac Book Air. None will display WeRelate Flash content.

I have been researching the matter over the last couple of days, with the help of a friend.

Internet Explorer: Some users of this browser can probably still view Flash content across all sites, but my IE 11 does not display Flash now.

Safari: This page: [3] explains that Flash has been disabled by default in Safari 10, and how you can enable it for individual sites. It concludes:

“Avoiding Flash is not a bad idea, by the way. We’ve suggested users disable Flash by default in their browser for a while now, because it bogs down your computer and is a common vector for malware. It would be wonderful if every site stopped using Flash. And many sites have, from YouTube to Vimeo to Netflix. Apple is, by blocking Flash by default, trying to encourage web developers everywhere to drop Flash too.

But the short term consequence is confused users, who are essentially pawns in Apple’s plan. Right now users are being told that Flash isn’t installed, even when it is. There must be a better way to get web developers to drop Flash."

Google Chrome: Dated December ‘16, this page: [4] concerns Flash in Google Chrome. The situation is similar to in Safari.

“Google told us in May that it would eventually block Adobe Flash Player content on Chrome. And today, the company is making good on its promise. Google is making HTML5 the preferred and default way to display website content in a change that’ll take place over the next couple of months. This means that unless a website has an HTML5 content player, video content will not automatically display. All Flash content will be blocked, unless users manually enable it on a site-by-site basis.

At first, permission requests will only pop up on sites that users are visiting for the first time, but by October, every site will require user permission to run Flash. One percent of users on the current version of Chrome will see this feature. Everyone should have an updated Chrome by February, when the most recent beta version goes stable.

Google isn’t the first company to block Flash content. Last year, Facebook made every video on its website play in HTML5 by default across all browsers. Even Adobe told people to stop using Flash last year, so really, Google’s update is for the best.”

Opera: Dated May ‘17, this site tells you how to enable Flash Player, on a similar site-by-site basis, in the Opera browser: [5]

Firefox: On July 14th, Mozilla announced that it was immediately blocking Firefox from playing Flash content. This was because of the recent discovery of two critical zero-day flaws. See: [6]

I am very concerned for the future of the WeRelate project, and believe we must address the need to replace Flash. Many users must have been having problems with the site for weeks/months. ] --Helen-HWMT 13:28, 6 August 2017 (UTC)

Helen's cogent and timely notice of the Flash content problem is very pertinent. I'm an avid user of linked YouTube references for my person additions here at WeRelate (when available), and all the people I checked today since reading the above topic that I know contain YouTube links are not only malfunctioning but the active references have disappeared. Yeah, this needs to be fixed! Hopefully someone can create an auto fix solution. Fast! --BobC 20:32, 6 August 2017 (UTC)

I've been dreading this for awhile now, but as of a day or so ago, Family Tree Explorer has become unusable for me, too. It won't function in either Firefox or Chrome, either of which I would be happy to use. The problem is, I use FTE ALL THE DAMN TIME . I research extended family groups offline (mostly putting everything into TMG), and then when I have ~30-150 people all sorted out and sourced, I upload them to a temporary "holding" tree at WeRelate. Then I use FTE to go through every single new page and double-check them for errors and generally clean them up before I regard them as ready for prime time. Yes, I can use the list view of the holding tree, but that's much, much slower. And you can't watch the list get shorter as you clean up each page and assign it to its permanent tree. (It doesn't refresh instantly, the way FTE does.)

I've been online since before browsers were invented, but I'm not a techie and I have no suggestions to make in fixing this. I don't even know that it CAN be fixed, since Flash is apparently going to disappear. I assume an entirely new non-Flash FTE replacement would have to be designed and implemented. And I'm pretty sure that, with the new website being developed and all, Dallan isn't going to be very much interested in doing all that on WeRelate. Very depressing. --Mike^Talk 10:48, 5 September 2017 (UTC)

I'm sure we need to sort out the technical issue you're referring to - no question. But maybe there's a way to preserve your work process without FTE... If I understand correctly - you're creating a small GEDCOM that you then upload. Then you want to be able to systematically go through each of the pages - with some certainty that you've visited all of them for final clean up. Maybe you could generate your GEDCOM such that each Person had a fact with a description field containing "{{Mksmith_Work}}" (or something equally clever). Define a template called "Mksmith_Work" - then you can find your way to the pages by going to the template and checking what Person pages link there. As you work through each of the pages - eliminate the "{{Mksmith_Work}}" marker. Over the years, I've used similar approaches to mark pages where I somehow left off and needed to be able to find my way back later. Just an idea. --jrm03063 14:31, 5 September 2017 (UTC)

Wait a minute - are you saying that - as you work on a page - you take it off your working/temp tree, adding to your regular tree - then when you do a search you don't get timely updates? --jrm03063 14:55, 5 September 2017 (UTC)

with some certainty that you've visited all of them for final clean up

Yes, that's exactly right. I may have several distinct family groups in a given GEDCOM that don't connect to each other, so I can't just work my way up and down the tree, clicking the links, either. (These are usually part of my Red River Project or some other interest, not my own family.)

And yes, I suppose I could create a new tag in TMG with a fixed, searchable bit of text, as you suggest. I already do something like that occasionally, as you do, to flag persons who need specific research done, or whatever. But, to be honest, I hate kludgy workarounds. And no, the "VIEW" link for a tree, which gives you an ordinary search-result listing of pages in that tree, does not update itself instantly the way FTE does. I can open a list of (say) the 50 pages in a tree, go through each of them, and reassign them to a different, permanent tree -- and if I reload the page a half-hour later, the list will not have updated itself. It takes an hour or two, usually. --Mike^Talk 18:12, 8 September 2017 (UTC)

The "blocked" incident [9 August 2017]

Now that my account has been "unblocked", and hopefully anyone else's, what happened ? Unsarcastically, could someone explain ? And is this likely to happen again ? --SkippyG 18:14, 7 August 2017 (UTC)

And in the meantime, a HUGE Thanks to the people who have (and probably still are) working on this. --GayelKnott 18:18, 7 August 2017 (UTC)

This goes for me, too. --Goldenoldie 19:27, 7 August 2017 (UTC)

Still working on figuring out the cause. I promise to update once it is figured out and fully resolved. I apologize for not posting sooner, but I was blocked from editing the same as everyone else. Thank you, --cos1776 19:35, 7 August 2017 (UTC)

Well, I appreciate the quick effort, so thanks!  :) ! --jrm03063 19:41, 7 August 2017 (UTC)

My appreciation, also. Neal--SkippyG 20:48, 7 August 2017 (UTC)

Hi Everyone - I will try to give you a simplified explanation of the malfunction that occurred over the weekend and refer you to Dallan if you wish to know more of the exact details. He has access to things like server logs, etc. that I do not have.

Basically, there are some behind-the-scene changes going on as we work through the user request list. In this case, as part of both the https conversion and the site speed improvement projects, some network changes are being made. Included in this is the installation of a new load balancer to help distribute site traffic across the servers. Following installation, there was a glitch going on which was causing the WR servers to interpret some of the incoming traffic as if it were all coming from the same IP address (probably that of the load balancer) and to associate that IP address with certain accounts that had been previously blocked for spam. This association triggered the auto-block message many of you saw and the lock out of your account.

Since I am the admin who blocked the spam accounts earlier in the year, the auto-block messages all said that the block was coming from me. I do feel awful about that, and I tried to personally answer all of the emails that I received. There were many, so I hope I replied to everyone. I am sorry for any inconvenience or confusion that this may have caused you.

As we continue with the upgrades, I can't guarantee that we won't run into some other glitches, but I can guarantee that we will try to address them as soon as we can, given our different work schedules and time zones. Please keep the feedback coming, and thanks again for your patience. --cos1776 14:02, 8 August 2017 (UTC)

Follow up: Clearly we are not 100% out of the woods yet as another site-wide block was triggered late last night EST. Thanks for quickly letting us know. We think we have isolated the source of the trigger in the code, so we can work on a more permanent correction today. --cos1776 11:36, 9 August 2017 (UTC)

MediaWiki and Wikipedia Language Versions [7 August 2017]

Association of WeRelate pages with Wikidata identifiers moves us beyond reliance solely on English Wikipedia. At the moment, 22,650+ WR Person pages are labelled with their corresponding Wikidata identifier. I now have some initial counts of how many of those pages appear on other language versions of Wikipedia:

• English WP - 20,975
• French WP - 11,550
• German WP - 11,335
• Italian WP - 10,865
• Russian WP - 9,873
• Dutch WP - 6,566

We could easily make WeRelate more internationally friendly on the basis of Wikidata instead of only English Wikipedia. --jrm03063 18:32, 7 August 2017 (UTC)

Congrats. Most of that effort comes from your diligent input, honest hard work and sometimes earnest debate here at WeRelate. That certainly expands our potential access to a true knowledge-base system (if utilized). But right now that is still only a one-way street. The next step, as I see it, is for WeRelate to be one of those "Source Identifiers" at Wikidata for universal access to the genealogical data that the linked pages here at WeRelate would provide, thereby becoming a two-way information highway. I notice that "WikiTree" is listed as such, so how do we get "WeRelate" shown and used as such? --BobC 20:14, 7 August 2017 (UTC)

There's a request for us to also have a property. In truth - the WikiTree people are more interested in us having that than I am - since it provides a rationale for creation of more identities in Wikidata. It's not important for me at present - since I can search in the WR Person space using the Wikidata ID as a keyword. It always returns unique.

Contributions really already move both ways. I've made thousands of contributions to Wikidata based on WR I have likewise added lots of connections and new pages in WR based on the connections present in Wikidata. The mere fact of tagging pages with the Wikidata ID - has revealed dozens of duplicates (and thus connections) that I would never have found otherwise. I'm looking forward to the difference report becoming small enough, that it's possible to upload for use by others. --jrm03063 20:57, 7 August 2017 (UTC)

Excellent ! woepwoep 21:04, 7 August 2017 (UTC)

I reviewed the "Property Proposal for WeRelate Person ID" subject at Wikidata and find your viewpoint posted there interesting and thought-filled. I also find it interesting one editor's observation that WeRelate is "simply a mirror of Wikipedia" using the example name provided there. Maybe the one-way ID notation approach is okay for WR now, but it would be great to be able to use a bot within WR to make that WD search automatically when entering a new person here rather than doing the search manually. (Just as a note of clarification, I am not proposing exchange of info with WT, just an observation that WT is shown as a Source Identifier at Wikidata.) --BobC 22:24, 7 August 2017 (UTC)

Updating WD with the current WR page names should be easy for a bot - I just don't want to add that task to everything else I'm doing at the moment. At present -

• I'm trying to get all our English Wikipedia attached Person pages updated to the corresponding Wikidata ID. About 4,500 remain to be visited. In some cases, the original WP page has gone away or become a disambiguation page. So I need to see if there's still a Wikipedia biography that yields a corresponding WD identifier. Such pages are either labelled with the corresponding WD id or have the obsolete WP content cleared.
• For WR pages with a WD identifier, my program determine what WD claims would arise from the WR organization. That set of claims is compared with the set of claims actually present on Wikidata. For WD connections that are not implied by what's present on WR - I know that something is missing from WR (relative to WD). If the WD content appears correct - I'll make appropriate additions to WR. If not - I delete the improper connections on WD (I have found a number of mistakes over there - they too are led astray by Wikipedia name changes over time).
• Eventually, it may be appropriate to interrogate WD for all instances of "human" - in order to find identities known in the MediaWiki universe but not presently on WR. There are probably many thousands - and it's not clear what might be the best thing to do to bring more of that information across.
• There's really so much more...

--jrm03063 00:03, 8 August 2017 (UTC)

Cautions while working on upgrades [9 August 2017]

In response to the comments from User:cos1776 regarding watching for glitches, I'd like to bring up something I have noticed with the "What links here" lists. (And before anything, let me say I'm so glad to see 500 items on the list as a default!) I have been looking through Montreal's "what links here". Montreal is a big city, and the problems here could well be hiding in "What links here" for other cities as well.

First, in the Persons and Families section (currently still in alphabetical order by first name), the list seems to stop part way through the alphabet. There are no Richards, or Roberts, or Thomases. Very peculiar. I am wondering if the list automatically stops at 1,000 items the way "Wanted Pages" does. If so, could this default be removed as part of the improvement process?

Second, in all alphabetical sorts accented first letters are found at the end of the list. Some places in Quebec are described as "Île" e.g. Île-de-Montréal and Îles-de-la-Madeleine. Is there some way to put these in with the rest of the "I's"? Accented e's are also out of place, but these are not so prevalent.

BTW, were the results of our poll ever published?

Regards, --Goldenoldie 18:31, 8 August 2017 (UTC)

I've been itching to increase that limit to 500 for a while now, so I am glad we were finally able to get that simple change done. Personally, I'd like to do the same for Search results (increase default number of returns), but one step at a time...

I'll see if I can answer a couple of your questions.

• "What links here" is not limited. Place:England is a good example of a page with more than 1000 other pages that link to it.
• Missing pages - There might be more than one reason why pages are missing from the list with each missing page having a specific reason. If you could give me an example of a page that you think belongs on that list but is not there, I could probably tell you why for that specific page. In general, I would guess that it is tied to the practice of redirecting page titles for Places. I think that is usually a bad idea given the structure of our site and the big re-naming project that took place in the Place namespace about 8 years ago which means that most Place titles are already a redirect. The best way to fix the bad entry in the Place field is to replace it with a good entry. If you would like some help doing this across multiple pages, just let me know.
• Changing alphabetical sort order - I was hoping that some others would weigh in on this. I know that the Scandinavian alphabets actually consider the letters such as å, ä, æ, ö, or ø to be separate letters, alphabetized at the end of their Latin alphabet, so it makes sense to stick to that. But I don't know much about French. We have several French speakers here. Hopefully they can give us some guidance.
• Poll results - To which poll are you referring? Did you mean the WeRelate:Request List?

--cos1776 12:05, 9 August 2017 (UTC)

For Place:Montréal, Île-de-Montréal, Québec, Canada, What Links Here shows several Roberts and one Thomas (but no Richards). Goldenoldie, you may have missed them because they don't appear at the end of the list like some of the "Person:" listings do. This is because of Redirects, as Cos1776 mentioned. The links via redirects are indented and appear under the redirecting "Place:" page name, so appear earlier in the list than the direct links from "Person:" pages. The Thomas and Robert links are listed on the first 500 page.

If you did mean the Request List, the WeRelate:Request List page gives the results near the top of the page in a table. --robert.shaw 15:46, 9 August 2017 (UTC)

This will look a bit confused. robert.shaw and I were writing at the same time.

• I didn't know that the Scaninavians put their accents at the end of the alphabet. At school we learned not to use accents on upper case letters in French (but that was 60 years ago; things may have changed), using the two together is something I have never done before.
• I have looked through Montreal "What links here" again. Because some of my changes have moved people and families from redirect links (e.g. Place:Montreal, Île-de-Montréal, Quebec, Canada) to the proper phrasing (Place:Montréal, Île-de-Montréal, Québec, Canada), I may have been confused when inspecting the lot a few days later. I think we had better wait till I investigate all of the redirected lists and see what happens then. Meanwhile, if there is a way to change all mentions of Quebec into Québec and Montreal into Montréal in one fell swoop it would certainly speed things up.

--Goldenoldie 16:06, 9 August 2017 (UTC)

LDS films availability ending [10 August 2017]

I rec'd this notice from RELIC (Ruth E. Lloyd Information Center) Prince William Co., Virginia:
"RELIC has been an affiliate library of the Family History Library for over fifteen years. Persons wanting to borrow from the millions of microfilms at Salt Lake City can have those films delivered to RELIC for viewing.
We recently received word that the film lending program will be discontinued on September 1, 2017. From now on, Salt Lake will concentrate on digitizing the remaining films and posting them on FamilySearch.org, but it will take until at least 2020 before they are completed.
If you think you will need particular films before 2020, you have until August 31 to place an order."--janiejac 00:28, 10 August 2017 (UTC)

Any idea whether this applies to the genealogy centers directly located in LDS stakes as well? --pkeegstra 10:41, 10 August 2017 (UTC)

The Family History Centers (FHC), as they are known at least in the U.S., will no longer be taking orders for microfilm distribution. They will continue to have access to the digital versions, including ones not available on the public internet. The most popular 1.5 million films are now digitally available, but the remainder will be added over three years, with all planned to be available by the end of 2020. --robert.shaw 16:47, 10 August 2017 (UTC)

Objectionable ads [12 August 2017]

If you've been paying to eliminate ads from your pages, you don't see what the general public sees. My donation 'ran out' and I haven't re-upped so I'm seeing those ads now. Really we should have a button to push to let Dallan know when ads are 'objectionable'. The one I just saw was gross. I know we have to have ads but really . . .I know I gross out easily but I don't want any intestines or blood on 'our' site. --janiejac 21:39, 11 August 2017 (UTC)

Most of the ads (other than MyHeritage), are chosen by Google -- and based on what other sites you have used and what they think you might be interested in (which is often a bit bizare). If you don't like a particular ad, in the upper right corner of the ad are a grey triangle, and a grey X. Click the triangle to tell Google what you think; click the X to delete that particular ad. Not sure, but this might actually affect the income for WeRelate. --GayelKnott 16:52, 12 August 2017 (UTC)

Feedback wanted on linking WeRelate to external source [16 August 2017]

Werelate is now a property over at Wikidata see my blog

One of the benefits of linking a profile to WIkidata is that you easy find other External references to the same profile e.g this query tells that

• we have now 397 WeRelate profiles linked to Wikidata using P4159
• on 154 of those profiles is also a FindAgrave link P535
• on 66 of those profiles is also a Dictionary of Swedish National Biography link P3217

Dictionary of Swedish National Biography abbreviated SBL is work done by professional researches since 1922 and in Sweden seen as a source you always should check if you research something on University level....

My thought is that WeRelate profiles that are described in SBL should also have a link to that site

I therefore did a small test

1. created a Template:SBL
2. added some profiles see Category:Pages_that_cross-reference_SBL

As Wikidata is machine readable its easy to find those links and it could maybe be possible to have a bot adding those links to WeRelate

Other possibilities

1. Pictures are stored in P18 as those pictures are from WIkicommon its ok to copy and use - query
2. Grave pictures are stored in P1442 see search on Werelated profiles with grave pictures
   1. as said all pictures are in WikiCommon and can be used
3. Finnish Bibliographies Kansallisbiografia has property P2180 - query
4. Rodovid is an Ukrainan genealogy Wiki using MediaWiki 1.9.3 they have Property P1185 and has most research in that part of the world ==> they maybe have other sources. A search for Werelate profiles that also has a reference to Rodovid

All comments are welcome.

Semantic web Doing this linking with Wikidata is part of something called the semantic web or Web 3.0.

Below some good videos explaining the concept

• TED Video with Tim Berners Lee the inventory of the web - The next web
• Video Open linked data whats in it for me

Regards Magnus Sälgö Stockholm Sweden

- Salgo60 07:27, 13 August 2017 (UTC)

Appreciate the details and the links posted above. I think that getting a Wikidata property identifier for WeRelate is a huge potential exposure for the site, even with the small number of linked profiles to start with at this time. As I said in my comments above, this moves WeRelate from just a "data collection and compilation site" to a "resource repository site," and thereby increases the pressure on us to create quality pages, using and citing original, primary or secondary sources that meet what is known as the Genealogical Proof Standard. --BobC 14:47, 13 August 2017 (UTC)

Hejsan Magnus! This is good stuff that both you and jrm are working on! I support the establishment of the property id at Wikidata and the cross referencing concept. I had also suggested looking into Semantic Mediawiki in relation to user requests for increased flexibility for searching and sorting, so this all fits well. After looking over your comments briefly, a couple of quick things come to mind ...

1. Our WR page titles are not static, so if they are being used as the unique identifier for the WD property id, what happens if the WR page title changes? I wonder if WR uses a hidden unique id... I'll look into this.
2. We have some established practices here for working with and citing sources that are not incorporated into the template and pages as written now. Of course, I understand that you might not be familiar with them yet, but I'd like to see the slight adjustments made, so that they comply.
3. I like that you have identified the number as an SBL number. If we are going to start entering many other reference numbers, I would like to see them identified as well. This would mean a small change to the Wikidata template to include that.
4. Up until now, it was unusual for our readers to see more than 1-2 reference numbers in the "Facts and Events" timeline. If we are going to think about adding more than that, we might want to consider entering them in the "References" section instead and keeping the timeline reserved for dates and events. This is purely from a page design POV, but it makes sense as you are making reference to some source by using that number.

I am looking forward to learning more and seeing how this develops. --cos1776 20:10, 13 August 2017 (UTC)

• Keeping Wikidata updated with current WR page titles ought to be pretty easy. It's just not something I'm focused on right now.
• I'm not really a fan of moving things out of "facts" on account of WR-specific page display issues. I feel like we should prioritize what makes sense in an exported GEDCOM. Beyond that, most of the display problem ought to be solved just by having a smarter fact/event sort based on type of event as well as date.

--jrm03063 00:19, 14 August 2017 (UTC)

As in many cases, things that are acceptable in small numbers, can be expanded until they are obnoxious because not everybody has the same sense of what is good. So I agree with cos1776, in that I feel there are certain facts that are important for identifying the person the page talks about, i.e., pure genealogy. Others contribute towards a timeline, i.e, more family history than genealogy. But to the extent that they steal optimum screen area from the genealogical group, I believe these may be viewed as harmful and perhaps should be displayed elsewhere so the critical stuff remains visible in the first screen. For example, I may be interested in college graduation, or residences for every census, or every military unit served in, but I never want the death date pushed off the first screen because dozens of these have been added. And some of the others frankly seem to reflect the interest of researchers more than they describe the person on the page, i.e., categories and memberships in this group or that group (including the group of people covered by wikipedia, the group of people in this family organization, etc.) There is always the dichotomy between creating a fact and citing a source, since ideally, all facts are supported by a source citation, and the source citation is perfectly capable of communicating information. One would hope that anybody whose interest extends beyond seeing if this is the person they are looking for, would read all sources. So I tend to think that the critical facts should be kept to a minimum so all remain visible on the first screen when you look at a page, and people should either write a narrative and/or cite sources when they wish to add detail. If there is some desire to add peripherals facts, I think some software change should be done to list them in a lower section as cos1776 suggests. --Jrich 02:26, 14 August 2017 (UTC)

Agree I see links like SBL mentioned above as "Authorized information" on Wikipedia see usage of template Template:Authority_control that is used on the following pages and positioned at the bottom

I guess references like this will "explod" so maybe have some hide/show option is better in the UI. After been playing around in Wikitree and Ancestry I feel we will see a crazy amount of "duplicated" "bad" profiles so adding quality and be the place interested in serious genealogy is I believe one direction that is interesting and needed. The challenge we see with people profiles and genealogy we also have with locations and "linking" good genealogy information. I have started in Sweden to speak with museums so they start to understand the concept ==> if I have a location I should easy find other sites that have good genealogy for this area and also that I should jump directly to the part of the website that describes a location, an occupation, an event. Small start adding Swedish parishes (socken in swedish) to Wikidata see blog - Salgo60 09:12, 14 August 2017 (UTC)

Jrich, you can put your fears to rest. The "Reference Number" in the timeline always appears after the "Death". Of course the birth and death info always appears in the first screen because they are in the big blue box under the person's name. And additional "pure" genealogical info is displayed in the boxes on the right side same as always. I know you prefer the ultra short timelines, but family history is what it is and can be extensive for well-known historical or more modern people. Now as for my own perspective on the Reference Numbers, the examples I have seen don't bother me, and I'm not worried about if people add more. If the site ever gets more money, someone can redesign the layout, but I'm willing to make allowances for this work that other people are doing in the current layout. -Moverton 16:50, 14 August 2017 (UTC)

Reference numbers beyond actual "Wikidata" IDs won't ever be typical. Wikidata exists specifically to consolidate information of that sort. Someone might start an effort on WeRelate - or they might have an identifier on a particular page here or there for reasons of convenience. But an extensive effort - of the order of the current effort with Wikidata - simply wouldn't make any sense. --jrm03063 18:20, 14 August 2017 (UTC)

I wasn't just complaining about reference numbers. It is more about the lack of planning and the anarchy of individuals doing what they want from one perspective without much thought about what other people might find useful or propose, and how that scales (it doesn't). And I believe thinking Wikidata type IDs are atypical doesn't reflect the big picture. For example, I would argue that the SBL ID mentioned above is more appropriate for this website than Wikidata IDs. Wikipedia covers a small fraction of people and thus wikidata is far from a universal identifier, and thus people are probably going to want to add others to cover the vast majority of people not in wikipedia, and each is likely to default to their preferred ID system. --Jrich 01:08, 15 August 2017 (UTC)

After just playing around a week at WeRelate I feel WeRelate has an excellent structure etc... why cant WeRelate be a genealogy VIAF for genealogy systems that support the vision of one profile per person (i.e. Ancestry that copies profile is a moving target that I guess has a design problem of ever be a trusted "friend"). Or at least be the prefered source... Most sites I have played with WIkiTree, FindAgrave, GENI, FamilySearch lacks the structure and the vision - Salgo60 14:50, 16 August 2017 (UTC)

I could offer a defense of the options and alternatives that arise (or may arise) from the Wikidata tagging effort - but I think I've already made bits and pieces of that case and don't really want to repeat that here or now. Instead - what if Wikidata (or any other id) - proves inappropriate or more noise than utility? What if the community rises up against use of a particular id for any set of reasons the community considers persuasive? So long as the ids are formatted with a consistent template - their removal could be accomplished systematically in a matter of hours. So the down side risk of this effort is trivial in the extreme. --jrm03063 16:24, 16 August 2017 (UTC)

Semantic WEB and persistent identifiers vs. the WeRelate identifier

The normal way of implement an identifier that change with renaming and merging is

1. add a #REDIRECT
2. never reuse an identifuer

Links about the theory

1. Study on Persistent URIs
2. lecture in german about URI and RDF

-Salgo60 09:23, 14 August 2017 (UTC)

Except sometimes you don't merge, you split. What you thought was one person was actually two different people. Could be as simple as a case in my tree the other day where the date of birth was from the first child of the same name, and the second was the one who lived to adulthood. --pkeegstra 09:32, 14 August 2017 (UTC)

Split that feels like a bug ;-) the idea with the semantic web is to identify same as relationships and a split means that you had something that was not same as something in the beginning.... good video of the importance of same as and how that can generate more traffic to your web as people will easier find it - Salgo60 10:11, 14 August 2017 (UTC)

GPS and quality

I agree this is the key. We will see hundred of sites that "copy paste wikipedia" compare profiles today on both WikiTree and WeRelate most of them has the same content. The challenge I think is to attract people doing good genealogy and are willing to follow a process like The Genealogical Proof Standard and that a site like Werelate has "quality framework" reviewing articles and also have some quality measurement - Salgo60 09:39, 14 August 2017 (UTC)

I'm not seriously concerned about whether a specific WR Person page offers content that isn't found on some language version of Wikipedia. What strikes me as important, is that people can move directly from WD (any language) -> WR Person: - then find themselves in a larger genealogy context than any WP would allow. The symmetric question of what's on a particular WR Person: page - versus what's on a corresponding WD or WP page - is interesting, but not critical. --jrm03063 17:40, 23 August 2017 (UTC)

volunteer needed to add page [26 August 2017]

Would someone volunteer to add a person page for Joseph Alexander Cooper. There is a long article about him on wikipedia and many other sites which do show up on a google seach, but WeRelate doesn't have him :( I'm unsure how to link the wikipedia info so I don't want to do it. We do already have his parents here: Family:John Cooper and Hester Sage (1). --janiejac 17:10, 23 August 2017 (UTC)

Done. --jrm03063 17:30, 23 August 2017 (UTC)

Thanks! . . . But that sure didn't turn out like I expected. I expected the link would go directly to the article about him. Is this the way it is supposed to work? --janiejac 19:50, 24 August 2017 (UTC)

Well, there are four active links there. The reference number which takes you to the wikidata page. The "source: Wikipedia" link which takes you to the wikipedia page (until it's replaced with an extract when the WP job runs over the WE), and the links to his find a grave page and the find a grave source page. What else were you expecting? --jrm03063 21:15, 24 August 2017 (UTC)

I'm trying to understand the wikidata system. I read the intro and was happy to see an example here. I could help by adding the appropriate ref link on my pages which have wikipedia links. But where does the number (Q6280958) come from? I went to Joseph's wikipedia page but I don't see any ref number for wikimedia. Is that a unique number for Joseph used by all of the systems? or is it a WR-generated number? --Judy (jlanoux) 16:35, 25 August 2017 (UTC)

Thanks for asking! The Q<nnn> value is generated on Wikidata when a new identity is established. I've never had cause to create one - I'm just using what's already there. To find the value from an English WP page - bring up the Wikipedia page. On that page, look under "Tools" for "Wikidata item". Go to the Wikidata item, and the top level title will be followed by the identifier "(Q<nnnnnn>)". So long as the WP page you were using was a biography for a particular person - you'll see that the page is an instance of "human" with all sorts of useful properties (given, gender, dob, pob, dod, pod, etc., etc.). The convention I've been following is to add the Q<nnnn> value to corresponding Person pages - using the Wikidata template - in the description field of a reference number fact. --jrm03063 16:48, 25 August 2017 (UTC)

Maybe my expectations weren't realistic but I thought I had previously seen some text from wikipedia brought over to WeRelate pages. (That's why I hesitated to try it myself.) But if no text is brought over, then I would have thought the link would go to the actual article: https://en.wikipedia.org/wiki/Joseph_Alexander_Cooper. When I followed your link it took a while to figure out how to get to the article. And I don't know what you were referring to "when the WP job runs over the WE". My ignorance is showing, but I'm trying to learn. --janiejac 00:47, 25 August 2017 (UTC)

Hi, Janie.

The content from Wikipedia will be added by next Monday. It is copied onto the page by a job that runs on the weekend. In the meantime, there is a "placeholder" indicating that Wikipedia is a source. When you click on the word Wikipedia, it takes you to the Wikipedia article. This will be changed by next week.--DataAnalyst 01:25, 25 August 2017 (UTC)

Thanks for the explanation. I'm more convinced it was right to ask for help constructing this page. The technicals are above my pay grade! I'm thankful for those able and willing to do it! --janiejac 17:56, 26 August 2017 (UTC)

trouble using WeRelate today [28 August 2017]

All kinds of trouble today. And I don't know if the problems are generated by my computer or the WR system. Was trying to review today's GEDCOM which uploaded just fine. Was using Firefox browser. After creating some place pages using a separate tab, when I came back to the review clicking on the tabs refused to work. Seemed like system was frozen, but it did allow me to use the back button to finally get out. So I switched to Chrome; went to my talk page to click review and cannot get the info to review. I do get this msg: "Alternate HTML content should be placed here. This content requires the Adobe Flash Player. Get Flash" the Get Flash is a link but nothing happens when I click on it. Any one have ideas for remedying either or both of these problems?? --janiejac 20:20, 28 August 2017 (UTC)

Hi janiejac, I am sorry to read that, like me, you are experiencing an issue caused by WeRelate's reliance on Flash Player for various functions. Most browsers now block Flash content for security reasons. You can set Chrome to override that block for specific sites; I have done this, but the result is not good.

Please see my topic on this page: 'Vital that we address Flash content issue' August 6th, and BobC's comment. Also see Support Talk where most of this conversation resides, though it should be on Watercooler.

I'd like to repeat my question to the experts: Can the system email all members? If it can, we need to ask everyone - even those who have headed off into the distance - whether or not they can use Flash features such as FTE without difficulty. We would not get a representative sample of members by doing an on-site poll, promoted on Watercooler. --Helen-HWMT 21:13, 28 August 2017 (UTC)

Can't review the Gedcom I just uploaded [9 September 2017]

I rec'd notice that the GEDCOM was ready for review but when I try to open it, I have to allow Adobe Flash, which I did; but then I get this msg: [SecurityErrorEvent type="securityError" bubbles=false cancelable=false eventPhase=2 text="Error #2048"]

So it won't open for review. Anybody else having this kind of trouble? --janiejac 16:44, 7 September 2017 (UTC)

Tried another time using Chrome (instead of the prior attempt with Firefox). Same result. Cannot review a GEDCOM. I guess WeRelate is dead in the water until this issue is resolved. --janiejac 18:33, 7 September 2017 (UTC)

Janie, can you please try again now and report back? --cos1776 19:07, 7 September 2017 (UTC) (and btw - that file sure has a lot of non-Place entries in the Place fields to be corrected before you import it.)

OK two points to make: (1) I tried again with both Firefox and Chrome. Same result both times. Cannot open review function.

(2) yes, there are a lot of missing places. I can remove the folks with missing places if I should not upload those folks. This is a file I was trying to upload to add what I could to the current Data Quality Improvement project.

"Currently Featured Task:1 Sep 2017: The tree created by Genealogist84 requires sources for most of its 47,000+ persons. . ." So I worked to find some of these folks and thought names and relationships would be better than nothing. But maybe this file would just add to the problem??? I could delete persons with no places and/or dates and just upload persons with more detail filled out. Or I can just drop the whole idea. This is not my line anyway. What do you suggest? --janiejac 22:06, 7 September 2017 (UTC)

Hi Janie - I think that anything you can do to improve the quality of Genealogist84's file is very helpful. Adding sources is the most helpful, but paying attention to how your data is entered is also important. I wasn't referring to the places that were missing, but rather to text you have entered in the Place fields that doesn't belong there, such as occupations, ages, household information, etc. It is much easier for you to fix these types of entry errors by moving the text to the appropriate field(s) before you import the file. That is when they all show up clearly for you in the Place matching list. After the Person pages are already created, it is much harder to find them again to fix them. --cos1776 15:45, 9 September 2017 (UTC)

I'm having the same error, with the gedcom I uploaded weeks ago. Both Firefox and Chrome.--Amelia 04:43, 8 September 2017 (UTC)

This seems to be another problem associated with the conversion to HTTPS. I tried a test GEDCOM and found I got this error when I followed the link from the "You're not done yet!" robot message on my talk page. I noticed that that link was a "HTTP" link, and when I tried changing the URL to HTTPS, it worked.

So until the site is fixed, I think users can work around this problem by inserting an "S" between "HTTP" and ":" in the URL for their review page. --robert.shaw 05:06, 8 September 2017 (UTC)

Https and flash don't work very well together (sigh). It looks like this is impacting both gedcom review and FTE. I was able to get gedcom review to work (finally) but I had to go through about 3 steps to do so. Let me see if I can serve gedcom review and FTE non-https and the rest of the site https. I'll work on this tonight.--Dallan 15:46, 8 September 2017 (UTC)

Great! Hope it works. How about the imbedded YouTube video links mentioned above? --BobC 17:26, 8 September 2017 (UTC)

I believe the FTE, gedcom Review, and embedded YouTube video links are working now. Please let me or DataAnalyst or Cos1776 know if anything else is broken because of the switch to https. That's caused a lot more problems than I anticipated.--Dallan 01:37, 9 September 2017 (UTC)

Glad to see you back [8 October 2017]

An unexpected day without WeRelate. What happened?

--Goldenoldie 16:07, 21 September 2017 (UTC)

Sorry - it crashed in the middle of the night (my time) and it took me a couple of hours to bring it back online.--Dallan 04:22, 29 September 2017 (UTC)

And I know you don't want to hear this (sorry), but the FTE appears to be hosed again. I uploaded a new not-large GEDCOM and when I began trying to process it, FTE began doing exactly what it was doing before. If I click away from that tab to another one, or to another application, and then click back, FTE has frozen. And when I change the tree a page is assigned to (after I finish editing it), it doesn't immediately disappear from the list. It just sits there. --Mike^Talk 11:07, 30 September 2017 (UTC)

Hmm, I just tried launching the FTE and it worked. When you launch FTE, is the URL http or https? It needs to be http, and I thought that I changed all of the FTE links to launch FTE in http mode, but maybe I missed one. If the URL is http, then can you tell me what browser and operating system you're using?--Dallan 03:56, 1 October 2017 (UTC)

Okay, looks like it is indeed http -- no "s." I'm using Firefox 55.0.3 under Win 10. --Mike^Talk 13:11, 1 October 2017 (UTC)

Oops -- Firefox just updated itself to v.56.0.0. Lessee, . . . Nope. Tried FTE again, clicked away to a different tab, noodled around a bit and came back -- and it's locked up again. --Mike^Talk 13:16, 1 October 2017 (UTC)

I'm running 64-bit 56.0 Firefox with the most current Adobe Flash (27.0.0.130) on Win 8.1. I ran FTE with a 500 family tree size and a 25000 family tree size and I can't repeat the issue that you're having Mike. It doesn't freeze up when I change tabs whether I leave the tab for a few seconds or a few minutes. I hope this helps. --khaentlahn 14:56, 1 October 2017 (UTC)

What puzzles me is that I spend significant time on a few other Flash-heavy sites and I never have this problem with them. And I have no trouble actually editing pages and so on within WeRelate. And as long as I stay on the FTE page, it seems to work okay -- opening pages in the list for editing, then saving them, then going on to the next page in the list. (Although FTE doesn't instantly update the list, either, as it always has done, when I change the tree a page is assigned to.) What's more, I can switch to another application entirely -- TMG or Textpad or whatever -- and then come back, and there's no problem. It's only when I "break the connection" (or whatever it is that happens) by leaving the WR tab and then coming back within Firefox that this problem occurs. --Mike^Talk 16:19, 1 October 2017 (UTC)

I just launched the FTE in Firefox on a Windows 10 box, opened a bunch of other tabs, came back to the FTE tab, and it seemed to work fine for me. I haven't changed the FTE code since I fixed it the last time. I'm not sure why it's not working now.--Dallan 03:20, 2 October 2017 (UTC)

And I just fired up FTE and it is still locking up. So it's apparently my system in particular. I appear to have the latest updates of Win10, Firefox, and Flash, so I have no idea what's going on. I find I can have FTE open and still move around within a family just fine by clicking on the links to parents and children and so on. It's only the lefthand panel with the FTE list that's frozen. *sigh* I'll just work around it until (hopefully) it fixes itself yet again. Thanks for your efforts, Dallan. --Mike^Talk 11:18, 2 October 2017 (UTC)

It's not just your system, Mike, FTE hasn't worked for me for a long time, and other people are having problems, also. I don't know what the answer is. I use a Mac, not Windows, for what it's worth. --GayelKnott 19:26, 2 October 2017 (UTC)

For what it's worth, I uploaded a new GEDCOM yesterday and decided to try processing in Chrome instead of Firefox. (I ordinarily tend to avoid using Chrome, for a number of reasons.) But the experiment was unsuccessful. The problems I had with Flash locking up and so on under Chrome were identical to the problems I was having before with Firefox. And again, other sites that use Flash worked just fine under Chrome. I dunno. . . . --Mike^Talk 11:41, 6 October 2017 (UTC)

I don't know why this is happening. We could try going back to http for a few days to see if that fixes the problem. Thoughts on that?--Dallan 20:15, 7 October 2017 (UTC)

I am using Google Chrome Version 61.0.3163.100 (64-bit) and am having no issues with the six random pages checked that had experiences issues last month (all now coming up under "https" URL scheme or protocol). My primary concern has been with the YouTube video links I've attached to multiple pages (which didn't work for awhile last month as previously addressed and fixed) which I feel are an integral part of the overall dynamic page design I was trying to create and use for those pages.

When trying to work with FTE I get the "requires the Adobe Flash Player" message. But I hardly go into or use FTE lately, so it's not a big issue for me personally. But I understand others' concerns.

So I would say (at least for me), it's not necessary to switch back to "http" protocol (primarily because I fear losing the now-working changes already made in the areas mentioned above). But I'm sure others may have differing priorities and recommendations.

As a final thought, since you're the expert here, you decide what needs to be done. --BobC 21:03, 7 October 2017 (UTC)

fwiw - I use Chrome and am not experiencing the FTE problems reported above, but I also have to admit that I only use FTE for exporting or copying trees, so I don't spend a lot of time with it. When it comes to the GEDCOM review program, however, I use it all the time to process incoming files. Since the last update, I have not had any of the problems we are talking about, even when working with files that were causing problems for others. I don't know why this is, but then again, I haven't gotten into the specifics of their particular settings and configurations each time. I have to believe that it is in those setups that the solution to these problems can be found. I don't believe reverting back to http is the answer, so I vote no on that. --cos1776 00:39, 8 October 2017 (UTC)

I'm not thrilled re:going back to http. Mainly because it's a pain in the [blank] getting into WR, at times refusing to let me enter for 10+ minutes. --SkippyG 21:47, 7 October 2017 (UTC)

Is it correct to presume the "can't open socket to search.werelate.org: 110 Connection timed out" message when trying to save an edited file is a result of maintenance or improvements being made this morning? --BobC 14:49, 8 October 2017 (UTC)

I can't get search to work in any capacity... ironically FTE is working fine.--Amelia 14:56, 8 October 2017 (UTC)

"Search" stopped for me today about 12:30 PM EDT.--SkippyG 16:56, 8 October 2017 (UTC)

Can't search or save now; so virtually unable to do much of anything. Get same message as BobC--SkippyG 17:37, 8 October 2017 (UTC)

Would tend to think something needs rebooting. This page seems to be savable, and I see plenty of Place edits in the Recent Changes. But for Person and Family pages, I only see "(diff) (hist) . . ! Person:Tom Petty (2)‎; 11:23 . . KleiHMv (Talk | contribs)" Possibly this is coming in from Europe so using a different server? --Jrich 18:34, 8 October 2017 (UTC)

I'm finding that I can edit and save person pages as long as I don't add a place - adding a place causes a search failure. I can add sources, though. I can also rename pages. But I can't get a search screen, other than search for a source from a page I am editing. I sent an email to Dallan several hours ago, alerting him to the problem.--DataAnalyst 21:37, 8 October 2017 (UTC)

Thanks! That seems to be the temporary fix I needed for the page I was trying to save. I eliminated the place page links and that allowed the page to save successfully. I'll come back when things normalize to add the place links. --BobC 22:14, 8 October 2017 (UTC)

I'm glad some can do something. The "fix" for editing isn't working for me. Can't even add a source from catalog, unattached to an event. --SkippyG 23:58, 8 October 2017 (UTC)

I should clarify. I realized after my last post that I can use the find/add link for a source on a person page, but the only sources I can select are those that are in my list of 10 most recently used sources (I can't actually search for a source from the catalogue). I can also select a source directly on the person page by starting to type and selecting a source I have used in the past few months from the resulting drop-down list. This works in Chrome (but not IE) and requires an exact match, including capitalization. Works best for predictable names such as census or VR sources.--DataAnalyst 02:16, 9 October 2017 (UTC)

Sandbox [25 September 2017]

Is the WeRelate Sandbox still around and usable? How do I get to it? Or where can I find out more about it? I don't remember much above it. If I put something there, will it remain or be washed off now and then? If it is still available for us to use, it ought to be on some dropdown list so it can be found. Or maybe it is just long gone... --janiejac 20:06, 24 September 2017 (UTC)

In your Dashboard, look down at your "User Pages" block, and hit the "Add user page" link. On the "Add a User" page, enter "Sandbox" in the title. WeRelate will then add your own Sandbox user page that you can play around with features you want to experiment with, and it will be forever listed on your Dashboard page. Good luck. --BobC 21:24, 24 September 2017 (UTC)

Hi, Janie. The actual Sandbox is still around although I don't believe it has been refreshed for a long time. It is found at http://sandbox.werelate.org/wiki/Main_Page. I keep a separate bookmark for it, as I don't recall where the link is on the regular WeRelate site. You have to create a separate account for this Sandbox. Also, I doubt that GEDCOM uploads are regularly managed in the Sandbox. If that is what you are looking for, you might have to contact Dallan.--DataAnalyst 22:38, 24 September 2017 (UTC)

Thanks to both of you! Following Bob's instructions, I found quite a few user pages I'd completely forgotten about. (My memory is NOT improving with age.) I think these user pages will do for what I wanted. One of the biggest problems I'm having is that I can't stop researching long enough to get what I've found uploaded to WeRelate! And too many projects come up at the same time so I need a good to-do list. This old lady is never bored! Because of a recent DNA test result for an adopted fellow I've been working on a study of ALL Jacksons in Marion County, WV. I made the mistake of adding this to my main database; I won't do that again. But I find I enjoy a county wide study. --janiejac 00:07, 25 September 2017 (UTC)

State Senates & House of Representatives as Opposed to U.S. Senate & U.S. House of Representatives [30 September 2017]

Has there been a category structure put in place for the State Senators and House Representatives for individual states of the United States? To clarify, these are for the politicians who serve/d in each state individually and are/were NOT members of the U.S. Senate or U.S. House of Representatives.--khaentlahn 16:47, 30 September 2017 (UTC)

With the exception of a category for historical Virginia, all of the categories for other U.S. elected officials seem to be at the federal level and are shown at Category:American political figures. Please feel free to expand as necessary and appropriate. --BobC 23:19, 30 September 2017 (UTC)

search button hangs up [9 October 2017]

New visitors are going to be disappointed when the search button on Home page doesn't work. The search button on the top menu also isn't working today. That little circle just goes round and round. I gave up on search and tabbed over to watercooler and it took forever to get here. Feels like the server needs rebooting again. --janiejac 04:48, 9 October 2017 (UTC)

Unfortunately, problems are still existing on 10/10/2017 - Beatrijs

Ability to add - since it searches for existing pages - likewise crippled. --jrm03063 14:53, 9 October 2017 (UTC)

There is a thread on this above as well (under heading Glad to see you back). As I commented yesterday, I emailed Dallan (about 24 hours ago now) and presumably he has not yet checked his email. I assume that once he checks his email, he will reboot the server.--DataAnalyst 15:12, 9 October 2017 (UTC)

The hardware that the search server was running on died yesterday morning, and the process to restore the search server from backup onto a new machine failed to work. Unfortunately I was swamped yesterday so I couldn't work on it. I manually restored the search server from backup onto a new machine this morning. Search should be working again now. I'm sorry for the downtime.--Dallan 16:20, 9 October 2017 (UTC)

Thanks, Dallan. I am sure you can hear sighs of relief from all over the place now that the server is fixed. --Goldenoldie 18:00, 9 October 2017 (UTC)

My extreme appreciation, Dallan for your diligent response. I actually resorted to reading a book !--SkippyG 18:31, 9 October 2017 (UTC)

FamilySearch Error [18 October 2017]

I'm not sure where else to post this, but I thought a notation should at least be made. If you use FamilySearch for any Kansas State Census records and are attempting to find individuals which should be in the Shawnee county area, none of the currently available State census records (1865, 1875 & 1895) will show individuals in Shawnee county. Unfortunately, every state census year has Shawnee county attributed to the city of Shawnee, which is in Johnson county. I have sent them a message reporting the error, but I am uncertain when something may be done to correct this.--khaentlahn 04:47, 18 October 2017 (UTC)

There should be a source page for this census. Each page in WeRelate has an associated Talk page where users can comment or discuss issues with the Source, Person, Family, Place or whatever. Here is the 1875 census page: Source:Kansas, United States. State Census of 1875. Thanks for sharing your information. --Judy (jlanoux) 11:22, 18 October 2017 (UTC)

Right, but herein lies the issue. While the error affects census records, it's not actually a census problem, but a FamilySearch problem. If there was a problem with the census itself, say certain sheets are illegible, I would completely agree with you. This is a technical problem with a website that will hopefully be fixed at some point. Are there pages dedicated to commentary on individual genealogy websites? That to me seems logical, but I haven't run across them.--khaentlahn 16:22, 18 October 2017 (UTC)

Just a thought - on the WR Source page for each affected source, you could note that there is a repository-specific problem for that source within the link to the repository. Perhaps something like "Search FHL index - known issues", where "known issues" points readers to the WR Talk page for more explanation in line with Judy's suggestion. --cos1776 18:16, 18 October 2017 (UTC)

Received word back from FamilySearch. It is currently not possible to change any errors in records, but they are working on "a program whereby the Patron will have the ability to request corrections directly on FamilySearch". They did not give an ETA, nor what this program may entail, but it was an answer of sorts.--khaentlahn 18:31, 18 October 2017 (UTC)

FREE access Nov 1-15 to Native American records [2 November 2017]

fyi - Fold3 is providing free access to their Native American Collection Nov 1st-15th with any registration for a free Fold3 account. Details can be found here.
--cos1776 18:09, 2 November 2017 (UTC)

FREE access Nov 2-5 to Scandinavian databases [2 November 2017]

SLÄKTFORSKA GRATIS I ALLHELGONAHELGEN!
In celebration of the All Saints holiday, Ancestry is granting free access to some of their Scandinavian databases Nov 2nd-5th when you access via their Swedish site, Ancestry.se.

• List of free databases here.
• Details on obtaining free access here.

From what I've noticed, there are usually only two times per year when free access to these records is granted (Easter and All Saints). If you have trouble reading Swedish, Google translate can be a big help.
Happy Hunting! --cos1776 18:39, 2 November 2017 (UTC)

Jackson folks that need sources [13 November 2017]

Most of the children of this John Jackson 243 are unsourced. I'm not sure how to get this info to the proper list of folks needing work so thought I'd put it here in hopes that someone can put Needs Sources on the pages.--janiejac 20:45, 7 November 2017 (UTC)

I'm not against flagging pages that need sources. But there are hundreds of thousands of pages that do - no one is going to get to all of them - and we've never really nailed down rules on when use of that template is appropriate anyway. If a particular user wants to label particular pages - so they can get back to them in a systematic and orderly way - does a general template of this sort really help? Perhaps if there's some way to do a search on your own pages AND the template - is that what people are thinking?

It seems like it would be better if we tried to objectively nail down circumstances when we want to label a page as needing more sources - then label it automatically - either via bot or as a standard part of getting a page for a user to look at. --jrm03063 23:39, 7 November 2017 (UTC)

One rather obvious criteria that shouldn't be too controversial would be when it has no sources as in "unsourced". Clearly better if someone can take the time and look up sources themselves, but if you can't next best thing would be to flag it so it's on a list where people willing to volunteer can find it and work on it. --Jrich 01:44, 8 November 2017 (UTC)

Another possibility comes to mind - maybe a search key could be added that allows searching for pages based on the number of source entries. Maybe then the ordinary search infrastructure could be leveraged to look for Person pages that had zero - or even a small number - of sources. --jrm03063 20:22, 8 November 2017 (UTC)

Besides the fact that this would take development, a resource in very short supply, it would not be useful because the right number all depends and one answer doesn't fit all. Sometimes one source is enough, especially if it is of high quality. If all the page has is a birthdate maybe citing a birth record is fine. And sometimes having two is no better than one when one of them is redundant or not credible. One of the primary purposes is to tell people where you got the data so they can assess its credibility and decide how to add additional or discrepant information to it. It would be nice if people looked at more than one source, but ultimately the chasm between one and zero is huge, and makes the difference between collaborating and less community-oriented posts. --Jrich 22:07, 8 November 2017 (UTC)

It is too late in the evening for me to do proper follow up, but I did add a note to the page that this appears to be the conflation of 2 separate families.--DataAnalyst 03:09, 8 November 2017 (UTC)

I have separated the several Jackson families that had been presented as a single family, and added sources (mostly one Virginia Genealogist article). I removed the "sources needed" template. Take care, Janie. --DataAnalyst 01:02, 14 November 2017 (UTC)