WeRelate talk:Watercooler/Archive 2014

I hope you all have a Happy New Year [1 January 2014]

It has been a happy Newyear for me. My great-great grandmother's maiden name has been a brickwall since I started family history in 1981. Her husband is in my direct paternal line and I had traced two generations beyond him, so it was very frustrating to list her simply as Martha with dates of birth and death from her tombstone. In the past few years I had picked up her birthplace from a two-line obituary and a possible surname from someone on Ancestry. Yesterday I decided to take the plunge and feed the information into FamilySearch. The first line to come up was Martha Maw, baptized 30 Jun 1807, Settrington, Yorkshire, England, dau of Newyear and Elizabeth Maw. I could hardly believe it. My Martha's eldest son was also named Newyear.

Happy New Year everybody! --Goldenoldie 10:04, 1 January 2014 (UTC)

Congratulations! A few years back, I spent a bit of time trying to figure out how New Year Maw's family was connected to my Maws from neighbouring Thornton Dale, but I didn't come up with anything.--Werebear 01:36, 2 January 2014 (UTC)

What a wonderfully timed discovery! :) -- Jdfoote1 02:22, 2 January 2014 (UTC)

My smile of the day - what fun! Happy New Year!--DataAnalyst 03:33, 2 January 2014 (UTC)

Werelate on the rise [4 January 2014]

This article notes that Werelate.org had the second biggest jump last year in Alexa ranking of any large genealogy site. I was a bit disappointed to see it described as an "English-only" genealogy wiki, though. --Werebear 06:51, 4 January 2014 (UTC)

Not to mention that WeRelate is the only wiki in the Top 100.--Jhamstra 07:31, 4 January 2014 (UTC)

Not so. WikiTree is in that Top 100 too (at 31).--Enno 21:52, 4 January 2014 (UTC)

Great news, but does anyone know why? Our number of records or users don't seem to have grown that much. Do we know which pages are getting the hits or where they are coming from? AndrewRT 21:32, 4 January 2014 (UTC)

Based on this article, readership seems to have nearly dounbled - from ca. 650 visitors per day to around 1,000. Is this consistent with the page view stats our site admins can see? Has there been a step change or just a gradual rise? AndrewRT 23:17, 4 January 2014 (UTC)

Deleting "discussions" and messages of other contributors [5 January 2014]

Hello ! I do as proposed by Jennifer ! Please see my "thought" on her talk-page. My english is so poor and it's for me not easy to explain (that I think and what I observed on some wiki-sites) and to understand precisely the arguments in their details. GoogleTranslate is truly catastrophic ! I became a new message from an WR-administrator, but I saw I deleted also several messages of others on his own talk-page ! Of course I can answer him on my page, but ... I think, this (problem ... for me) should be discussed and explained. Why is the only solution not an implementation archive, also an archive without destruction ? Amicalement - Marc ROUSSEL - --Markus3 09:04, 4 January 2014 (UTC)

Je crois que peut-être certaines de vos idées était <<perdu en traduction>>, mais je pense que je comprends. J'essaierai d'expliquer en anglais, et vous pouvez me corriger.

As I understand it, the problem is that some administrators are simply deleting revisions of pages, instead of removing the information and leaving it in the revision history. Is that correct? If so, then I agree with Marc, and think that the only information that should be deleted are copyright violations or privacy violations, and generally the revisions should still be available. -- Jdfoote1 22:42, 4 January 2014 (UTC)

I agree with jdfoote, better to leave discussions in the page history. Editors should be given more freedom on their own Talk page histories, but should still leave discussions in the history where possible so that others can refer to them if they need to. AndrewRT 23:03, 4 January 2014 (UTC)

Yes, deletion of a talk page (deleting all its history), or deleting items from the revision history, should I think only be done in extraordinary circumstances. Circumstances could include extreme language, attacks, defamation, etc. but should not be used to just get rid of "old stuff" that is thought not to be needed. Go ahead and edit the page to remove the stuff, but deleting the old revisions should pretty much be avoided if at all reasonable. --robert.shaw 22:34, 5 January 2014 (UTC)

People with one name [4 January 2014]

What about when someone has only one name? An example is Redhawk. Should Redhawk be entered for the first name or the last name? --cthrnvl 03:54, 5 January 2014 (UTC)

I favor first name because that is the "given" name, the one identifying the individual, whereas the surname or last name (in Western usage) is the family name and identifies the family. Since a single name does not identify the family, it belongs in the given name position to my way of thinking. --robert.shaw 06:22, 5 January 2014 (UTC)

Loss of TITL events during GEDCOM import [12 January 2014]

I have the impression that during my GEDCOM import all TITL events were lost and the titles were simply copied to the prefix of names. Is this a feature or a bug ? The loss of TITL event looks to me pity, as the TITL event may content not only the title itself, but the date of attribution, place, comments etc. Is there a list of events which are supported and not supported during the GEDCOM import ? --Alexandre 10:57, 10 January 2014 (UTC)

Are you saying that it's throwing away information? Or is it just dropping stuff it doesn't understand into the narrative body of the page? --jrm03063 19:13, 10 January 2014 (UTC)

I mean that the TITL event is lost. The title value itself is not lost, it it is copied into the prefix of the name of the person, which i personally do not mind, but some GEDCOM purists may argue that the title should not be part of the name. The date, place and comments of the TITL events are copied to the general notes, not related to attribution of the title. For example, the following GEDCOM record:

1 NAME Petr /Tolstoi/ 1 SEX M

1 BIRT

 2 DATE 1645
 2 PLAC Moscow, Russia

1 TITL Comte

 2 DATE 7 May 1724
 2 PLAC St.Petersbourg, Russia
 2 NOTE title retracted 22 May 1727 after deportation to Solovky

1 DEAT

 2 DATE 17 Feb 1729
 2 PLAC Solovky, Russia

is transformed in WeRelate into "Comte Petr Tolstoi (M) born in 1645 at Moscow, Russia and dead 17 Feb 1729 at Solovky, Russia". With general comments: "7 may 1724", "St.Petersbourg, Russia" and "title retracted 22 May 1727 after deportation to Solovky".--Alexandre 13:24, 12 January 2014 (UTC)

Hi Alexandre. I've brought this to Dallan's attention. The TITL Title (Nobility) field is relatively new to WeRelate's events list, so there may be a GEDCOM import bug. I appreciate you letting us know about this! --Jennifer (JBS66) 14:06, 12 January 2014 (UTC)

I reformulated my example in more correct way. Thanks for reporting this issue.--Alexandre 21:33, 12 January 2014 (UTC)

Integer Math in a Template - Parser/String Functions Extension [15 February 2014]

