WeRelate talk:Watercooler

This page is for discussing anything you want to discuss unless it relates only to a single page. Let people know what you like and don't like about WeRelate. If you don't want to leave comments on this page, you can email them to dallan@WeRelate.org.

Have a question about how to use WeRelate? Post it to WeRelate talk:Support.

Old topics have been archived: 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013.


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


 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


 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]


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:

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:


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 ( TalkContribs ) … 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 ( TalkContribs ) … 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. --MikeTalk 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?



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)
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)

GenWeb Sources [1 January 2015]

Would it be best practice to delete GenWeb "Sources" and transfer their links to their respective county Place pages as Resources?--khaentlahn 18:42, 1 December 2014 (UTC)

Unless I am missing something, I am not even sure it would be a good practice??? The times I have used Genweb, it usually includes a link to specific set of data found on a specific page of their website which I doubt is anyway linked to by the Place page. --Jrich 19:28, 1 December 2014 (UTC)
I should have been more specific. I was referring to the main home page of the respective GenWeb sites, not the various resources that those sites contain. Therefore, the idea is that GenWeb home pages are not actual Sources (which many of them are created as such currently on WeRelate), but the various GenWeb home pages should be linked to 'somewhere' as they can be a viable resource from which to cull specific information, hence the county Place page suggestion. GenWeb pages are more closely related to Repositories, but transferring GenWeb Sources to Repositories has been determined not to be a viable practice and continuing the practice of using them as Sources has been frowned upon. So if giving them a link on respective county Place pages is not viable (so as to start removing the bad Sources), then what should be done with the links to the home pages?--khaentlahn 19:52, 1 December 2014 (UTC)
I still don't understand. Who decided they are bad sources? If they contain transcripts of marriages in some county, which many do, how are you supposed to cite that information, i.e., what to point the source citation at. Perhaps an example would be useful. On my side, an example is Family:Henry Kendall and Julia Grogan (1). --Jrich 23:28, 1 December 2014 (UTC)

I agree with JRich.--Beth 01:49, 2 December 2014 (UTC)

According to the conversations here (beginning in 2013) and here, using individual County GenWeb pages as Sources is incorrect, which appears to be what was used on the example you gave with Family:Henry Kendall and Julia Grogan (1). Whether I agree with this or not, I do see the logic behind why all of these County GenWeb pages are not Sources as they are closer in definition to Repositories of gathered information. The overarching question of what to do with GenWeb pages does not appear to have been determined (they need to be standardized, converted, or removed), but, in all likelihood, they will disappear over time from what I read. If this is incorrect, a determination of some type would be helpful as there is still confusion over the subject. In any case, I retract my initial question (it was going to be too much work) in place of a determination on County GenWeb pages. Should they be standardized, converted to Repositories, or removed? Am I missing other options? As they stand currently, they are a mess.--khaentlahn 03:39, 2 December 2014 (UTC)

I am still at a total loss trying to understand the issue here. If you make Genweb a repository, it is allowed to contain multiple sources, say, one for each county. A insignificant organizational issue that in no way requires deleting the individual county genweb source pages. To make each county genweb a Repository implies that it contains several sources, so each subsection now needs a source page. For example, in the above example, now the Marriages section of LaPorte County genweb would be a source page inside the Laporte county Genweb Repository, instead of having one source page for the entire county website.
I read the cited discussion, filtering out all but Dallan's comments as just someone's opinion, and I do not see that it says using county Genwebs as source is incorrect. Instead, just the opposite. So saying it says one thing or another is rather selective reading.
As far as I can see, the choice here is to have a Source page for each County genweb (since each are administered differently) or have absolutely no page at all, and do them all as citation-only including explicit links to the page used when you are using the Genweb website as a source of information. --Jrich 04:06, 2 December 2014 (UTC)
After a little more information which you provided to me in referencing County Sites?, which I will admit I hadn't read previously, this line of conversation is no longer valid as it appears that my original question was erroneous based on invalid information.--khaentlahn 16:56, 2 December 2014 (UTC)

Why is Find A Grave Template not working? [1 January 2015]

On Person Page Person:Nancy Baile (1), the saved result is (i think) a lot of code. I've tried to change it, but . . What can we do?

Thanks, --GayelKnott 19:50, 1 January 2015 (UTC)

I took a quick look and found that there was a stray '<refname' at the end of the text for S2 on that page. Removed the offending stray and the template works fine.--jaques1724 20:07, 1 January 2015 (UTC)
Thanks, Jaques -- so simple when you know what to look for, but I sure didn't.--GayelKnott 20:16, 1 January 2015 (UTC)

Does WeRelate have a naming convention for slaves? [5 February 2015]

Wondering how WeRelate handles the surnames of people who became or were born into slavery. I'm thinking specifically about the period of slavery in the U.S. pre Civil War. Thanks.--Jillaine 22:32, 17 January 2015 (UTC)

Coincidentally, I have an interest in this question from the other direction: A bunch of my ancestors, sadly, owned slaves, in some cases I have their names. I'd like to document them in case it could be useful to someone else's research. --Trentf 01:40, 18 January 2015 (UTC)

This is a good question. Many of my ancestors owned slaves, but I haven't personally traced any of them. I would think that the 'Unknown' naming convention would apply to slaves (ie Sara Unknown); most genealogists who do black genealogy simply call them by their given names "a slave named Sara", etc. Daniel Maxwell 11:26, 18 January 2015 (UTC)

I did a bit more searching and happened upon this category Category:Slavery, it shows two different conventions being used: The surname of "Unknown" (as Daniel suggested), and a few have the surname "(Enslaved)". I would think the former would be sufficient but I would suggest coupling it with the category, though I might suggest that the Slavery category get two sub-categories: Slaves and Slave Owners. Maybe the general topic of Slavery is worthy of a portal or project of its own? --Trentf 17:51, 30 January 2015 (UTC)

I agree that there should be separate sub-categories for 'Slaves' and 'Slave owners'. I went ahead and created them. I also created these templates: Template:Slave (and equivalent Template:Enslaved person), Template:Slave family, and Template:Slave owner. The templates can be used on a Person or Family page instead of a direct Category: entry, the intended advantage being that the category placement or category name can then easily be changed. For example, currently Template:Slave family causes a page to have Category:Slaves, but it could later be changed to use a 'Slave families' category or some such.
I am beginning to go through the pages presently in Category:Slavery to update them to use the new categories (via templates). Most pages seem to be part of this plantation research project.
A number of pages in Category:Slavery don't fit either of the new sub-categories. So far I've found pages for never-enslaved descendants of slaves and for overseers of slave plantations. Some people in the category are of unclear status: a son of an owner and his slave who was a minor at the end of U.S. slavery and was later sent to college by the slave owner's sisters. I'm not sure if descendants and overseers should be removed from Category:Slavery or put into new sub-categories (of what nature?), or just what. I'm leaving them unchanged at the moment.
--robert.shaw 02:40, 6 February 2015 (UTC)

Top 100 websites [4 February 2015]

WeRelate has featured again in Genealogy in Time magazine's 100 top genealogy website based on webtraffic. We've gone from 86th to 79th. Out of interest, do we publish anything ourselves about traffic? AndrewRT 16:40, 25 January 2015 (UTC)

I would love to see periodic reports of various metrics about the site. It seems like we all spend our days making steady improvements to information on the site, and it would be nice to see some numbers to show where our collective effort is getting us. I have noticed that you, AndrewRT, have made some efforts towards generating metrics in the past. Are you still pursuing that? Could you use a hand? --Trentf 14:57, 4 February 2015 (UTC)