I was just looking at trying to write a template, where I need a little integer math. It looks like something I could do with the expression handling part of the parser functions, but they don't seem to be present. I'm looking at creating a template to create something like the following:

   [http://www.thepeerage.com/p10214.htm#i102139 Henry Plantagenet, 3rd Earl of Lancaster]

I'ld like to create a template that looked like {{Lundy|102139|Henry Plantagenet, 3rd Earl of Lancaster}}, but I need to be able to take the second parameter, divide it by 10, and if there's a remainder, add 1 - to create 10214. It seems a waste to have the second integer parameter, if it's a simple function of the first.

Anyone have any clever ideas? --jrm03063 16:13, 14 January 2014 (UTC)

We're on an old version of mediawiki. Chances are math functions were introduced in a more-recent version.--Dallan 17:14, 15 February 2014 (UTC)

Weird Category Sort Behavior [4 February 2014]

I'm getting some weird behavior associated with sorting items in a category. The specific category is the Salem Witch Trials, and the strange sort behavior is the appearance of Rebecca Unknown in a second "W" section after "^". Rebecca is assigned to this category by way of a template (which provides a reliable category sort in many other situations - for example William Stoughton). The sort parameter I've provided is "Unknown, Rebecca". I would have expected her to show up under "U".  ??? --jrm03063 16:51, 4 February 2014 (UTC)

I don't think it's the template that is providing the sort - it is the [[Category:Salem Witch Trials|witchcrf.]] in the S3 source citation. The sorting follows ASCII sort - so all of the upper case letters come before ^ which comes before all of the lower case letters. --Jennifer (JBS66) 17:30, 4 February 2014 (UTC)

Oh.... --jrm03063 23:28, 4 February 2014 (UTC)

Possible Next Steps for WeRelate [15 February 2014]

I recently created a discussion page about possible next steps for WeRelate and the possibility of becoming a Wikimedia Foundation project. Would you please take a few minutes to review that page and add your comments (on that page, not here)? Your feedback is greatly valued - thanks.--Dallan 17:13, 15 February 2014 (UTC)

I refuse to contribute to anything involved with Wikipedia. At this point I will be ceasing my editing of WR, and will have to look elsewhere for collaborative genealogical work. Daniel Maxwell 17:16, 15 February 2014 (UTC)

Ok, would you please add your comments to the discussion page? I'd like to keep all of the discussion in one place. Thank you.--Dallan 17:31, 15 February 2014 (UTC)

A language half-measure - wikipedia inclusion alternative [24 February 2014]

On the various language wikipedia, people expect to find alternative language versions of the page (if any), listed in the lower-left hand column. For our pages, that section of screen real estate is usually empty, presenting a an opportunity. What if we populated the same space with the same language-specific WP links (not particular alternative languages - rather - all that are defined for a Person, Place, or whatever). I previously wrote a suggestion that would try to present an appropriate language extract depending on the user's language preferences. That idea is orthogonal to this, but would likewise rely on a language-neutral Wikidata address to establish a page association (from that, you can get the list of different language WP versions that have a corresponding page).

As I'm contemplating this - I'm wondering if we could arrange to have our corresponding pages WP<->WR established in Wikidata? That would make WR quite unique and interesting technically...  ??? --jrm03063 23:23, 21 February 2014 (UTC)

I am not sure I understand. Do you mean that the list of alternative language versions for a Wikipedia page would appear below the "Watchers" and "Browse" lists, and if you clicked them, it would bring up the alternative language versions of the Wikipedia page? That sounds like a step forward in making Werelate more welcoming to foreign language users, at least for pages with a Wikipedia component. --Werebear 15:15, 24 February 2014 (UTC)

Yes, that's exactly the idea. --jrm03063 15:26, 24 February 2014 (UTC)

The previous suggestion alluded to was for wikipedia pages and how to include them from the different servers, so that people could choose to get their native language - though perhaps different content that the builder of the WeRelate page read when they decided to use wikipedia in the creator's native language. Not sure that is good, but if readers understand that risk, who knows? They may actually get better material in their language. Of course, that is possible because wikipedia does all the work of providing the foreign language version. It is the production of the foreign language version that seems completely lacking from this current proposal. That is the hard part, is it not?

Ignoring cultural issues, such as different events being of interest, and naming issues, for which various workarounds seem to be progressing as needed, just the presentation of foreign language offers several problems that have been glossed over, I think. I assume that internationalization/localization can be applied to facts to make them reasonably easy to understand to a foreign language reader, which at least gives a skeleton view of the page that is understandable. So this problem seems to be centered on the narrative, notes, and other free-form text.

If one person produces a Japanese narrative, who is going to produce an English one so that there is an alternative to offer in this little list on the side of the page? Who is going to ensure that they remain in sync? I would assume that many of these may be team efforts where one researcher writes in one language and another provides a translation, like some of the discussions on various Talk pages. What if one member of the team becomes inactive? Now the translation gets out of synch and probably should be deleted. Or are you suggesting using translation software to provide machine translations? If so, then no list is needed, it could just adjust based on user preferences.

It is nice to talk about foreign languages. Nobody want to make this English only, which is predominant because most of the users are probably from the United States, but could have and may still develop otherwise. But how exactly do you imagine a researcher of one language writing so a reader in another language can understand? That is the process that needs to be defined. Where to put links on the page, if links is even the best way to offer different languages, seems like the least of the problems. --Jrich 16:12, 24 February 2014 (UTC)

GEDCOM disappeared [23 February 2014]

I had a GEDCOM in admin review and now it appears to be gone. If it was deleted/rejected, I assume I would've gotten a message, correct? Colby Farrington 06:12, 23 February 2014 (UTC)

Have you checked to see if the data was successfully imported? Maybe the 'Imported Successfully' message was dropped or delayed. I see recent contributions of things like "Family:Zechariah Eddy and Mercy Morton (1) (Add data from gedcom)". --robert.shaw 07:53, 23 February 2014 (UTC)

Those were done while matching/updating families. When everything is accepted, the contributions say "gedcom upload", like this: http://www.werelate.org/w/index.php?title=Person:Ella_Ellsworth_%283%29&diff=prev&oldid=20360924. It should have been hundreds of edits with that comment. Colby Farrington 14:28, 23 February 2014 (UTC)

As to your first question, yes, you would have gotten a message if it were removed or rejected, but that did not happen. The file should have imported without a problem, but that does not appear to be the case. Jennifer has indicated that she will contact Dallan about the issue and hopefully it can be resolved as soon as possible.--Khaentlahn 16:18, 23 February 2014 (UTC)

Dallan has successfully sent your file through to import. Sorry for the inconvenience, and thank you for letting us know about the problem. --Jennifer (JBS66) 22:16, 23 February 2014 (UTC)

Thank you very much! Colby Farrington 03:26, 24 February 2014 (UTC)

Narratives versus Facts [25 February 2014]

In cleaning up pages, I've often found myself looking at narratives that (at least to my eye) did nothing more than string together material that could as easily have been represented as facts. I also pretty much took it for granted that the fact list representation is to be preferred - it provides an obvious way to associate particular sources with particular facts - and that association would persist in a GEDCOM export.

In my primary discipline, computer science, it is almost always considered bad practice to duplicate information. So when I create a fact list from narrative information, I'll drop the narrative if it doesn't seem to add anything not apparent in the fact list. Also, while we havn't done anything along these lines, I've always considered automatic information consistency checking to be something that we will eventually want. It would be fairly straight-forward to recognize a page, where a date of residence fact was later than a date of death fact - but recognizing such information in free-form narratives is practically impossible. A fact list is also more apt to be useful in an environment where we strive for more language neutrality - since fact names can be expressed appropriately.

So are there general principles that we should have on this sort of thing? I'm willing to accept that there may be good reasons to keep a narrative along with a fact list - but "I just like it that way" probably shouldn't be among them. To be sure, I don't think a narrative should ever be considered a substitute for the fact list representation. --jrm03063 16:13, 25 February 2014 (UTC)

I'll assume that it OK for a narrative to summarize facts/records on a Person Page, versus using a narrative to replace facts.... Frankly, this is why I like using wikipedia content on Person Pages, as long as it is supported by an appropriate amount of sources and records. Just my $.02.

Jim Delijim - 25 February 2014

I'm not sure that I understand why having both is a concern unless it has to do with keeping the size of the primary page manageable or readable? I like both for different reasons at different stages of putting a page together. I want to have the Timeline available for research and reference, but once events are pretty well sorted out, I think a narrative summarizing the person's life is nicer to have front and center on the page. A narrative can include relevant analysis and discussion and can cover territory that shouldn't be included in a strict list of facts. Sorry, that one is just my personal preference. I don't want to reduce these human beings to just a series of data points. Wasn't there an idea floated around at one time about moving the Timeline to a Subpage or an attached Article? --Cos1776 17:48, 25 February 2014 (UTC)

The narratives that I find revolting are those that don't do anything that wouldn't be done by a software program that strings together sentences generated from a chronological walk over the fact list. It's not a space problem - it's a doubling of the maintenance and review problem. It also creates a situation where a change made in one location could be left at odds with another. I'm not saying don't do narratives - I'm just saying they ought to contribute something that isn't equally apparent from the fact list. --jrm03063 18:00, 25 February 2014 (UTC)

As a choice between facts or narrative, facts lose because they are incapable of transmitting as much detail so richly due to their constrained format. If there can only be one, it should be narrative. Besides not being as sterile, or as black and white, it gives researchers the freedom to discuss various things in as much detail as they want, including stories, background, conflicting views, mistakes in the past, analysis, etc., etc. which facts by themselves could not possibly communicate.

As to how to balance facts and narrative, facts appear me to be summary items with narratives providing the finished product that makes it look like somebody has actually studied the whole life of the person, not intersected it at one factoid. Most facts outside birth and death are not processed by the system other than sorting the list, so no functionality benefit accrues from their presence (and if they were desired to be processed, they would have to be more regulated as to content, e.g., fact type military would have to be specifically understood to be rank, or unit, or battle, or all three in some constrained format). They add redundant maintenance as sources and narrative get changed. Certain facts seem useful in situations where there are uncertain results, such as alternate dates, will and probate, but other than the these and the main 4, I personally see no value. I prefer to provide a more concise summary with the facts, having it understood that details will be found in the narrative, notes, and sources which are capable of nuance and depth.

Excessive facts can cause the list to extend off the visible part of the screen. Because I use the facts to quickly identify a person based on their birth, death, and marriages, I find the last particularly annoying. If the person is of interest, I will read everything on the page. But having their last marriage pushed off the bottom so so that can list 6 residences, 4 ranks in the military, 5 battles participated in, 3 town offices, and every other little detail that strikes ones fancy, in the facts, just makes pulling the critical information out of the fact list harder. It is clutter. The fact list should be like the info boxes on the families: it just a quick overview, not all the information on the family page. --Jrich 18:13, 25 February 2014 (UTC)

I agree with the problem of minor facts cluttering up the timeline. But I do not think the solution is to eliminate the facts. The current structure of WeRelate is fact-driven rather than source-driven. I try in most cases to tie my Sources to Facts. Especially in the case of some of my ancestors and their families who did indeed move five or more times across three or four different states, when and how they moved around is a key part of unraveling the genealogy puzzles. Here the devil is indeed in the details. Consider the puzzles of Samuel (Bauer or Bowers) Wilson and of his niece Mary Salome Wilson. Between them they moved around a lot and Mary had 8 recorded marriages to 7 different husbands. I do not claim to have the best-formatted pages on these distant relatives but I think I have a fairly good compilation of the known facts with some supporting narrative. --Jhamstra 18:35, 25 February 2014 (UTC)

Obviously, I concur w/Jhamstra. If the problem is that fact display is creating visual clutter - the solution isn't to eliminate facts - but to address software choices latent in the display. Some people perform narrow research - participants in battles, burials in a grave yard, passengers on a particular vessel of immigration - and who knows what else. Their contribution can't be less worthwhile or honorable if they offer it as a single well supported and properly described fact on a Person page! They can't possibly be on the hook to learn the life story of the individual beyond learning enough to be sure that the fact is being assigned to the right individual. --jrm03063 18:46, 25 February 2014 (UTC)

Did I miss something? I don't recall anybody even hinting at eliminating facts, and in fact the very reason for expressing concern over clutter, is the usefulness of certain facts. But many people lack perspective, which leads to clutter. Now clutter can be reduced by having major and minor facts, and perhaps a user preference setting combined with "+"/"-" buttons would allow each to see their own preference. The issue of clutter could also be resolved by creating two sections on the page, one for summary facts that identify the person, the other for a timeline. (Still I think guidelines are needed about what is important enough so people aren't adding facts for "John Doe turned 50".) Or people can simply use the normal method of Categories to put pages into groups. Unless accompanied by a banner, categories impose much less disruption on the format of a page so that people can tie together the subjects of their research project without taking over the page from the person who is studying the person's whole life.