What do other people do when they find their WeRelate pages copied elsewhere without attribution? [4 February 2015]

Just found another page on Ancestry that had a scanned page from WeRelate that I recognized as one I had posted - but with no attribution, and no indication that it came from WeRelate, other than the formatting of the sources. I don't care if my name is not mentioned, but if WeRelate is being mined for data, I really do think the site itself should be credited. And that is also my understanding of what the Open Commons agreement is about -- go ahead and copy, but provide attribution. Am I wrong? (I did leave a comment, thanking the person for circulating my information, and pointing out that it come from WeRelate, with an URL to the page.) What do other people do? Thanks, Gayel --GayelKnott 19:48, 1 February 2015 (UTC)

Yup - that's exactly what I do on ancestry, i.e. provide a comment stating where the information is coming from with a link to the WR page.--Cos1776 20:00, 1 February 2015 (UTC)
Ditto - I literally just had this dilemma 12 hours ago.--Amelia 20:38, 1 February 2015 (UTC)
Since Ancestry is a pay to use service, uploading material may be a violation of the Open Commons agreement. I would be interested in what a copyright lawyer has to say about that. People can't go around profiting from Wikipedia for instance. --Artefacts 20:59, 1 February 2015 (UTC)
This is one of several reasons I dislike Ancestry.com. I think the only thing that can be done is make a copyright violation claim, but there isn't going to be a one size fits all solution. It is going to be a game of whack-a-mole. There are even worse instances of this same problem - several photos I personally scanned from my grandmother's album and put on Findagrave found their way to Ancestry.com like they were just free for the taking. Now I watermark all of my scanned, non-public domain images 'Daniel Maxwell Collection'. I also do not keep a tree on Ancestry.com since I dislike how they handle non-Ancestry approved sources. Daniel Maxwell 21:33, 1 February 2015 (UTC)
Thanks, all. Very reassuring, and response policy now in place.. And, Artefacts, can't you just see a Judy Russel blog on this? I don't think she would pull her punches. But Daniel 's right -- it would be like playing whack-a-mole to deal with officially. Gayel--GayelKnott 01:45, 2 February 2015 (UTC)
If there's a silver lining to plagiarizing WeRelate, at least they're hopefully spreading good data, for a change. Ancestry enhances people's ability to copy data, good or bad, that bad data often propagates faster than the correct data, until suggesting the right answer is swimming against the current. I have been told that Ancestry owns almost no actual data, mostly just indexes made in India, and as more and more stuff is put online, Ancestry will have less and less to offer. Devil Take the Hindmost: venture capital fund to buy Ancestry, that is. --Jrich 04:23, 2 February 2015 (UTC)
The Legal Genealogist would do a great blog on this. Wikipedia has a whole apparatus to report copyright violations, I don't understand why a commercial company like Ancestry does not have to have one. I think the willingness of government records agencies to outsource record provision to Ancestry is incredibly stupid as they are giving up a way to show their relevance to the taxpayer and justify their existence and Jrich is right about Ancestry's usefulness and relevance decaying as the Internet keeps expanding its offerings. --Artefacts 18:13, 3 February 2015 (UTC)
I have to say I disagree about Ancestry's relevance decaying. Ancestry has a long, consistent history of buying out or neutralizing all the potential competitors it can, and doing well at that. Rootsweb was put on ice years ago; census sites, general genealogy sites, even some government data provision pulled in; Billiongraves to counter FindAGrave, deals with FamilySearch for holding original document images and limiting usage outside the Ancestry paywall; the list goes on and on. I'm sure they are continuously figuring on how to acquire or neutralize other emerging or established resources like WikiTree and FindAGrave. Although there are an increasing multitude of smallish, scattered resources on the net, only a few major resources of interest to them, like Archive.org and Google Books, remain out of their reach (or so it seems to me). --robert.shaw 19:42, 3 February 2015 (UTC)
Most of that is a different issue. I agree that Ancestry has to fight tooth and nail to retain commercial viability, because with a few well placed free sites, they would go out of business tomorrow. To be honest, I don't like the idea of most commercial genealogy sites unless they offer something copyrighted and not under public domain (See NEHGS's site for an example of this, which has a large selection of recent genealogical journals, something Ancestry doesnt offer) but Ancestry mainly has people thinking that they have to pay for access to the census and other non copyrighted government records and I don't like this. Oh sure, they index the pre 1850 censuses but there is no reason Familysearch or someone else could have done this and put it all up for free. Ancestry has other problems too, such as creating 'sources' from people's GEDCOMs. Daniel Maxwell 22:54, 3 February 2015 (UTC)
I don't think you would have a case against Ancestry unless they refused to remove copyrighted material that was pointed out to them. Since individuals are creating and sharing their personal trees with each other, I think fair use rules would apply similar to here on WeRelate. As far as my work is concerned, I don't care who copies it or whether they attribute, although unattributed anonymous data loses its value. I just assume that anything I put on the Internet could be copied and am not shocked if I see it. And when I see them copy something I put together on this site, I take it as a compliment. It isn't something I would ever bother going to court for. (This is my opinion, and I am not a lawyer.) -Moverton 17:32, 3 February 2015 (UTC)
While I agree with you in general, the fact is that all material on this site is copyrighted and this is clearly indicated at the bottom of every page (see WeRelate:Terms of Use). The terms of the copyright ([CC-BY-SA]) clearly indicate that any materials can be copied provided credit is given and that they place no restrictions on further copying. As long as they abide by those terms, then there's no problem (though, I am not a lawyer). But if they take the information behind their paywall and augment or improve it but prevent further copying, then I have a huge problem with that. That would entirely negate the goal of putting information here under CC-BY-SA, which is, as I see it, to improve the quality of genealogical information on the internet. --Trentf 14:57, 4 February 2015 (UTC)
If you post genealogical information on any site with the expectation that it won't be "copied" or "shared", then you likely also believe in Santa Claus or the Tooth Fairy. First of all, some of what people "think" is copyrighted simply isn't because they don't include any "original thought" or "originality"; this includes many transcriptions, etc., also "facts" can't be copyrighted. If the information we add on WeRelate is high quality and source-based, we should be accepting of others copying that information without first asking for permission or using proper citation. Much of what I've added here I've seen on other people's websites, including some of the maps I've done and other narrative that COULD be considered "copyrightable". In the beginning, I got a little irritated, but after I thought about it more, I figured it was good to have "better information" on someone else's site, instead of other questionable information... Remember "a rising tide lifts all boats". John F. Kennedy --Delijim, 4 February 2015
More like a "rising tide profits Ancestry" and makes suckers out of the novice users there who don't realize how much stuff behind the paywall they are financing is available here and elsewhere for free. --Artefacts 21:33, 4 February 2015 (UTC)
I don't believe WeRelate has ever espoused itself to be a "be-all, end-all" in genealogical research like Ancestry has. For better or worse, Ancestry will continue to be the most comprehensive place to research your ancestors. It has more way more sources than probably all of the other sites combined, and in spite of its many flaws (especially the Ancestry Member Trees, many with little or no sources or documentation), it is still the best thing around, and yes, with a fee attached. Until there is a better site to use, I'll continue to be happy to shell out the $25 or bucks a month or so to have access to their vast source of records. Like it or not, it sure beats trudging around the country to visit local courthouses, graveyards, LDS research centers or genealogical libraries... As they say, nothing good in life is FREE. Best regards --Delijim, 4 February 2015
It most certainly is not the best site for research and it is not even remotely comprehensive. The coverage on Ancestry is good for censuses and some vital records (which governments should be providing themselves) and some specialized collections and that is about it. It sucks for pre-19th century sources. FamilySearch and Google are better for church records, without doubt, which is the meat and potatoes of anyone who is not a novice.--Artefacts 22:55, 4 February 2015 (UTC)