But given the total lack of prevailing practice on facts, converting people's narrative into facts and removing the narrative is, I think, too much an imposition of personal preference, whether because facts are the latest technical feature you are playing with, or simply because you personally don't like narratives. Yes some present problems because they mostly talk about people that have their own pages and the material should be moved. Or they merely dump a list of children duplicating the family infobox, and should be trimmed or eliminated. Some are under-documented and need footnotes added. But overall I think the dominant practice in genealogy would suggest a narrative describing a person's life is a necessary ingredient of a mature coverage.

By the way, I think the key to "worthwhile or honorable" is "well-supported", i.e, sources, preferably reliable objectives sources that are cited, and there is a whole other school that would suggest a person should be presented merely as a collection of sources, and that the rest is redundant after that. That is more my style, but I respect that some people like narratives, and so I try to maintain them when I find them. And which is why I agree wikipedia inclusions do serve a purpose when nobody has taken the time to write a narrative. --Jrich 20:34, 25 February 2014 (UTC)

I certainly think that a more sophisticated display, with respect to fact lists, could be helpful. Beyond that I direct attention to the opportunities presented by structured information, as opposed to free form, both in terms of obtaining it and using it on larger scales. When cleaning up pages, I tend not to retain narratives that don't offer context or something that isn't immediately apparent from the fact list. The narratives I object to most, are those that appear to have been mechanically produced by report software, which turned information that originally WAS a list of facts, into a pseudo-narrative. If there's a human intellect involved in composing a helpful presentation or introduction that's more friendly - that's just fine. But there ought to be a reason, and it ought not to be instead of creating entries for appropriate facts. --jrm03063 02:39, 26 February 2014 (UTC)

Basic Tutorials [26 February 2014]

Is there any one person who has the responsibility to keep the beginner tutorials up-to-date?--Khaentlahn 15:27, 26 February 2014 (UTC)

I think the crickets chirping may be your answer - though you can certainly look at who edited them last time to see if they're interested in updating things. Are you nominating yourself? Perhaps you just not want to go in there alone? :) ? --jrm03063 18:01, 26 February 2014 (UTC)

Nominating myself... Not initially, but I will make the attempt if no one else wants to do the text tutorials. They are in dire need of updating. The video tutorials will need to be someone else's purview. I've never produced a tutorial video. I would be willing to help with a collaborative effort on the videos if need be, but not as a solo effort.--Khaentlahn 18:48, 26 February 2014 (UTC)

You might want to reach out to User:JBS66. Do you think that you should first go through and identify weaknesses, then try to address them? Or would it be more efficient to simply work through them as you find them? Like any other sort of page, the history is of course retained, so I don't think you should be afraid to make a direct assault on a page or two that seem most offensive. You can actively solicit review after the fact... --jrm03063 19:01, 26 February 2014 (UTC)

The first page needing some work would be Help:Person pages tutorial as it is the initial link on the Home page to begin any text tutorial. Attempting to go through the page with the eyes of a new user, it was very confusing. The main tutorial page appears to reference old page layouts and procedures which are no longer valid. Primarily, that page needs to be updated to present a better face to the general public and new users. Perhaps at a later date and time, the page may be broken into individual lessons and the main page can link to a list of these lessons.

In any case, while updating this page should be done sooner as opposed to later, it may be a few days before I can focus my energies on revising it. In the mean time, if someone else finds that they are wanting to tackle this or already has the responsibility for doing so speaks up, all the power to them.--Khaentlahn 20:13, 26 February 2014 (UTC)

Just sent a MyHeritage offer [27 February 2014]

WeRelate raised several hundred dollars when we sent out a special offer from MyHeritage late 2012. This one looks like a better deal than the last time since it includes access to all of MyHeritage, not just the WorldVitalRecords part. I'm sorry to send out the spam, but it's a way to raise money and we do it only about once a year.--Dallan 22:30, 27 February 2014 (UTC)

Speed problems? [2 March 2014]

Anyone else having speed problems with WR pages today? Or is it just my machine? I tried some other sites and didn't have the same slowness, so I was wondering if anyone else here is experiencing it? --Cos1776 23:14, 28 February 2014 (UTC)

We've been updating wikipedia templates with up to date content from Wikipedia for the past several days. Maybe that's the cause of the problem? I'm hoping it will be finished soon.--Dallan 23:29, 28 February 2014 (UTC)

I was having both speed problems, and I couldn't save or delete anything. The save message indicated loss of session data and told me to try again/log out, but neither worked, and I had the same problem on other browsers and my iPad - even as I watched recent changes come in, so clearly it wasn't universal. The delete page just reloaded while doing nothing. It went all evening west coast time. But if you're seeing this, clearly it's fixed!--Amelia 18:29, 2 March 2014 (UTC)

I had this problem yesterday morning; it seemed to fixed after I went and deleted something. Very strange. Was this site wide or just some of us? Daniel Maxwell 18:30, 2 March 2014 (UTC)

I had this problem ... speed + session loss + invitation to try again / log out ... in vain (I am in France) - Amicalement - Marc ROUSSEL - --Markus3 19:51, 2 March 2014 (UTC)

The session loss problem went away after I restarted the server late last night. I'm not sure what happened; I haven't made any code changes recently. (I noticed that if I checked the "remember me" box on logging in it didn't lose the session, but checking the box shouldn't be a requirement.) After rebooting the server it seemed to be fixed.--Dallan 22:11, 2 March 2014 (UTC)

I was having the session lost problems too. Thanks for the fix. Before I retired (2004) I worked in both IT support and security. One of the cardinal rules was, "When in doubt, punch it out." Seems to have worked this time. That's still good advice much of the time (but think about any reasonable alternatives first).--jaques1724 23:05, 2 March 2014 (UTC)

Cleaning up pages [7 March 2014]

Is there a dedicated page in the help pages for instructions on cleaning up pages? --Beth 02:20, 4 March 2014 (UTC)

Beth, I intend to upgrade such a guide. Need to talk to some others first. Daniel Maxwell 15:25, 7 March 2014 (UTC)

It is good that someone is at least looking at this. What guide is it that you are updating? Someone seriously needs to explain to people how the genealogical version of the sunk cost fallacy is crippling the quality of genealogical wikis like Werelate.--Werebear 16:44, 7 March 2014 (UTC)

I had wondered the same thing a few months ago. I tried to start a discussion here, which didn't really go anywhere. (Some of the pages I linked to as examples have been changed since then.) I found it disheartening that the discussion ended up going nowhere, but I suppose I was trying to start it in the wrong place. Maybe, judging from the crickets chirping in response to your question, there is simply no interest in such things here?!?--Werebear 13:59, 7 March 2014 (UTC)

I brought up the topic in a conversation on this page recently, however that thread has flagged as well. I don't know how general my suggestion there is; it was intended only for Karen Theriot Reader's GEDCOM. Cleaning up all the dumped GEDCOMS on WR is a monumental task. It could be partially automated. A simple rule for Karen Theriot Reader's GEDCOM might be to move all her narrative text to a note for person pages not edited since the GEDCOM upload.--Prcb 15:23, 7 March 2014 (UTC)

Place drop down menu [8 May 2014]

I find I'm not getting a drop down menu when entering a place name on a person page. It works on a person search page however.--HLJ411 21:24, 7 March 2014 (UTC)

• I find this function does not work some days/some sessions but then it comes back Artefacts 04:42, 15 March 2014 (UTC)

I had the same problem but I realised that it works as soon as you put a space after the place name--MWalker 13:36, 8 May 2014 (UTC)

'Anachronistic' place names and personal preference [22 March 2014]

There was a mini revert war between an admin and one other user recently about so called anachronistic place names; ie the modern place name vs. the historical place name, in that case whether or not the place should be in 'Massachusetts, United States' vs. 'Massachusetts' (colony). If I wanted to, I could hairsplit and say that no, there was no such place called simply 'Massachusetts' at that time, either, it was 'Massachusetts Bay'. There has been some leeway with this, i.e. the person working on it writes it as they like, and neither or wrong, but there is a problem when users are reverting each other's work. Should there be a more hard policy on this matter? The solution I thought of was that maybe older (ie colonial, non existent counties, countries, etc) place names might display vs. modern place names as a user's dash board preference. For example, I have 'older place names' setting on, and thus WR will show the older place names. If I have this setting off, then it shows the modern place names. How this might work - in the place page, names could be set by year, ie 'Colony of _____' before the United States existed. Without such a compromise, it seems this could get into an editing war of what I like vs. what you like.--Daniel Maxwell 02:27, 15 March 2014 (UTC)

To me, this seems like the sort of thing we need to figure out how to resolve, as a community. I think that having a setting to display things differently sort of defeats the purpose of having one shared page. Personally, my vote is to show the place name as it appeared at the time, but linking to the modern place name. However, I'd be happy to support an alternate scheme. Either way, I think this is the sort of thing we should have a policy about. - 13:42, 15 March 2014 (UTC)