On Wikipedia and inclusion of content therefrom [19 February 2015]

Hello -- I have been active from time to time in adding people, particularly scientists, who have Wikipedia biographies to WeRelate. I created a template over at Wikipedia to be added to a biography talk page indicating that the person has been represented in WeRelate (see https://en.wikipedia.org/wiki/Template:Werelate). I wanted to express my negative feelings about bringing content from Wikipedia over into WeRelate. There was a time a few years ago when I liberally used the template which would bring content over from Wikipedia to this wiki. However, in recent activities, I've not been using this template, rather focusing on the basic genealogical information. Frankly, I believe it is this basic genealogical information which is the core of what WeRelate is about, not the linkage, for instance, the linkage between Person:Amos Alcott (1) and Person:Ralph Emerson (4) via the passage "Alcott became friends with Ralph Waldo Emerson ....". This is an example I stumbled across when adding Person:Charles Haskins (6), but it pricked me into writing this. Such connections are not along the critical path for WeRelate, and we should be relying on Wikipedia to provide the rich text of a biography, while we here work to systematize that information. There have been inklings/dreams/rumors that WeRelate and Wikipedia might merge via the Wikimedia Foundation. If that happens, I would see WeRelate as a specialized adjunct to WikiData rather than Wikpedia per se, drawing on the organized information in Biography Infoboxes and explicitly not replicating Wikipedia biographical narratives. It is this state, looking at the genealogical systematization of content as oppose to florid narrative, which I see as the true future of WeRelate. --ceyockey 01:03, 10 February 2015 (UTC)

Just created Person:H Wells (1) (for H. G. Wells), which kind of exemplifies the minimalist approach to representing Wikipedia in WeRelate. --ceyockey 01:37, 10 February 2015 (UTC)

I think the better approach is to use the sources that Wikipedia uses. Citing the page itself would be like citing another WeRelate page as a source on WeRelate. But in practice Wikipedia is cited as a source in itself, despite Wikipedia's infamous inaccuracies, hence one of the several reasons I am not a fan of Wikipedia. Daniel Maxwell 08:01, 10 February 2015 (UTC)
In general, yes, use of the sources the WP article cites is to be preferred. They can be directly cited if one actually consults the source and finds the information (and sometimes more, like birthplace Brooklyn for Person:Charles Haskins (6)). However, if one is only relying on WP's citation, then I think it best that WeRelate's citation reflect both the (supposed) original source and the fact that it came from Wikipedia. For instance, in Wikipedia, H. G. Wells' death date (and birth date?) cite Oxford Dictionary of National Biography, so both that and the WP page version doing the citing, https://en.wikipedia.org/w/index.php?title=H._G._Wells&oldid=646374101#cite_note-Parrinder-3 (available via "Permanent link" in tool menu) should be used. I prefer this to be in the form "Oxford Dictionary of National Biography, as cited by Wikipedia link", but "Wikipedia link citing Oxford Dictionary of National Biography" would also be reasonable. --robert.shaw 18:22, 10 February 2015 (UTC)

Re WR's H. G Wells page. With no parents and no spouse? I thought this was genealogy.

I just came over to Watercooler to take a break after working on the village of Bredon in Worcestershire, England. The Wikipedia page mentions a William Hancock with a date of 1718. WR has another William Hancock who died in Bredon in 1676, no descendants listed. Anyone want to tie up some loose ends? --Goldenoldie 11:11, 10 February 2015 (UTC)

"With no parents and no spouse?" - It's still useful, because it gives birth and death dates and places. It's just one person, but still a contribution. --robert.shaw 18:38, 10 February 2015 (UTC)
Re: Your comment on Person:H Wells (1). It also the practice at WR to use full birth names, not initials in person pages. So H Wells needs to be Herbert Wells. Daniel Maxwell 12:11, 10 February 2015 (UTC)
I agree, sort of. I've renamed the H Wells page to be Person:Herbert Wells (9), but have left the primary Name as "H. G. Wells". I think this is the right thing to do because when a person has many names, if one stands out as the well known name that should generally be used. Certainly "H. G. Wells" is much more recognizable than "Herbert George Wells". This helps, for instance, when doing a search for "Herbert Wells" -- one can immediately go to it, if that's who you're after, or skip it if you're after someone who is not the famous H. G. Wells. --robert.shaw 18:33, 10 February 2015 (UTC)

Following the discussion, I think you will find this person record more along the lines of what most people would find useful and acceptable (?): Person:Louis Mordell (2) . --ceyockey 18:16, 14 February 2015 (UTC)

The basic problem is that some of us actually like the "florid narrative" that you think should be restricted to Wikipedia. I don't think you can say that narrative belongs to one place and "facts" belong somewhere else. And it's worth pointing out that there are multiple ways to reference/link to Wikipedia, including the one you have just used. --GayelKnott 18:54, 14 February 2015 (UTC)
You think it is a problem? I am not stopping anyone from adding narrative, nor have I said I would remove it if it was there. I'm saying I prefer not to have it and, therefore, will not be adding it myself. --ceyockey 19:28, 14 February 2015 (UTC)
I think Louis is a great example of a page that benefits from the WP extract, given that I have no idea who he is unless I go to WP. The flipside of that is that writing a good, well-sourced summary of someone truly high profile like, say, George Washington is hard to do correctly and takes a lot of time, whereas we can leverage a crowd-sourced, cross-linked version from WP unless and until someone feels they can improve it. (And, on that vein, I love it that we get the cross-linked content to other WP pages. I think it's fun to be able to instantly see other people and where they came from to end up in the same place.)
Now that I've been moved to comment, however, I'm not sure what the original issue was. People add narrative if they want, and don't if they don't want to, right? As long as the people that don't want to add it, don't object to other people coming along and doing so, then we don't have a problem.--Amelia 23:47, 14 February 2015 (UTC)

Married surnames for women [21 February 2015]

Hi Markus3. Recently you have moved the married surname from the married surname field to the married given name field, leaving the married surname field blank, on several of the pages I watch. Can you explain why you are doing this and how you decide which pages to do it to? It doesn't make sense to me, and it removes a data point from the page which affects searches. Regards, --Cos1776 13:33, 14 February 2015 (UTC)

Hello, Cos1776 ! Please, at first excuse my very bad english. You seem to be not the only contributor who has a different opinion and experience with this use. See the "revert" of Jaques1724 ---> http://www.werelate.org/w/index.php?title=Person%3AAbiah_Hitchcock_%281%29&diff=21602835&oldid=21602718
I really don't understand why what I changed ... "affects searches". Can you explain and give examples ? I believe instead that my changes are absolutely necessary because otherwise the "count tool" always give an exaggerated number of persons (it's the same problem with Geni and WikiTree) ---> see this page - Amicalement - Marc ROUSSEL - --Markus3 14:03, 14 February 2015 (UTC)

I agree with Jaques1724. When you remove data from a page, you remove the ability to search on it. You may have noticed that the "Surname in place" search no longer appears on the left side of the page for the married surname of these women. Regarding your analysis program - if your "count tool" is not working properly, then you should fix the "count tool" itself, not change the data until you get the results to come out the way you want them to. I can not analyze your code from the link you provided. Does your program know to exclude data from the Married Surname Field if you do not want to count married women? --Cos1776 22:15, 14 February 2015 (UTC)

Hello Cos1776 ! Please, be more attentive ! It's not my... "analysis program" ! My "count tool" works perfectly ... it's nothing particulous but just a basic MediaWiki table with rows and columns. Amicalement - Marc ROUSSEL - --Markus3 08:28, 19 February 2015 (UTC)

Markus3: I too came here to ask why you were moving the last name of women's married names from the surname field into the given name field. A page I was watching had this change, and I saw that you had done this kind of change for a bunch of women on 16 Feb. I don't see any point in doing this, and it will have serious consequences for the search mechanism. I think most English-speakers, at least, expect the married last name to be in the surname field, and will search for it in that position. That convention is the one that is used on major genealogy sites like FamilySearch. I don't think you should continue doing such changes unless and until some consensus to do so is reached (say, on the Watercooler page). Please let Cos1776 and I know your thoughts about this. --robert.shaw 04:53, 19 February 2015 (UTC)

Hello, Robert ! It's for me not so easy, my english is very poor. It's difficult to explain all the details of my "position". And I saw very often since my activity on WeRelate that a lot of contributors write on several points/topics in terms I am unable to really understand (and GoogleTranslate is "diabolic"). About your opinion and argumentation, it's for me exactly as the argumentation of Cos1776. You are staying on generalities and explaining nothing. You wrote for example : "it will have serious consequences for the search mechanism". What do you mean ? Amicalement - Marc ROUSSEL - --Markus3 07:19, 19 February 2015 (UTC)
Yes, Cos1776 and robert.shaw ! it's obvious . I "have noticed that the "Surname in place" search no longer appears on the left side of the page for the married surname of these women.". But 1) this possibility has very serious consequences on the general number of persons with a particular surname. 2) the "search mechanism" is really not destroyed ... it's only not so direct. 3) I have noticed since 2 years that the very vast majority of records on WeRelate don't use this heavy problematic search method. Amicalement - Marc ROUSSEL. --Markus3 08:19, 19 February 2015 (UTC)