In terms of factual accuracy, you cannot use current place names to accurately indicate the location of a large portion of historical vital statistical events. They simply do not accurately indicate the actual geographic location of the event anymore, for a number of reasons, including, in the west, that places often tend towards amalgamation and increase in size. Given the scope of WeRelate, embracing description of facts that use the tightest possible normalized geographic descriptors (shy of street addresses which can be input in the note field) is a necessary adjunct to correctly differentiating people with the same name. Accurate genealogy depends on doing comprehensive geographic research to properly situate people. Additionally, place names are going to continue to change so embracing a system that accommodates documentation of change (linked, parent-child records, etc. like the one we currently have), while it may seem like a lot of work, is a reasonable response to this reality. It also fishtails with record access. As an example, you can search Toronto records until the cows come home and never find information on people who lived in Yorkville (now a neighbourhood in midtown) between the 1780s-1940s when it was not within the city limits. As a second example, if a place's name changed, there may be excellent records under the preceding name which will never be found if someone does not undertake (and preferably document here) research on the differing names for that location.

PS Some people are naturally inclined to simplicity and want to reduce, reduce, reduce, as much complexity as they can get their hands on, but there are huge sacrifices made in the service of this misguided ideal of minimization. There are no informational gains. Normalization and standardization of information with pull-downs and standardization of spelling is, however, worthwhile.Artefacts 16:52, 15 March 2014 (UTC)

It would be inaccurate to characterize this discussion as for or against accuracy. My experience has consistently been that "historical accuracy" is a mantle that some people cloak themselves in while providing names that are no more historically accurate than the names they are changing. While the place fields have had structure added (simplified?) to allow places to be understood and processed in a limited way by the computer, to centralize data about the place in a single location, and to be more accessible to the kinds of new users that attend this site, there appear to be plenty of opportunities elsewhere on the page to communicate accurate and precise locations, including use of Template:GoogleMap in the description field, and justifying and documenting homestead locations or parishes in source citations or in the freeform narratives.

This is a discussion about the use of piped names in place names. The use of piped names is very controversial because there is no guideline and use is by perceived purpose rather than guided by any policy. The perceived consensus to me seems to be to remove them, as this seems to be totally or partially what makes up most of the changes I see in my watchlist notifications.

My personal opinion concurs, as I believe that piped names represent a less than desirable feature for several reasons:

• in simple display, they obscure standard place names leading to undiscovered errors in links to place pages
• they cause different pages to name the same place differently, causing confusion to new users and encouraging undisciplined data entry.
• attempts (rarely correct) at historical accuracy are mostly indistinguishable from personal preference and GEDCOM chaff
• they provide a battleground for competing personal preference
• in any processing, such as Pedigree maps, the computer will ignore the piped name and only operate using the linked Place name

In order to have an orderly use of piped names, some form of guideline is needed about what is considered appropriate piped name. In a community database, it is hard to think that personal preferences would be an appropriate reason. Certainly the preference of one user is the pet peeve of another user. It is hard to think that historically accurate names can be made distinguishable from arbitrary variations without a major development effort to add software support and ensure consistency. For adding preciseness, no piped name will be understood by the computer, so it is not clear why the Googlemap and freeform areas of the page are not the better method to provide details, justification and explanation in whatever form will be most helpful to readers not so familiar with the place, both for clarity of communication and to avoid the shortcomings of the list above. The only use I see that is necessary for piped names is as a place to save GEDCOM input, which is inherently arbitrary, until the automated place matching the computer provides can be verified by a human, which is then signaled by removing the piped name. --Jrich 21:59, 15 March 2014 (UTC)

I'm coming at this with an understanding that "piped name" means name pulled down from the place space index, so Jrich, if that is not what you mean, please let me know. I think we should have a policy and training to strongly encourage people to pipe in the place name in all fact fields, rather than typing in something that is not a place space. However, the ability to add places that are no longer current is necessary for factual accuracy and specificity, so I disagree with your statement that the place discussion is not about accuracy (not sure we are talking about the same thing though). It is absolutely possible to assign a historically accurate value, that is, the legal name(s) of the geographic entity of the event at the time it occurred, with the highest degree of spatial specificity possible and which is derived from a contemporary source. This creates a multitude of additional place pages, however, they all have tremendous value as the place names are associated with specific source materials, administrative histories, and contemporary narratives and links to such materials can be lost or confused if the place name changes over time are not recorded and represented in a way that editors can get at and use.Artefacts 22:20, 15 March 2014 (UTC)

"Piped" is a reference to the following example: Place field:Cambridge, Middlesex, Massachusetts, United States|Cambridge, Middlesex, Massachusetts. The "|" is the pipe which makes the system standard name of Cambridge, Middlesex, Massachusetts, United States appear as Cambridge, Middlesex, Massachusetts on the page that a user is viewing.--Khaentlahn 23:47, 15 March 2014 (UTC)

Got it, "piped"=assigned display value of the internal link. Not relevant to the angle I am coming from.Artefacts 01:07, 16 March 2014 (UTC)

I don't think this can be reduced entirely to a debate about the use of piped names on Place links, although that certainly comes in to play. I don't think the Cambridge example given above is a very helpful example for the more substantive issue being raised here. Let's talk about something more interesting, like the town of Huncovce in Slovakia. At the time that my great-grandmother's birth was registered there, the town was called Hunfalu, and it was in the kingdom of Hungary. A century later when the good LDS folks took microfilms of the church records there, it was called Huncovce, in the former nation of Czechoslovakia. Currently, WR has a Place page for "Hunfalu, Szepes, Hungary" and another one for "Huncovce, Kežmarok, Slovensko, Czechoslovakia", neither of which reflect the fact that this place is today in the nation of Slovakia. Ideally, there should be one page for this town, which has existed continuously through its various name and nationality changes. But when I reference the Place page for that town on my great-grandmother's page, I would like it to show up as Hunfalu, Szepes, Hungary, because that's what it was when her birth was registered. When I go to that page, I would like to find all of the information about the town through the ages on the one page.

WR already has some features that help with this. The "Located in" field on the Place template supports having multiple "Located in" fields with time ranges, so I can indicate that it was in the Hungarian megye (county) of Szepes prior to 1918, and in the Czech region of Kežmarok after 1918. If we had similar date range information on the "Alt name" field (or perhaps a "Former name" field), that would enable automated processing (such as timelines and Place name links) to provide the appropriate historical place name for the "fact".

Amen to the above 2 paragraphs. The Austro-Hungarian Empire ("Austria-Hungary") isn't even a country here. LDS re-assigned one of my ancestral Slovak villages to an entirely different place and the only viable record is for Hungary (which I don't mind because that is not anachronistic to my time span, but for later records it would be a wee bit misleading). I could not make the parent to child or associated relationships work using the existing place space indexing list (pull-down)PS I think you are basically proposing a series of date-activated AKAs which would work as far as I am concerned Artefacts 01:07, 16 March 2014 (UTC)

In the mean time, how should such a situation be handled? That is the real question here. Should I make the Hunfalu page redirect to the Huncovce page? (And if so, should that new page preserve the distinct FHLC template from the old page? And if so, how?) If WR will let me, shouldn't I link my great-grandmother's birth registry place to the Hunfalu page (even though it would now be a redirect)? And if it won't let me, wouldn't it be appropriate to use pipe notation to show her birth registry place to be "Hunfalu, Szepes, Hungary" rather than Huncovce? TomChatt 00:58, 16 March 2014 (UTC)

If editors are coming along and de-rendering piped display names which match the name of the location at the time of the event, in order to modernize (or standardize) place display in the text, particularly if they are already a viable link which provides all names for the place, that is not an editorial policy which you would see in any respectable historical publication (because it introduces inaccuracy and misrepresentation). It is also a huge waste of time and could become offensive in situations. I have ancestors who were United Empire Loyalists and fought and died (and mostly lost all their property, lol) and if I write it Massachusetts Colony and someone wanders in declaring they lived in a state the person repudiated in their lifetime, that would be kind of obnoxious and unnecessary bureaucratic lollygagging.Artefacts 01:14, 16 March 2014 (UTC)

And quasi-political approaches to representing information are exactly why freedom to choose one's preference should be outlawed. The 1900 rules may cause certain discomfort, probably for most people at one time or another, but it is impersonal and not aimed at anybody. Perhaps while he works on creating his mechanism to support private and public spaces, Dallan can allow personal place aliases that one can have displayed by preference, without foisting them on others. --Jrich 02:34, 16 March 2014 (UTC)

Geographical settlement names are by their very nature political entities. There is no "quasi"-ness in my argument. If place names from 1900 were selected because administration beyond that scope presented practical impossibilities, then become a wikimedia site already and grow into a sophisticated, high quality site that uses industry-standard editorial techniques to accurately represent information instead of bullshit work arounds that freeze a thousand years of history to a reality represented by 1 arbitrary year a hundred and thirteen years ago.Artefacts 02:47, 16 March 2014 (UTC)

I agree with Artefacts. All place names are political. Sometimes the changes in jurisdiction are a result of civil action, sometimes a result of military action. Not to mention places that were settled 200 or 300 years ago but no longer exist due to geological or demographic events, or were not settled in 1900 but now exist. You cannot freeze geography at a point in time. For my own ancestors this works reasonably well because the places have been relatively stable, but for many other parts of the world there have been major upheavals. For some families I am researching in the interior of the US of A 1900 is a rather unfortunate "freeze point" because they were still "Indian Territory". And some of these rural villages have since disappeared! I could show you many examples in this part of the US of A where the WeRelate "standard" place names did not exist in 1900 so whoever is maintaining the database does not follow the rules. Nor have I chosen to go into trying to "fix" these entries because the 1900 names if they existed at all do not make any sense whatsoever to anyone trying to research those places. I could cite other examples including the German settlements in what is now the southern part of Ukraine, etc, etc, usw. Historical facts on the ground will ultimately trump any system of conventions.--Jhamstra 10:52, 16 March 2014 (UTC)

I think place is ultimately identifying a spot on the planet earth. The ideal way would be some form of geo-coordinates so you can show a spot and change the political rearrangement of the map underneath the spot at will to whatever time you find most useful. But since few people have researched things to that level, we are left assuming it falls somewhere in the jurisdiction of some political entity, which is often a rather vague estimate of the location. But the political entity is not what we are trying to communicate, it is location. The location is the same today as it was in 1900 as it was whenever. The political entity changes. --Jrich 14:43, 16 March 2014 (UTC)

As a counter to the opinion that "place is ultimately identifying a spot on the planet earth" (which could be done by reducing to latitude and longitude, what engaging narrative that would make): place is a socio-historical context in which life events occurred. The name(s) of places provide human-readable access to linked information associated with those events. If you are not prone to seeing (or modelling) reality across large chunks of time, you won't care about this dimension; but seriously, as a genealogy site, you have to expect the vast majority of users to be very, very interested, in the historical time dimension and how it is represented. We are not recording geologic events here. Artefacts 18:16, 16 March 2014 (UTC)

Has anyone ever noticed what we did to Ireland? Ireland did not split into the Republic and Northern Ireland until 1922 and yet we must choose between one and the other when giving a place for those who left with the Famine before 1850. --Goldenoldie 16:47, 16 March 2014 (UTC)

Lol, noticed that. Also, fyi I recently discovered, working with Canadian and American immigrants, that when they documented their own origins, they frequently referred to their Irish townland (which French Canadian priests then recorded incorrectly as their parish), which are 60,000 geographical entities that basically do not exist on the Internet except in lists on wikipedia. Artefacts 18:16, 16 March 2014 (UTC)

Because some places existed only before or after that arbitrary reference point in the early 1900s, the Place pages may not be historically accurate in how they are named. But it should be remembered that the Place page name is only an arbitrary name which is used to name the unique wiki page. It probably could have been a unique 12 digit number or some other computer code, but instead it is the name of the place to make it easier for humans to use (and that is how wikis typically name their pages). The software and database would probably have to be significantly improved to incorporate the kind of flexible naming that has been suggested. Many Place pages are for small well-defined (specific) locations, but many (most?) are not. Such non-specific locations are usually political divisions of varying sizes which may have changed many times during their history. (But it should be noted that even city pages are non-specific on a small enough scale.) I think that allowing pipes is the simplest way to allow flexible naming. Yes, some people may argue over the proper historical name of a place in a given time, but I would be willing to risk that to create a better history. Besides, the page names that are displayed don't conform to normal genealogical standards (ie. displaying "Smithville, Smith, ..." instead of "Smithville, Smith Co., ...").

I realize those in the "Minimalist" camp don't like extensive use of the fact list and would relegate the place fields to the arbitrary page names without pipes. But making a feature (like piping) available for use by the users and then slapping their hand when they try to use it is not conducive to cooperative work between individuals. I have been making use of the feature more frequently. However I avoid editing pages owned by other users who may be Minimalists because I have no desire to argue over stylistic issues. Luckily, most of my tree is not shared by anyone else. But it also means a few areas may not benefit from my desire to research. But I do not have a shortage of work. Where I do use the piping is when I desire to override the default names to make it more historically accurate or more understandable for the reader. My primary concern is the human reader, and if the computer happens to understand what I'm doing, bully for it. But the human reader should never be a secondary concern, especially when doing serious research. —Moverton 05:25, 21 March 2014 (UTC)

Yet a piped place name is unable to explain to another human why that pipe is needed or essential, so is that not, in essence, making it more difficult for a human to understand at least from an editing perspective?--Khaentlahn 05:46, 21 March 2014 (UTC)

We don't edit in a vacuum. Understanding should come from the source or the associated descriptions. I would hope there aren't people going around eradicating pipes merely because they exist. There may be many pipes created in the GEDCOM upload process that can be eliminated because they didn't get linked to the correct place. (Just guessing, I don't use GEDCOMs.) But I wouldn't make a blanket statement about all pipes. —Moverton 01:00, 23 March 2014 (UTC)

Where GEDCOMs are concerned, unless the creator of the GEDCOM has the exact same place names in their GEDCOM that WeRelate already contains, the review matches them to the most likely candidate, as it should. Anything that is matched, whether by the review program or by the user, is modified on every matched page with a piped name, thereby allowing for the original to be retained. Chase Co., Kansas, USA is produced as Chase, Kansas, United States|Chase Co., Kansas, USA. A user may then go through their pages and eliminate the computer-generated pipes. This rarely if ever happens, so these computer-generated pipes go into the wiki. Has there been an overall determination concerning whether these computer-generated pipes should be retained or removed?--Khaentlahn 01:20, 23 March 2014 (UTC)

My approach to my own work is to avoid using pipes unless they actually add information - eg the name of the place has changed, the "standard" name is ambiguous or incorrect, etc. When I encounter an obvious "GEDCOM pipe" in someone else's work, I generally remove it unless it appears to add information.--Jhamstra 06:46, 23 March 2014 (UTC)

Why can't I use external link in Talk pages [20 March 2014]

Hi,

Why are external links in Talk pages not allowed? For I certain I want to Talk about his mother, because the one listed on that page differs from the name registered in the Churchbook. So, obviously, I'd like to include a link to the Church book images available from the Regional Archives. When saving the talk pages I get this error: External links are not allowed. Why not?

Fred--BigBearFreddy 07:46, 16 March 2014 (UTC)

What kind of talk page? I attempted to add an external link to a Person's talk page and was successful. —Moverton 05:38, 21 March 2014 (UTC)

Links to FindARecord.com [11 April 2014]

If you have a place but not a source for a birth, marriage, or death, I've added a link to FindARecord.com in the upper-right of the Person page above the family infoboxes. FindARecord is a relatively new website by a friend of mine. Please tell us what you think.--Dallan 23:09, 8 April 2014 (UTC)

It's not a bad WIP, but I find the placement annoying. Could it be moved into the 'blue' area that contains the name? Daniel Maxwell 02:21, 11 April 2014 (UTC)

I'll move it tomorrow.--Dallan 05:24, 12 April 2014 (UTC)

Porting Source(s) from Family Page to Person Page [11 April 2014]

I recently noticed that person pages now display a source # for the marriage data. This seems to occur whether or not the sources cited for the marriage on the family page are even present on the person page. This is more than a bit confusing and introduces inaccuracies in the person pages as displayed. This is a kind of lame description of the problem, but see the following pages as an example.

Family:Weeks Williams and Mehitabel Cone (1)
Person:Weeks Williams (1)
Person:Mehitabel Cone (2)

--jaques1724 01:46, 11 April 2014 (UTC)

Yes, this is a system wide problem now. See Person:Edward Bugbee (2) that I have been working on as another example. It's even uglier on pages where there is no source for birth/death dates. Example: Person:Richard Chamberlain (1). Daniel Maxwell 02:22, 11 April 2014 (UTC)

Yes, sorry about that. I'll fix it tomorow.--Dallan 05:24, 12 April 2014 (UTC)

Gedcom software [12 May 2014]

I'm a bit of a beginner, and have hand entered many pages quite painstakingly. I've been finding just about all the birth, death and marriage registration documents on http://www.allegroningers.nl/. Then I noticed that you can export from there to Gedcom and import Gedcoms here. Except that didn't go too well because for some strange reason their default birth date for people (e.g. the parents of a bride and groom whose birth dates are not mentioned) is 1970. So I thought that maybe it would save me some time to get some kind of Gedcom software that I could pull all these funny records into, clean them up and link them properly, and then only once I had a decent set of data, import it to this site.

My question is... what (preferably free) gedcom software do you recommend?--MWalker 11:30, 12 May 2014 (UTC)

There are a lot of problems with AlleGroningers' GEDCOM export. Just a few issues:

• Does not export the place of birth.
• Excludes the name prefix (so van der Pers just exports as Pers). Also does not use the GIVN or SURN tags.
• Appears to exclude the marriage date and place
• You miss important data in the index, such as parents' age at child's birth, spouses' age at marriage, and source citation.

I would strongly caution against utilizing the GEDCOM export from AG. --Jennifer (JBS66) 12:06, 12 May 2014 (UTC)

Yes I noticed that - waste of time! I'm also so annoyed that after I carefully linked all my ancestors' records back to AG, they changed the links. I've written to them to complain, either they should have no links at all, or they should respect that the links must have ID's on them and never, ever change. No point otherwise!

Anyway, thanks for your response. Back to the old fashioned way... doing it by hand :-)--MWalker 12:17, 12 May 2014 (UTC)

If you are worried about links changing in the future, might I humbly suggest creating a Template. This was done with good success for Find A Grave (see Template:Fgravemem) and Billion Graves (see Template:Bgraves3) and other such sites. [My Disclaimer: I am not familiar with AlleGroningers so there might other factors of which I am not aware. :) ]. Regards, --Cos1776 15:02, 12 May 2014 (UTC)

Warning notice on place pages [16 June 2014]

When I go into "edit" mode on the place pages for English counties I keep on getting this warning:

WARNING: This page is 80 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections.

I have several questions:

1. Should we just forget about it? Computer memories and online facilities have moved on from when it was put into place, probably, in 2007-08.
2. The length of the page is caused by the number of individual places within the county—not by the descriptive text added from Wikipedia or written by ourselves. Without reducing the number of places listed how can we break down the page into smaller sections?
3. Could the warning be removed?
4. How would one go about making a continuation place page where we could safely expand the data we would like to provide?

--Goldenoldie 18:23, 7 June 2014 (UTC)

I took a look at the code, and it looks like this message will appear on any page that is over 29 kb long. It looks like it would be very easy to either:

1. Increase the limit
2. Remove the message completely

I'd be happy to make the change, and submit it to Dallan. For what it's worth, it looks like Wikipedia got rid of this message completely.

-- Jdfoote1 22:00, 8 June 2014 (UTC)

For the record, the Great Migration sketches page also gives me that warning. Could this change be made centrally or would it have to be done on a page by page basis? It seems to me that we don't people to make pages too huge (ie putting the entire content of a book on a person page), so maybe the limit should increase but not be eliminated? Daniel Maxwell 03:01, 9 June 2014 (UTC)

I would be pleased to see it disappear. As I said, on place pages, it is usually not our fault. But, any suggestions on point 4? I would like to make lists of groups of administrative areas within British counties and include a map locating the areas, but there just isn't room for the map along with the text and the county list of places. Maybe these would be worth a "Portal"?

--Goldenoldie 07:05, 9 June 2014 (UTC)

Jdfoote1 kindly made a code change to remove the warning. This seems like the best thing to do since as you say, browsers are much more capable now. I've merged in his change so the warning no longer appears. Thank-you jdfoote1!--Dallan 19:28, 16 June 2014 (UTC)

Translating WeRelate to other langauges [10 July 2014]

Are you interested in helping translate the WeRelate interface to other languages? If so, please visit the following page: WeRelate:Messages --Dallan 04:58, 17 June 2014 (UTC)

It's fine ! Thank you ! I can help, but I need other contributors ... my english is basic and I don't know all pages and functions of WeRelate. Amicalement - Marc ROUSSEL - --Markus3 06:14, 17 June 2014 (UTC)

Is it possible to create Russian page ? If yes, i can help with translation.--Alexandre 16:31, 4 July 2014 (UTC)

I expect that Russian would work, so I've been bold and added a Messages page for Russian. I'm just another user, so it's possible that this isn't quite right for some reason unclear to me, but I think you're set to do some translations. --robert.shaw 20:49, 4 July 2014 (UTC)

Dallan has looked it over, and the Russian translation page is ready for use. --robert.shaw 18:53, 5 July 2014 (UTC)

I finished the translation to Russian. Some remarks:

For the moment I left the name of the project in the text in English "WeRelate". I can put Russian translation "МыСвязываем" , but it does not sound very attractive and i do not know what will be the policy for other languages. What will be the policy ?

In some cases exact translation depends on the context, so more iterations will be needed when the site will start working in Russian

It will be nice if somebody could independently review this Russian translation

--Alexandre 00:23, 10 July 2014 (UTC)

Request for Volunteers [17 June 2014]

If you are interested in helping out at WeRelate, we could use help on two committees:

• GEDCOM review
• Source patrol

Would anyone be interested in helping out? It's not a big time commitment and it does make a difference.--Dallan 05:05, 17 June 2014 (UTC)

I can help on either one or both. --Cos1776 16:49, 17 June 2014 (UTC)

Ancestry and Find-A-Grave DDOS Attack [17 June 2014]

Ancestry and Find-A-Grave (recently purchased by Ancestry) have been down since yesterday. Ancestry has released a statement here:

http://nutfieldgenealogy.blogspot.com/2014/06/ancestrycom-ddos-attack-press-release.html

While Ancestry has come back up (albeit intermittently and with limited search capability), Find-A-Grave remains down, at least as of now.

Several other genealogy blogs are reporting the same information.....

Jim--Delijim 20:04, 17 June 2014 (UTC)

Possibility of updating the style sheet [9 August 2014]

This is me being anal retentive and I don't want to cause extra work but I thought I would bring it up to see what would be involved and if anyone else in the community has also noticed this. Namely, the current style sheet which generates the orange headers and related design elements seems to me to present the following problems:

1. it is difficult to match non-header design elements in the body of the page to the font, color, and box style,
2. it doesn't print well so content has to be dropped into a word processor and reformatted prior to being printed for distribution (i.e. to family who aren't going to go to the web)
3. it is starting to look a little "Internet 2005"
4. I like to think of myself as a historian-genealogist and it is bit too far towards campy and away from academic style for me to take it seriously
5. might just be me/led screens but the eye does not pick the header out quickly on viewing.

Anyway, I wondered if anyone else thought a bit of a style update might be called for. I am not asking for investment in redesign if resources aren't there, maybe just reverting to defaults.--Artefacts 18:43, 30 June 2014 (UTC)

I agree - would anyone like to help work on a new stylesheet for us?--Dallan 03:27, 4 July 2014 (UTC)

I might be interested in having a crack at it. I'd try to implement it as a stand-alone skin and move all skin JS/CSS/imgs to it. I'll start a PR on github, so others can see what I'm doing. — Sam Wilson ( Talk • Contribs ) … 05:10, 4 July 2014 (UTC)

Thank you.--Dallan 05:11, 4 July 2014 (UTC)

Is it possible selecting the style could be a user preference? --Jrich 05:23, 4 July 2014 (UTC)

Yep, skin-selection is part of Special:Preferences. There's only the 'MonoBook' option at the moment, but more can be added. — Sam Wilson ( Talk • Contribs ) … 05:32, 4 July 2014 (UTC)

I am sorry that I do not program, but maybe these will help: http://www.mediawiki.org/wiki/Category:All_skins --Artefacts 02:47, 11 July 2014 (UTC)

I agree, and is it just me, or did the font size on the stylesheet seem to get a lot smaller? It's even small when I compare the pages to Wikipedia, and that's pretty small. I know I can change my default font sizes, but then all the other websites look huge. I can also zoom text of course. I was just thinking that a lot of the users are likely older folks, and there may be challenges seeing the text. – Parsa 23:35, 9 August 2014 (UTC)

WeRelate Thesis [3 March 2015]

So, I recently defended and submitted my Master's Thesis. I study online communities, and how people become engaged in communities.

The context of my thesis was actually WeRelate. I took the edit history of the site from Jan 2007- Feb 2013. I categorized people based on what types of pages they edited, how often they edited, and how many pages they edited.

It's very long, but if anyone wants to read it, it's online here. I'd be very happy to answer questions, or even better, to get any insights or comments that you have about the paper.

-- Jdfoote1 21:31, 9 July 2014 (UTC)

Thanks for an interesting piece of work. I am now in your low activity category. A big reason for this is that those of us who are primarily interested in certain families or places, eventually uncover almost everything that can be learnt on our favorite subjects. Once that has been captured there is a relatively low level of ongoing maintenance of the portions of the database where we could contribute.

It is unfortunate that your interaction model could not capture those of us who return to pages we are watching after others make updates. This would not be visible in your study for two reasons. (1) We do not need to login to view the changes that others make. (2) Page views are not logged - only page edits.

I also suspect that failing to distinguish between those who do GEDCOM uploads vs those who tend to contribute their data in situ, misses a lot. These are two very different modes of contributing data.

--Jhamstra 12:16, 10 July 2014 (UTC)

Jhamstra - very useful and interesting feedback. Previous studies of WP, for example, would suggest that once people finished with the things they are interested in, they might move on to other activities on the site. I could definitely see how genealogy as a context might be different, though. If all you are interested in is your own direct line ancestors, then once their information is reasonably complete, perhaps you would be "done".

I agree that there are certainly some interesting interactions that are missed. I was tempted to try to use watchlists, but it has its own problem - jus tbecause something is on your watchlist doesn't mean that you've seen any changes.

I also agree about the importance of GEDCOM uploads - if I were to do further analysis, I think I'd focus on detecting those users.

-- Jdfoote1 13:56, 12 July 2014 (UTC)

Well I am interested in more than my own ancestors. I have also traced the ancestry of various relatives and acquaintances. With regard to places, I find the 1900 rule to be a major dis-incentive. One of the places where there is error and confusion in the existing WeRelate database was in a state of transition from "indian" territory to immigrant settlement in 1900. I could add and correct a lot of information there but I chose to walk away. For me it is worth going to the trouble of extending and correcting WeRelate date regarding people, because WeRelate provides a fair bit of useful infrastructure for this process. I have also added a dozen MySource pages, as well as adding and correcting some Source pages where appropriate. It is not worth extending and correcting WeRelate information about places. I simply override the Place pipes where I think things can be captured more clearly. --Jhamstra 14:26, 13 July 2014 (UTC)

I wonder if there is a learning point for the site here? Maybe we need to find more ways to encourage people to "hang around" once their own ancestry has been exhausted - perhaps through broader projects such as surname studies, branching off into work on sources or places, or developing individuals into "featured pages". AndrewRT 18:32, 12 July 2014 (UTC)

I think that is right on. If I had to summarize what I think the findings are that could be translated into suggestions for the site, they would be:

• My best guess is that those who become really active users are not genealogy neophytes nor technology neophytes when they join WeRelate. This suggests two possible courses of action:

1. Greatly simplify the site to appeal to new genealogists. Put up more training material, etc.
2. Focus on recruiting other genealogists who have time and experience.

• Figure out how to keep the active participants active. People disengage slowly, which may indicate that they are looking for ways to continue participating.

-- Jdfoote1 20:46, 12 July 2014 (UTC)