Regardless of why it is being done, if the information being entered in the "given surname" field is the married name, not the name they were born with, then it is incorrect.

I think that is the point being made.--Jonmcrawford 12:42, 19 February 2015 (UTC)

No, what is being discussed is not the primary name for an individual (which all agree should use the maiden surname), but rather an additional name for a woman, which can be labeled as "alternate name" or "married name". The question is whether to have the surname (taken from husband at marriage) in the "surname" field, or in the "given name" field. To make this clear, here are two screenshots of how it looks while editing:
--robert.shaw 21:32, 19 February 2015 (UTC)
Yes, Robert ! And the field where this "married name" is tipped is bringing consequences (advantages and disadvantages). The problem is : "Which of these two methods brings more benefits and fewer drawbacks ?"
Yes, Jonmcrawford. The option labeled "married name" also divides the input between given name and husband's surname. It's also theoretically "incorrect" to put a surname in the entry field that is dedicated to the first name. But ... Amicalement - Marc ROUSSEL - --Markus3 07:44, 20 February 2015 (UTC)
This dialogue reminds me of how i am struggling with family names in the part of Holland where i grew up. When a man married into the farm of his wife, he would - at any given time, perhaps when their third child is born - take on the name of his wife, or - to be more precise - the name of the farm where she came from and where they live. The first and second child may be named after their father, but then the father changes surnames, and the children get their lastname from the place where they were born. My solution to this is to have the surname field follow the father's name, and in the alt_name i enter the farm name. Example see Eimert and Janna. Note Janna Goormans is also called Janna te Roller, while some of her children have "ten Brundel" as their surname.

woepwoep 22:27, 20 February 2015 (UTC)

Markus3 - When I say that it is "your" counting tool, it means that "you" are the one using it to count something that "you" personally wish to count. Obviously, it is not working perfectly for your needs, because you have to edit pages by hand, one at a time, to eliminate the married surname field in order to get the counter to return the answer that you want. Instead of getting into a back and forth argument about this - why don't you explain exactly what you are trying to count (I think I know, but you seem to think I am missing something). Then we can help you with a solution to your problem that doesn't negatively impact everyone else. --Cos1776 13:08, 19 February 2015 (UTC)

Cos1776 ... 1) I especially do not want to ..."negatively impact everyone else" ! 2) I think, my goal/project it very clear and very simple --> to obtain (when possible without writing an other/new (light or heavy ?) part of programm) an exact number of persons who have a particular surname and precisely excluding surnames obtained by marriage. I don't want to remove any information on person pages and family pages, making poorer the records and obstructing the work of others. 3) No and no ... I am not the (only) "one using to count". There is a big competition between genealogical sites and the vast majority of them are using this "total number of persons" as advertising, propaganda and recruitment. Many give false statistics, with duplications and confusions (intended or not). I can cite several sites and genealogical associations in France. I have had several debates and (sometimes heavy) conflicts about it, including Wikipedia ... When WeRelate wants to be better than its rivals (that use comparisons on the number of records), we are needing undisputed and indisputable arguments and numbers of records. Amicalement - Marc ROUSSEL - --Markus3 09:43, 20 February 2015 (UTC)

On the fringes there may be some value to external search engines in having married names entered, though the exact value is far from clear as the names exist in very close proximity in Family page titles already. As it has largely not been done in any systematic way, it seems pointless to have it exist on, say, 0.5% of the pages. Further, I believe it is pointless until the feature is supported by software that keeps it up to date, so that when somebody changes the spelling of a husband's name from, say Curtiss to Curtis or Curtice, or vice versa, the married names of all five of his wives is correctly updated as well. Up until recently, believing it to be an annoyance brought in with people's GEDCOM uploads, because it is something they do on their own system, or their software does, I have been deleting it. I have put that on hold hoping this conversation would establish whether WeRelate values it and is going to add software to maintain it, or it is realized it is a maintenance headache, because it duplicates data on the woman's page to data whose natural place is on her husband's page, creating a non-normalized data model, which suggests it should not be done at all if not by software. The simplest arrangement is, of course, to simply know people by their birth name, and much like the system for place names, some people may not like that system, but it allows us to have a common understanding and work together.

Whatever this counting tool is, is a separate issue that needs explaining. I would hazard a guess that somebody needs to figure out a different way to count surnames as it appears to be concerned with one person's project, which does not make a good justification for changing how things are done. --Jrich 16:03, 19 February 2015 (UTC)

Re: a common understanding - I would put forth that we already do have a common agreement for at least one part of a woman's page - the wiki Page Title - which could technically be anything, but we have agreed to use a person's birth name (first and last) to provide the unique identifier for their page. It would seem to me that Markus3 should probably use the Page Title to count people born with a specific surname for his project. Depending on what exactly it is that he is trying to count, he should probably also incorporate the name variant database, which brings me to ...
Re: maintenance issues with using different names - It is true that name variants used to cause problems in genealogical databases, but remember that WR now handles name variants very well (recall this project), so I do not agree that including married surnames introduces the potential for a maintenance headache. It is not necessary to use the same spelling for every member of a family. They rarely all appeared in the records with the same spelling anyhow.
Re: should we even include married surnames on pages for women - I say YES, mostly because a woman was usually known for more years of her life by her married name(s) than by her maiden name. She therefore would appear in official records more often under her married name(s), which means that it is often beneficial to be able to search for her that way. That data point is very relevant to who she was. I would be interested in exploring the concerns surrounding this issue further, however. --Cos1776 19:28, 19 February 2015 (UTC)
You can search for Family pages with wife's given name and husband's surname filled in. You can search for Person pages using the given name and fill in the spouse's surname. Since the married name has a given name and surname separate (and half the cases I see only fill in the surname part of it anyway), it does not create a contiguous string you can search for anyway. So I see little actual searching value. --Jrich 20:22, 19 February 2015 (UTC)
I think it's important to remember that someone's married name may change in unpredictable ways, such as combining both spouses' surnames, etc. This field seems to serve a purpose in disambiguating what the actual married name of a person was. IMO, I think that if the field is given as "Married name", with a first name and surname, then people will fill it out with the married name in the surname field. Moving this to the first name is confusing. --Jdfoote1 20:44, 19 February 2015 (UTC)