If interested in why older genealogists hang around or leave, I'll add my 2 cents. I've been around since June 2007 on and off. On when I've decided to upload yet another GEDCOM and off when I leave in frustration because I have had to stop the GEDCOM review process to create new place, source and cemetery pages. Sometimes it just seems like the results may not be worth the effort. Especially with us older folks who are not so wiki literate. Another large frustration is that the items on the suggestion page never seem to get addressed. Actual bugs get fixed but real suggestions for making the site work better are still sitting there and I expected some progress over this period of time. I am certainly willing to work on a site still in beta but when, oh when, will these suggestions ever get addressed so the site can come out of beta?? I could be patient easier if I saw even just a few suggestions marked through as completed so I'd know some progress was being made.

I think the mentoring idea is a good one but it needs to be in conjunction with getting those suggestions implemented so that things work more smoothly. Without that, mentoring will still be an uphill trek. A select few made me feel very welcome and I still miss them since they've left. --janiejac 17:17, 16 July 2014 (UTC)

i am a visual learner, so large portions of text are a problem for me. pray tell in a few paragraphs what you learned?

i came to this site almost a year ago (i guess) and the first and foremost driver for me to hang around and add contributions (now about 20K) is, that i was welcomed by users Lidewij and JBS66. Not in a traditional way (hey hi there!) but because these women improved my newly added pages. So what i noticed was that my pages (which are not mine, another wonderful feature of WR) were increasing in quality.

thx, Ron woepwoep 12:44, 30 July 2014 (UTC)

Before this 2014 topic (and the link to its fascinating thesis) get relegated to last year's archive, let me express my sincere appreciation to Jdfoote1 for his thorough scholarship and his well-studied investigation into the social-science aspect of WeRelate. It leaves me somewhat curious to wonder about the roles I've played here since joining WR back in 2008 and the transformation I've undergone between those varied roles during that time. Well done!

And since we're talking statistics, user and behavioral roles, and corresponding activity and contribution levels, it's interesting to note that this Watercooler topic, one that to me is of such scholarly interest, garnered discussion of only a mere 1,108 words (or 5,150 characters - prior to my contribution), in comparison to the inane topic (yes, that's my opinion) of "placement and format of a married woman's surname" which accumulated serious discussion of 3,438 words (or 16,110 characters) in the February 2015 Watercooler discussion, a statistic reflecting what I suspect corresponds to and correlates to roughly three times the interest level of the more educated and scholarly contribution. Interesting...

Seems like fellow WR user janiejac and I are playing on pretty-much the same sheet of music, and I think I need to address and expand on three major concerns here further.

• Like janiejac, the download GEDCOM process here at WR has been a major frustration for me as well; more accurately, not so much the application process itself, but the management and oversight of it. It seems once the initial functionality of it was tested and validated, the management of it was given to others with a more iron-fisted approach, to those who I have to refer to as Big Brother Monitors, admins who strictly enforced contribution revision timelines, not taking into account or being able to distinguish between serious users making steady progress of making changes, modification or improvements to their downloaded GEDCOM files, and other casual users who dumped GEDCOM files of questionable quality into WR and made little attempt to validate, improve or source their data dumps. Personally, I had three such files deleted while improving them, valuable time I lost and wasted effort I can never replace, both very important and high priority at my age.
• Then WR implemented the capability to freely upload well-researched and well-sourced data here in WR converted into a GEDCOM format that could then be freely taken and dumped into subscription-based websites where we ourselves later might look for further research on our own ancestral lines, and then be faced with the quandary of deciding whether or not we should use that same unsourced and unattributed data previously taken from WR without our knowledge or without clues to be able to distinguish the source, to then add that data as source material to our own research investigation and then have to credit the data-thief or plagiarist as the creator or source for the uploaded and re-dumped data, creating a vicious circular dilemma for our records or Catch-22 situation for us. I've seen that happen a number of times in my research over the last 20 years (not necessarily related to WR data yet). This topic too was discussed in part earlier this year as a Watercooler topic relating to finding WeRelate pages copied elsewhere without attribution, (addressing only part of the problem).
• And I agree too with the uncertain status and progress of program suggestions made for WR application improvements, a lot of it collected because of a much heralded move a few years ago calling for improvement recommendations here at WR. I certainly understand and appreciate that real-life (i.e. income-producing activities) sometimes gets in the way of personal interest (i.e. hobbies and contributory activities), but to have this application in Beta-mode for almost 10 years is somewhat disconcerting and worrisome when I think about the investment of time and effort many of us have placed in creating and adding data here at WR.

Just a few thoughts I had to add. --BobC 06:05, 3 March 2015 (UTC)

Embedding Google Maps needs updating [9 August 2014]

I am a big fan of the feature added a few years ago to be able to embed Google maps. (For background, Google lets you create custom maps with your own points of interest plotted on them.) I find it very helpful to see on a map the various places where a particular person or family lived, worked, died, etc.

Alas, Google seems to have changed around the way that they do their custom maps, such that newly created custom maps don't work with the <googlemaps> feature that exists on WeRelate (see WeRelate:Suggestions/Embedded Google Maps). Pre-existing maps still work fine, but newly created ones under the new regime do not. Perhaps Dallan or some other tech folks on the site can take a look? If you want a "new" map to play with as an example, take a look at Person:Paul Taylor (8). You can see where I've attempted to embed the Google Map using the technique that used to work, but it just gives a big blank area. It does provide a working link at the bottom to get to the map. I suspect it has something to do with Google changing the way the embeddable map is presented.

Thanks! TomChatt 22:43, 3 August 2014 (UTC)

I discovered that if you change the word "viewer" in the URL that you get from google for new-format maps to "view", it works. (I'm not sure why.) I've updated the documentation.--Dallan 04:25, 6 August 2014 (UTC)

Thanks, that seems to have done the trick! --TomChatt 05:46, 9 August 2014 (UTC)

Standard Google map on place pages [6 August 2014]

Would it be possible to have the location pin for a place closer to the center of the map in the north-south direction? It is currently so close to the bottom of the map it is often impossible to be sure where the place is--particularly if you are trying to relate it to places further south. --Goldenoldie 15:00, 6 August 2014 (UTC)

Text not saving? [7 August 2014]

Odd problem: text added to the text box and then saved is not showing on page view, even after refresh. When back in edit, the text is visible... --Artefacts 22:35, 7 August 2014 (UTC)

A pointer to the page and the text in question would help, to see if we get the same symptom. Could it be your browser cache? Can you force a refresh? Otherwise, would expect some string of characters causing grief for the parser, causing the formatting of the text box to abort without generating anything. --Jrich 00:44, 8 August 2014 (UTC)

http://www.werelate.org/wiki/Person:Henrietta_Leeds_%281%29 it has something to do with the source citation -- it seems to cut off just after the source is invoked with a ref name="S1" (inside pointy brackets) and no source citation section shows.--Artefacts 04:37, 8 August 2014 (UTC)

And I just figured out it's because I failed to close the tag with a slash... thank you though--Artefacts 04:39, 8 August 2014 (UTC)

From year="xxxx" to year="xxxx" [28 aug 2014]

After 14 days there is still no response, so Help:NLHelpdesk

There is confusion regarding from year = "xxxx" to year = "xxxx".
The page Help:Place pages does not help.

I understand by, from year xxxx to year xxxx.
When a municipality AAA on 1 January 1870 goes on in town BBB.
This municipality AAA is to (till) 1 January 1870 a separate municipality (so to year 1870)

Up to and including, seems to me not like to year and would be here in 1869.

But what if municipality CCC on 1 April 1870 to go into town DDD. Groet, --Lidewij 17:43, 28 August 2014 (UTC)

UK civil registration BMDs now available on FamilySearch [17 September 2014]

A note that just appeared on the blog "Anglo Celtic Connections" reads:

"Since the start of the month FamilySearch.org have been adding civil registration birth, marriage and death indexes for England and Wales to their database. Taken from the transcription of the GRO indexes made by FindMyPast, they were made independent of the transcriptions by FreeBMD. The indexes include name, record type, year, quarter, district, county, volume, and page number, information that can be used to order certificates from www.gro.gov.uk/GRO/content/certificates/default.asp"

Currently, the basic price for a certificate is £9.25 and they can be ordered online with a credit card. Civil registration started in England and Wales in 1837.

--Goldenoldie 14:29, 17 September 2014 (UTC)

Practice of truncating coordinates [26 September 2014]

I've put a lot of effort into specifically locating cemeteries using full Google Maps / Open Street Maps latitude and longitude coordinates and another user is going in and truncating the locations to three decimals which is effectively moving the pin outside of the actual cemetery location. The user has informed me this truncation to three decimals is considered standard or best practice for this wiki (why? what does less accuracy at no cost get us and how is this "best" practice?). Can someone direct me to where it says this and why? Also, what is the expectation regarding users from other genealogy sites editing articles to place prominent links to those sites within werelate articles, including at the expense of more developed content. On wikipedia this would be considered spamming. Thanks for advice. --Artefacts 20:44, 25 September 2014 (UTC)

Can you be more specific and/or provide an example of what you mean by "users from other genealogy sites editing articles to place prominent links to those sites within werelate articles?" --Cos1776 21:02, 25 September 2014 (UTC)

I wasn't aware of a 3 decimal practice for GPS location (though this is an area I have not had to dispute before). As for the rest of tha, if you have more detailed information to share, please PM me and I will look into it. Daniel Maxwell 22:48, 25 September 2014 (UTC)

If 1 second is nearly 0.0003 degrees and can be up to about 0.02 miles in distance, I would argue that 4 decimal places is more appropriate. However, if a more accurate coordinate has been determined, I don't see a reason to limit it. —Moverton 23:21, 25 September 2014 (UTC)

This appears to be related to a dispute with Rick Moffat: http://www.werelate.org/wiki/User_talk:RGMoffat#Why_are_you_truncating_coordinates.3F_.5B26_September_2014.5D--Tfmorris 05:27, 26 September 2014 (UTC)

Other sites using WeRelate material [2 October 2014]

I know that posting research and or articles to WeRelate releases any copyright I might have, but have to admit feeling a bit startled when I saw my entire article copied from WeRelate onto another genealogy site. The poster did give WeRelate credit as they used WeRelate as their source! I'm all for sharing or I wouldn't be here, but still was surprised to see my research article posted elsewhere. Is this practice to be expected? I guess I should just take it as a compliment and be pleased that what I consider correct info is being passed around. --janiejac 06:12, 26 September 2014 (UTC)

I haven't seen that often. There are alot of bad genealogy sites out there, particularly personal ones, that will copy + paste alot of other work without attribution, but this isn't a phenomenon unique to WR (I have not see many WR lifts 'out there' on the internet, myself). Daniel Maxwell 06:48, 26 September 2014 (UTC)

My sympathies Janiejac. I know the feeling. At least it sounds like the person did attempt to do one right thing in sourcing the info and pointing back to WR. It is when they don't do that that it particularly bugs me. I've had this happen mostly with bios I've written or images I've posted. I'm not sure there is any recourse with text, but after seeing too many images get scraped with no mention of original source, I've adopted the practice of embedding identification and source info directly into the image itself. I know they could still crop it out if they are determined, but usually folks won't take that extra step. Now I am still seeing these images reposted (mostly in Ancestry), but at least they clearly state the source. --Cos1776 11:43, 26 September 2014 (UTC)

When you post something on the site, you release it under this license, meaning that others are free to do whatever they like with it, as long as they give attribution, and if they modify it, they release their modified version under the same license. I personally think that this is really cool. It means that we get to legally ensure that our contributions always remain free - that WeRelate (nor any other organization) can simply take them and use them for their own gain. However, the downside is that we also lose the benefits of copyright, such as control of where/when/how your stuff is used. IMO, we should embrace this, change our mindset, and, as you say, be flattered that what you are posting is useful to additional people, even outside of WeRelate. -- Jdfoote1 14:17, 2 October 2014 (UTC)

Family History Catalog Library Template [2 October 2014]

Has anyone else noticed that clicking the {{fhlc----}} no longer leads to a specific place reference in the catalog? Now we get a form in which we are asked to enter the name of the place we are looking for instead. It does, in the end, lead to the same information.

Should we consider our template no longer relevant?

--Goldenoldie 13:18, 2 October 2014 (UTC)

Noticed this a couple of weeks ago but I didn't know it was a hiccup on their end. I'd probably go for updating our references on the site, but that would probably be a major undertaking to match them all again. Daniel Maxwell 13:25, 2 October 2014 (UTC)

Is there still a page on the FHLC site that you would want to find? I played around for a bit with the search results page, and trying to modify the template so that it would return that, but it looks pretty tempermental, and like we would possibly need to update the references again. Perhaps we could talk to the FS folks to see if, for example, just entering the place id would bring up the query results? -- Jdfoote1 14:46, 2 October 2014 (UTC)

I'd wait to hear Dallan's take on this first, if it is something that can be updated on our end first. Daniel Maxwell 16:21, 2 October 2014 (UTC)

No, I'm not looking for anything specific. I just thought this was something to bring to everyone's notice. Provided you spell a place the way FHLC spells a place (smiley needed here), the listing will come up. Since you can get most information on a person-by-person basis on FS these days, it doesn't matter much.----Goldenoldie 15:19, 2 October 2014 (UTC)

I found the FS links convenient, especially when they had PDF copies available of some obscure works. I think it would be worth it do update, if it isn't too much trouble. This should be brought to Dallan's attention. Daniel Maxwell 16:21, 2 October 2014 (UTC)

It appears the "Family History Library" Repositories links on Sources pages lead directly to the FHLC entry (at least the few that I tested). It seems the problem is with the Template:Source-fhlc mostly on Place pages, is that right? For example, on Place:North Haven, New Haven, Connecticut, United States, clicking source: Family History Library Catalog messes up. If so, that is something we should be able to fix without Dallan's assistance. --Jennifer (JBS66) 17:13, 2 October 2014 (UTC)

I see now that FS changed more than just a URL reference. If that were the case, I could update the URL in the template as I've had to do a few times in the past. I will send Dallan an email to ask what our options might be to fix this. --Jennifer (JBS66) 17:33, 2 October 2014 (UTC)

Maine plantations [4 October 2014]

In Maine (and historical Massachusetts) there are places referred to as plantations. There isn't a place type specifically for that. I created Place:West Pond Plantation, Kennebec, Maine, United States using the "Unincorporated area" type, but I am wondering if we should have a new type added or if some other type would be more appropriate. -Moverton 15:45, 3 October 2014 (UTC)

In most of the U.S., "plantation" is mostly just local jargon for a cash-crop farm, as opposed to a "feeding the family from the land" farm. In Massachusetts, as at Plymouth Plantation, I believe it refers to a farming settlement sponsored by investors hoping to turn a profit. But they aren't really different types of places. --Mike^Talk 13:54, 4 October 2014 (UTC)

Auto Complete [7 October 2014]

Auto complete for places is not working.--SkippyG 23:22, 7 October 2014 (UTC)

It is for me. Do you run AdBlock? In the past I had issues with it running on WR breaking the auto complete. Daniel Maxwell 23:34, 7 October 2014 (UTC)

No AdBlock, but this is a new problem for me. Can't search sources by place either unless I know the entire (city, county, state, etc). I'll try restarting my PC.--SkippyG 23:39, 7 October 2014 (UTC)

Short answer on source style guide? [8 October 2014]

Wow, there is so much here, I'm finding it hard to find an answer to my question, which is this:

Should I be following a particular style guide when sourcing information? For example, APA format (http://www.apastyle.org/) vs Chicago format (http://www.chicagomanualofstyle.org/tools_citationguide.html) vs whatever else we used to use in school, or that werelate has decided upon?

Thanks!

Jonmcrawford

P.S. - fabulous work all, special kudos to Dallan!--Jonmcrawford 15:22, 8 October 2014 (UTC)

You don't need to worry about bibliography style, it's done by the system. Input the title in a source box to link to the appropriate source page, and WeRelate inserts a formatted citation. To get started with finding the right source title, set the source type to "Source" (ie., not Citation, not MySource). Click on the Find/Add link and enter search criteria, then select the source from the results list. Enter author names "last, first". After you get familiar with source titles, you can enter the first few characters/words in the source title and select it from a drop down list that is presented. If your source is not there (most are) you need to study Help:Source page titles and compare what it says to various existing sources you are familiar with. --Jrich 15:32, 8 October 2014 (UTC)

Related: Is it possible to invoke a formatted link to a Source page using reference tags in page types that do not have the Source form boxes?--Artefacts 17:50, 8 October 2014 (UTC)

Genealogy contest: maybe do this NY Cemetery needs emerg research? [13 November 2014]

Saw this and thought we could do a Cemetery page as the genealogy contest to find out as much as possible before gets destroyed: http://www.nytimes.com/2014/11/04/nyregion/long-in-repose-last-remnants-of-founding-family-van-alst-will-leave-long-island-city.html --Artefacts 16:58, 4 November 2014 (UTC)

In case the above link does not work for you, try this one.

Here, here! It would be fun to do a community/crowd sourcing kind of project together with the WR "experts" :) here. Just think of the publicity we could generate for WR by doing solid work and getting a follow up article in NYT. Anyone else interested? --Cos1776 17:15, 4 November 2014 (UTC)

Place:Van_Alst_Cemetery,_Queens,_New_York,_United_States

Some Alsts are already in the system, I will link them into the page above. In Ontario the go to source for cemetery info is the Ontario Genealogical Society, which sent transcribers out into the field in the 20th century who recorded a lot of information now lost, is there something similar for New York? --Artefacts 17:26, 4 November 2014 (UTC)

Put up all the sources I could find on the cemetery page itself. Several free online. --Artefacts 17:58, 4 November 2014 (UTC)

This family really deserves better than they have gotten. If you read the report prepared by the historical consultants 2001-2003 http://s-media.nyc.gov/agencies/lpc/arch_reports/610.pdf it contains the incredibly poor methodological statement "an internet check of telephone directories for the New York metropolitan area identified a number of Van Alsts, but none in Queens. Without directly contacting these individuals it is impossible to determine if any of these individuals is related to Harry Van Alst who arranged for the 1925 reinterments."--Artefacts 00:57, 5 November 2014 (UTC) There are probably a 100,000 descendants of Joris (ie. who seems likely to be in this cemetery) -- if one of them sees this, please consider starting a Friends of Van Alst Burying Ground Facebook Group (or some such).

I wonder if the Van Altine family is connected to the Van Alsts? See Person:Abraham Van Alstine (1). Abraham's wife's grandfather was born in Oyster Bay, Queens and migrated to Canada. Some of Abraham and Elizabeth's children moved back to New York. Just wondering. I have no other info about them. --janiejac 17:17, 8 November 2014 (UTC)

I wondered that too as "Van Alstyne's party", lead by Peter Van Alstyne to Adolphustown is one of the iconic founding stories for Ontario. Have yet to come across anything indicating a connections though. --Artefacts 20:18, 13 November 2014 (UTC)