Marc asked for an explicit example of how his preferred data entry causes searching problems, so: Suppose you want to find out if WeRelate has anything on a person you know as "Amanda Boyer". Perhaps you know or suspect that was a married name, but perhaps you think she may have been single at the time you know about her. One natural way to search for her is to go to the "Search" dropdown and select "People" search. On the search Person page, you naturally would fill in "Amanda" in the Given Name field and "Boyer" in the Surname field. Doing this search will not find one of the candidates (as the WeRelate database exists right now) because the candidate, Person:Mariah Frost (1), who was known as "Amanda Boyer" during her first marriage, does not have the name "Boyer" in the surname field of her alternative Married name (or any other alternative name). This is because "Boyer" was moved out of the Surname field and into the Given Name field of the Married name. The correct name was actually given on her page, but was modified so that the person can no longer be found through using this straightforward, natural form of search. --robert.shaw 22:25, 19 February 2015 (UTC)

It sounds like the solution to the use case presented by Markus3 is to provide direct access to the underlying WeRelate data rather than via the user interface. With direct access, he could query the surname field and exclude all but the primary name from the results. How might such direct access be granted? --ceyockey 13:52, 20 February 2015 (UTC)

ceyockey, perhaps a solution ? Would it be possible to bring together in a single field (without heavy modification of the source program) for the option labeled "married name" ! But actually, the vast majority of this information about the "married name" is labeled "alt name". With this modification (only one field for this only line) the search can perhaps work as hoped/wished by other contributors ? Amicalement - Marc ROUSSEL - --Markus3 14:25, 20 February 2015 (UTC)
Marc, It looks like your counting is done with simple searches. If this isn't yielding proper results, then the search functions need to be modified. Reporting tools should be made to conform to the data in the database, and the data should never be modified to accommodate the reporting tools. You may not like hearing this, but you may just be stuck with what you've got until a developer can improve the search functions for you. -Moverton 17:15, 20 February 2015 (UTC)
Agreed. I said the same thing (using Marc's terminology) on 14 Feb and was told to "be more attentive", after I had taken the time to review his project page and tried to offer solutions. It does seem like it is more about arguing than it is about finding an agreeable solution. In this case, I still vote for searching the Page Title, instead of any Surname fields, since it is the most consistent place where you will find a woman's maiden name. (I will refrain from opening the Name Fields can of worms again at this time.) --Cos1776 17:57, 20 February 2015 (UTC)
Cos1776 ..."searching the Page Title, instead of any Surname fields" ? ---> May I have a real example, with a link and/or a screenshot ? I have tried often since weeks ! The result is not as expected, because the "married name" always appears ! What works wrong ? What I did not understand ? Marc ROUSSEL - --Markus3 19:30, 20 February 2015 (UTC)
Marc, HERE is a link to such a search. It returns Person pages which have the surname "Carrier" and which have "Carrier" in the page title (note that 2 fields have entries: Surname, and Keywords, which has "Title:Carrier" in it. The search returns 53 person pages. If one removes the "Title:Carrier" specification, it returns 55 pages. The 2 additional returned pages are: Person:Martha Allen (69), returned because she has a "Married name" entry with "Carrier", and Person:William Caryer (1), returned because he has an "Alt Name" entry containing his surname with the spelling "Carrier". Note that it is important to put the name in both the "Title:" field and the "Surname" field because some names, such as "George", can be used as either a given name or a surname. --robert.shaw 22:42, 20 February 2015 (UTC)
It's fine, Robert ! Thank you ! Here is the reason why I did not understand !. I had read many times yet this help page. Is there somewhere other informations and tips about all search possibilities ?
I only chose one time "page title" in the first field on the top which offers 3 options. I did not know I had also to add "Title:...." in the last field "Keywords". It's very interessant to have this (new for me) possibility, but what is returned is not perfect. I wish I could obtain real alternatives but do not take into account the "married names". No luck ! And I know, the very vast majority of contributors are using "alt name" instead of "married name". One more time thanks for your "patience" and the quality of your explanation and clarification ! Amicalement - Marc ROUSSEL ---Markus3 15:32, 21 February 2015 (UTC)
I found out about "Title:" and other options from the Help:Search page, but I had to think about it awhile and try some test searches before I decided it was best to use Title: and Surname. --robert.shaw 18:57, 21 February 2015 (UTC)
Yes! Thank you for the example, Robert. I think this is going in the right direction and will work just fine for one specific spelling of a Surname. If Marc also wishes to include Surname variants in his final count, the Search will have to be adjusted. I've been working on it, but haven't figured out how to get variants (for Surname only) returned when searching on Page Titles. Any ideas? --Cos1776 20:55, 21 February 2015 (UTC)

Markus3, I suggest you end this silly Watercooler controversy about a married woman's given name (i.e. personal name) versus surname (i.e. family name), and just chalk it up to language or procedural misinterpretation. This seems to me to be an almost embarrassing argument you can't win and has no basis in commonly accepted genealogical recordkeeping. Please review the Person Page Tutorial for further rules for designating names here at WeRelate. Hopefully that will clarify the rules and format for data entry of names and end this fruitlessly trivial argument. I also invite you to review the definitions and historical use of "Given Names" and "Surnames" at Wikipedia. No response to me is necessary, because I don't want to share any further in this senseless discussion, and that is why I write this here on your Talk Page rather than add to the Watercooler Page. Take care. --BobC 15:43, 20 February 2015 (UTC)

BobC ... it's very funny, ... courteous and friendly ! --> "silly controversy" + "fruitlessly trivial argument" + "this senseless discussion" + "you can't win". Where do you read I search and hope to "win" ? This is the "watercooler page" where ideas are discuted ... Why do you think it's a "controverse" full of violence and intolerance in the arguments ? WeRelate is a collective "tool" and site ! I do not try to always have the last word ! Genealogy is not "war"  ! Marc ROUSSEL - --Markus3 16:26, 20 February 2015 (UTC)

Open external links in new window (tab)? [26 March 2015]

One of the things I find quite useful about Wikipedia is that when I click on an external link it does not open in the same tab/window as the article I am viewing. Is this something which could reasonably be implemented here, either as a default or as a personalization (selectable behavior parameter)? Thanks for considering this. --ceyockey 01:03, 27 March 2015 (UTC)

Well, I think most browsers that support tabs allow you to right-click on a link and choose to open a new tab instead of in place. So you already more or less have control of what you want to happen. --Jrich 02:30, 27 March 2015 (UTC)

Unwanted Ads [30 March 2015]

Over the last couple of hours I am getting bombarded with a wide variety of advertising in various locations on werelate pages. Is anyone else experiencing this or is it my computer? I know I won't be working on werelate much longer if I can't figure out how to stop these. --Susan Irish 02:39, 28 March 2015 (UTC)

I agree that in the last couple of days, the ads have gotten really intrusive. Now we have them below the name box on person pages. I don't mind them on the left bar, but having 3 areas of ads is too much. Daniel Maxwell 02:43, 28 March 2015 (UTC)
Agreed -- these are gross! Not only to work with, but they sure don't present the kind of image that is likely to attract new users. You can get rid of them, one at a time, by clicking the very small grey x in the top right corner of the ad, but you have to do it for every page. --GayelKnott 04:14, 28 March 2015 (UTC)
Ditto. They make the pages look awful and junky. The bigger ads on the right and left are pretty bad, but the one at the top is a dealbreaker, as it makes the page impossible to read and is the type that would only appear on a site whose primary purpose is advertising. Do ad blockers kill them? If not, I think I'm out until they're fixed.--Amelia 05:46, 28 March 2015 (UTC)
Yes, ad blockers kill them. I've been blissfully unharassed by ads. --robert.shaw 06:36, 28 March 2015 (UTC)
For the sake of getting revenue for this site, I urge you not to use Adblocker on WR. We could use the income, though I can understand doing it under these circumstances - I myself have it on until this is sorted. Dallan has assured me that this is a WIP measure, and we will be experimenting with different placements/ad types over the next couple of weeks. I find the placement of the ad on the left side very non-intrusive, and actually an improvement compared to the old placement on the right side, where it caused the person columns to shift over.Daniel Maxwell 07:49, 28 March 2015 (UTC)
I'm happy to donate, or use affiliate links, but I won't use the site with the giant ads, and may stop even with an ad blocker. They look so unprofessional (and I say that with the middle text ad in place) that I think they undermine the entire purpose of the site in promoting serious genealogy and discussion, in which case there's really no point in my spending my efforts here. I spend a lot of time online looking at the spammy, scraped, semi-illegal marketing side of the internet for work, and that's where I think I am with these. I get the need for money, but please look at other options.--Amelia 14:43, 28 March 2015 (UTC)
Don't like the ads on the pages at all, but the nature of the ads (drugged out mug shots, cheezy medical ads, questionable businesses, etc.) will push me out as well. They drown out the serious and respectable work on the pages and give WR the appearance of just another junky name-scraping site. This is a horrible idea, and I hope that we can come up with a different answer. Wondering if this is happening as a result of the relatively minor, yet very vocal, opposition to joining forces with, dare I say it, the blissfully ad-free world of the Wikimedia Foundation? - here it comes :) --Cos1776 17:01, 28 March 2015 (UTC)
The new plethora of ads substantially detracts from the site. It really makes it seem like a trashy commercial site (of which genealogy has way too many of these days). The banner under the header block on Person and other pages is the most problematic (disruptive and misleading), although some of the ads in other locations are pretty bad too (mug shots, arrest records, find anyone...). The site would do best (IMO) by emulating Wikipedia -- the ad-free nature is welcoming and helps invite new content contributions. Maybe there need to be higher profile ways of soliciting donations, but the heavy ads really are alienating. --robert.shaw 18:47, 28 March 2015 (UTC)

Experiencing the same in the middle of the pages I'm working on ! I have enough trouble with new bifocals. Can't the ads stay on the side ?--SkippyG 02:48, 28 March 2015 (UTC)

I am going to contact Dallan about this. Ad placement is something I have wanted to talk to him about for awhile now anyway. Daniel Maxwell 02:49, 28 March 2015 (UTC)
Notice that the way the logo on the top left of the page is now out of alignment because of the width of the ads on the left. Pages are displaying strangly now. If Dallan doesn't respond here, I will keep trying to get ahold of him behind the scenes. Daniel Maxwell 03:36, 28 March 2015 (UTC)
The ads are an attempt to get the site to make some additional money so I can afford to hire a developer every once in awhile to improve the site. I'm planning to try different ad placements over the next few weeks to find out which set of placements have the highest $/annoyance ratio. I'm not particularly wild about the middle ad, though google recommends that's the best place to put an ad. But I agree that annoyance factor is pretty high. I just switched the middle ad to text-only. That makes it less annoying I think. Another possibility is to remove it entirely. Other possibilities to experiment with are whether the left and/or right ads should be switched to text-only or removed entirely. I'll be trying these variations over the next few weeks.--Dallan 05:28, 28 March 2015 (UTC)
Thanks for the explanation -- I was afraid it was about money. So, what happens if I click the x to get rid of the ones in the middle of the page every time I change a page -- a nuisance, but sending a message. Who gets the message and what does that do to agreement with Google?--GayelKnott 06:11, 28 March 2015 (UTC)
Dallan, you might want to consider setting up an affiliate link arrangement to Amazon for Source pages which are for books sold there. It might be more remunerative than ads, less intrusive, and occasionally actually helpful to the reader. --robert.shaw 06:36, 28 March 2015 (UTC)

Even though I accept the money implications, I've added an ad-blocker. Even with text-only the text of the ads is too large. A margin around them might help. BUT even with an ad-blocker the empty space follows on into edit-mode increasing the time of the editing process. This is important when trying to do a series of similar edits. --Goldenoldie 08:06, 28 March 2015 (UTC)

We should support Dallan on this. I also found the ads fairly intrusive, but also understand the financial implications of hosting a "Free Website", where one of the only sources of revenue is selling ad space.... -Delijim 10:05, 28 March 2015 (UTC)

Well all, Dallan removed the one on the top. I think the ones on the side need to be adjusted a little bit in width, but it is much more tolerable now. Daniel Maxwell 07:34, 29 March 2015 (UTC)

Agreed. Actually, only the one on the right really needs to be made a bit smaller, perhaps allowing more white space on the page (a la Find A Grave). And a third ad at the bottom of the page might work, as well. --GayelKnott 08:08, 29 March 2015 (UTC)

Here are some statistics that may be useful:

  • WeRelate currently makes enough money on ads to pay for the servers, but not for any development costs.
  • With the new ads, WeRelate made enough money today that if it were to continue like this for a full month, we would have $600 extra - enough to hire a junior developer for 20-30 hours a month or a senior developer for 5-10 hours a month.
  • 40% of the ad revenue today came from the middle ad; 35% from the left-hand ad, and 25% from the right-hand ad. These percentages agree with Google's recommendation for ad placement: middle is best, followed by left-hand side, followed by right-hand side.
  • I would prefer not to end this experiment after only one day, but since so many people dislike the middle ad I have removed it. Next we'll find out how much can be made with just left and right-hand ads. After that we'll find out how much can be made if we require the left and right-hand ads to be text-only ads instead of text+picture ads, then with left-hand-only ads, then with right-hand-only ads, then with right-hand-only ads that are 160 pixels side instead of 300 pixels wide. I'd like to run these experiments for several days each so we get more-accurate results than we got from the experiment with all three ads today.
  • FindAGrave has ads at the top-middle of the page, on the left-hand side, and at the bottom.
  • We can't put an ad at the top-middle of the page like FindAGrave does because our drop-down menus would cover it, and google doesn't allow anything to cover their ads, including drop-down menus. We could put an ad in the middle if it were above the drop-down menus. That might look strange though.
  • Over the years WeRelate has typically gotten $100/year in donations, generally from a single person. You know who you are; thank you.
  • Since the beginning of the year, roughly 300 people have made 10 or more edits to WeRelate pages, another 300 have made 1-9 edits, and another 4,000 people have visited the site at least once as a signed-in user but have not made any edits. (If we were to run a donation campaign, my guess is the majority of donations would need to come from the 300 active users.)
  • The majority of site visits: 80-90%, are made by people who have either not registered or who have not signed in. They tend to come to the site from a google search, look at one page, and then leave.
  • I've tried affiliate marketing with Amazon in the past; it wasn't worth the effort when I tried it, though I can provide a special link that you can put on source pages pointing people to Amazon if you want to try that approach.
  • I have not tried becoming an Ancestry affiliate and pointing people to Ancestry (i.e., like the ads like found at the bottom of FindAGrave pages). I believe that most people visiting WeRelate have already heard of Ancestry, though I can try adding the Ancestry affiliate ads if you think these ads would not be more annoying than they are worth.

--Dallan 07:48, 29 March 2015 (UTC)

Thanks for those details, Dallan; it helps to know the facts. I'm stunned by the lack of personal donations. Yes, as Ron below says, people donate time, but if you could make it easier / more visible to encourage people to donate $, that could help you. "Want to keep WeRelate.org from being overtaken by ads? Please donate..." "If you donate at least $___ you (personally) won't see ads" (Don't know if that's technically possible.) Perhaps consider something along the lines that wikipedia or public radio does-- periodic fundraising campaigns where, for a specific period of time, viewers are encouraged to donate money. Set a goal: "We need to raise $nnnn in order to hire a developer to make the improvements you've been requesting; please help us reach that goal..." (and have one of those thermometer things that reports progress against the goal. Off to the donate page now, Jillaine 13:09, 29 March 2015 (UTC)
Suggest that a copyedited version of the bulleted list provided by Dallan be put on a page and placed into the new category Category:Financial support (or a replacement category with more consensus support). --ceyockey 15:24, 29 March 2015 (UTC)

I am one of those 300 active users.

I would like to see these 300 active users as contributors. So my question is: what is the match between me editing a page, or adding a page, and an ad on that same page? Am i expected, when i am looking for the edit button, to see "oh, an ad! let me just click on it", instead of doing my work and edit or add the page?

It does make sense that when i use other people's work, i see ads. It doesn't make sense to want money from me since i already invest my time.

I hope that i can be on a list of 300 active users who - while signed in - are freed from any ads, so that we can do our work.

Thank you, Ron--woepwoep 09:46, 29 March 2015 (UTC)

I like wikipedia's practice of periodic requests for donations and I always give. If this would get WeRelate suggestions worked on, I'm for it because I've given up on WeRelate because of lack of improvement. I don't want those suggestions to just disappear; I want to see them lined thru as completed - so we can know what has been done! So lets give Dallan some help and get this train moving again. Perhaps after an initial push for donations, WeRelate could revert to periodic requests for donations. These ads will ruin us! If wikipedia can support themselves with periodic requests we should be able to do so too - after we get over this 'inactive suggestion list' problem. At least I hope that's what additional funds will be used for! --janiejac 15:29, 29 March 2015 (UTC)

I will add a "Donate" link to the upper-right corner of every page (between Settings and Volunteer) tomorrow. I'm open to other suggestions for emphasizing donations as well. I'm also open to the idea of a donation of say $19/year making it so you don't see any ads.
The argument that "I contribute my time so I shouldn't have to contribute money as well" makes sense, but it means that we're back to ads being the primary source of funding. People who don't spend a lot of time on the site probably aren't going to donate a lot of money to it. And unobtrusive ads make less money than obtrusive ads, so if we want to raise more money, we need to have more ads. On the other hand, perhaps we're generally happy with the site as it is. I'm ok if that's the concensus as well.--Dallan 06:12, 30 March 2015 (UTC)

I consider this a wake-up call, as should all users and supporters of this WeRelate service. To everyone who reads on the bottom of the home page the words, “WeRelate is a free public-service wiki for genealogy sponsored by the Foundation for On-Line Genealogy,” and thinks that the word “free” means “no cost” is either very naïve, oblivious to reality, or an ardent supporter of liberal politicians. Nothing is free! Someone pays the cost: either Dallan out of his own pocket or out of the FOLG organization, generous corporate or personal donators who have no ulterior motive or anything to sell, advertisers who get visibility and a portion of the page space in return for revenue to the site, or the users and subscribers to the service.

Roughly 10-15 years ago I saw the same dilemma faced at RootsWeb, a totally “free” community-based genealogy website, at the time a viable alternative to Ancestry.com. If I remember correctly, as their vision outpaced their capability, as genealogy data contributions increased, and as the need for greater media storage and higher speed access compounded, they asked politely at first for donations, then went to the ad-revenue route, then eventually sold out and fell under the Ancestry corporate umbrella, where they now reside. Whether that is considered a good or bad path to follow, they do still survive and still provide a subscription-free resource to a small slice of the genealogy community.

While I don’t really consider myself an active user here, I guess if based on making 10 or more edits to WeRelate pages since the beginning of the year alone, then yes, I am an active user. I’ve been here off and on since 2008 and have not yet chosen to donate money. So if Dallan feels the only way to fund my use of the service is ad-space, then so be it. As a matter of fact, I think it’s fair I should be provided the choice to either donate to the service or put up with the ads if I choose not to donate. To me it’s worth the “price” of a “free” service. (BTW, a user's "contribution" is not interchangeable with "donation." Really? Quite the opposite, I believe.)

While some may object to the “fat-lady weight-loss ad” showing up on the right side of your grandmother’s person page, either consider that your share of the price for having this service available to you, or consider it an incentive to donate to FOLG and not see that ad again. Those ads will pay for getting that “suggestion list” its much needed attention and should improve the capabilities and use of this site.

Not sure if someone else recommended it or not, but I suggest that every advertisement be immediately followed with a small text below the ad that donations will eliminate the ad for that user.

Thanks, Dallan. --BobC 14:25, 30 March 2015 (UTC)

Foundation for Online Genealogy [28 March 2015]

There are links to http://www.folg.org/ on the main page, the about page and maybe a couple of others. Should this apparently dead link be revised to https://sites.google.com/a/folg.org/family-history/ wherever it appears? --ceyockey 15:22, 28 March 2015 (UTC)

It does seem like http://www.folg.org/ is broken. On Chrome and Firefox it displays as blank; on IE it gives error screen saying "This content cannot be displayed in a frame". The source does look like it's trying to frame the sites.google.com/a/folg.org/family-history/ content. Maybe it should be doing a redirect instead? --robert.shaw 18:20, 28 March 2015 (UTC)

How to donate and Info about donation [30 March 2015]

Suggest that the pages WeRelate:Donate and WeRelate:About donations be merged. Also suggest that the every-page footer include an additional link (making four on the bottom line) to the merged page labeled "Donate" or "Support WeRelate: Donate". The WeRelate:About page should have the donation paragraph removed in favor of a top-of-page link to the new merged donation page. Finally, could a link to financials be placed on the new merged donation page? --ceyockey 15:29, 28 March 2015 (UTC)

I have revised WeRelate:About donations so that it a) cross-references WeRelate:Donate and b) has a working link to FOLG information. I found, and understand why, that I cannot edit WeRelate:Donate. I do think having this as a protected page is best as it contains a bit of functional kit that, if broken, screws us all.

I have also created a new category, into which WeRelate:About donations has been put ... Category:Financial support.

Regards --ceyockey 15:12, 29 March 2015 (UTC)

I find that content at WeRelate:About non-profit status duplicates some information at WeRelate:About donations and suggest that it be redirected. The WeRelate:About non-profit status is protected and cannot be edited by a standard user. --ceyockey 15:37, 29 March 2015 (UTC)

I revised the section WeRelate:About#Please donate to include a word about advertising and to remove the several times said mention of the 'donate button' in the upper right of the page, which I think was there at one time but which I've not seen in a long time. Should there be such a button or link on every page? --ceyockey 15:44, 29 March 2015 (UTC)

I redirected WeRelate:About non-profit status to WeRelate:About donations.--Dallan 05:07, 30 March 2015 (UTC)

Maybe you should put your tax info on a protected template that could be added to the page. You probably don't want people messing around with the tax ID. -Moverton 16:55, 30 March 2015 (UTC)
Good point. I've done that.--Dallan 03:55, 31 March 2015 (UTC)

Method for regular monthly donations [30 March 2015]

Suggest that you look into or describe method(s) for providing small monthly donations which are directly charged to credit or debit card. Thinking in terms of $10 / month as a "sustaining member" donation level. --ceyockey 15:32, 28 March 2015 (UTC)

Good idea, especially if some of us actually followed through? --GayelKnott 08:09, 29 March 2015 (UTC)
There isn't currently a way to have an amount automatically charged to your credit card each month on the donations page, but I could add it if enough people would say they would make use of it. It appears that Paypal supports this.--Dallan 08:16, 29 March 2015 (UTC)

I would do this. It would also be a bonus if doing so would remove the ads.--Wongers 08:24, 29 March 2015 (UTC)

+1, I would as well. --ceyockey 14:25, 29 March 2015 (UTC)
Count me in -- we need to do something to keep the site viable. --GayelKnott 21:43, 29 March 2015 (UTC)
What about a donation of $19/year for no ads?--Dallan 04:59, 30 March 2015 (UTC)
You can count me in as a taker on that amount. Daniel Maxwell 05:17, 30 March 2015 (UTC)
While I think it's a nice kicker to take out the ads for donors, the site for non-donors needs to look professional enough that new people come and stay, or there's no point. I'd rather we focus on raising an overall goal that makes the ads go away as much as possible for everyone. --Amelia 05:38, 30 March 2015 (UTC)
I'm fine with that as well. It's a question of how much people donate and how quickly they want new features to be implemented. An inexperienced developer in the US (i.e., college student) or an experienced developer from Ukraine both cost around $20-30/hour. New features will take from a few hours to a few days to implement depending on the feature, so if we had an extra $300/month, we could probably implement one new feature a month. If we wanted that money to come purely from donations, then each active user would need to contribute $1/month or $12/year. If we wanted it to come purely from ads, then we would need to keep both the right-hand and the left-hand ads. Or we could do a combination.--Dallan 06:26, 30 March 2015 (UTC)
My question would be, is $19 going to be enough? (And is this a one-time donation or an annual donation?) WeRelate desperately needs up-dating, and has for a long time. We are not unique -- there are other free wikis out there -- and we are being left behind because the others offer benefits that we don't. I don't mind being a "niche" site if we survive, but survival is still going to take up-grading. And like Bob C. (above) I am (and have been for some time) seeing "RootsWeb" handwriting on the wall -- not enough money to maintain the site and eventual sale to someone like Ancestry and their ability to gut the good and leave a shell. I agree with Amelia, we need to maintain a reasonably serious appearance in order to attract new users to even a niche site. I can live with one or two discreet ads as a source of on-going income, combined with other means of raising income -- such as an annual donation campaign, for example. If a $20 (or more) donation once a year is enough to make the up-grades and to significantly reduce the number of ads on all pages, then that's pretty small peanuts for the benefits.--GayelKnott 16:39, 30 March 2015 (UTC)

WeRelate and Paypal [29 March 2015]

A couple of observations:

  • I don't see a way via the Paypal site to set up regular donations over time; appears to only support single donations. There was an allusion above to Paypal supporting for payees multiple cross-time payments.
  • I wanted to see if I could find FOLG as a payee in the Paypal interface and could not. I think it would be useful to have the WeRelate payee available as a search return from within Paypal; however, I'm not sure if Paypal supports this for non-profits or only for stores as in retail ventures.

--ceyockey 15:16, 29 March 2015 (UTC)

WeRelate and Allen County Public Library -and- The Genealogy Center [29 March 2015]

The page http://genealogycenter.org/ contains a prominent "Donate" button in the top button bar. It might be useful to clarify somewhere (maybe on WeRelate:About donations) that donation to The Genealogy Center does not directly support WeRelate, though it would support a WeRelate partner. --ceyockey 15:20, 29 March 2015 (UTC)

WeRelate and online charity listing sites [29 March 2015]

I pulled a reference to http://www.guidestar.org/ into WeRelate:About donations and went looking for other online registries, but found some incorrect information:

--ceyockey 16:38, 29 March 2015 (UTC)

Extracted content from the Exempt Organizations Business Master File for Utah; this can be downloaded from http://www.irs.gov/Charities-&-Non-Profits/Exempt-Organizations-Business-Master-File-Extract-EO-BMF and has an explanatory sheet at http://www.irs.gov/pub/irs-soi/eo_info.pdf . The file format is puportedly .csv, but could not open it using Libre Office, so went to Google Sheets and that opened just fine.

STREET724 W 1720 N APT 207

--ceyockey 16:24, 29 March 2015 (UTC)

FWIW, these are all places we've lived since starting FOLG around 2002. The current address is 223 N 835 E, Lindon, UT 84042. We moved here about six months ago. We filed the address change with the state of Utah but possibly not with the IRS yet. We're checking into that.--Dallan 04:57, 30 March 2015 (UTC)

Fundraising proposal [31 March 2015]

Over the weekend five people donated a total of $350 - thank-you!

Also, I have switched the left-hand and right-hand ads to text-only. We'll try that for a couple of days.

It looks like several MediaWiki developers are available for $35-$40/hour. (When I checked a year or two ago it was only $25-30/hour, but it appears to have increased.) I think we'd want to hire a developer for at least two weeks in order to give the developer a chance to get familiar with the code and implement a few features. If we were to try to hire someone for just a few days the start-up costs of becoming familiar with the code would be relatively high. Given that, I think we ought to not hire anyone until we have $3,000 raised either from ads or donations. That would be enough to hire someone for two weeks.

So here is a proposal for feedback:

  • We run a fundraiser the first month of each quarter with the goal of raising $3,000 each quarter.
  • We use the excess ad revenue from the prior quarter to jump-start the fundraiser.
  • We need to have some way of promoting the fundraiser each quarter - ideas?
  • People who contribute at least $5 during the quarterly fundraiser will not be shown ads for that quarter. I could add something like Don't like ads? - Donate links to the top of each ad. I have already taken the liberty of disabling ads for the five people who contributed over the weekend.
  • People who contribute more than $5 will be emailed a link to a google form where they can vote on the WeRelate:Suggestions they want to see implemented that quarter. People who contribute more will have their votes weigh more.
  • Someone needs to summarize each suggestion into a single section with examples: the existing (undesired) behavior, and the proposed (desired) behavior. This will make it easier for me and the developer to understand the suggestion.
  • I will review the suggestion summaries and attempt to estimate the number of days required to implement each one. Hopefully this information will help guide the people who are voting.
  • Once we have raised $3,000 we will hire the developer.
  • If we are unable to raise $3,000 during a quarter, we use the money to jump-start the fundraiser for the next quarter.

My guess is that a few suggestions could be implemented each quarter using this approach. Thoughts?--Dallan 05:07, 31 March 2015 (UTC)