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.


Costs to upgrade MediaWiki version [30 November 2013]

There has been an outstanding suggestion to upgrade the version of software we are running for over a year. It is mentioned on that page as "one of the primary focus". My question - how much would it cost to perform such an upgrade and if we were able to get funding, would werelate be happy to do this via the paid developer route? AndrewRT 20:05, 21 June 2013 (EDT)

My guess is if we were to hire someone to do this, it would cost somewhere in the neighborhood of low five figures. I can't do it myself because I'm working fulltime on a consulting project until the end of the year. In the meantime I'm in the process of open-sourcing the complete WeRelate codebase so that others can help out if they want to: https://github.com/DallanQ/werelate-wiki --Dallan 22:38, 7 July 2013 (EDT)
Terrific news Dallan (re getting the source code onto Github). Well done! :-) I know how hard it can be to find the time to work on these things.
As for paying someone to get it all working with the latest MW, I think you're probably right. My feeling is that there might be enough of us genealogy-hackers around to perhaps get a fair bit done in say the next year... Are you around enough to point people in the right direction and advise and whatnot? Anyway, worth a shot via the open-collaboration route, before trying for funding etc.
But enough talking, I'm off to look through the code! :-) Thanks again. — Sam Wilson ( TalkContribs ) … 22:50, 7 July 2013 (EDT)
Yes, that's the plan and the hope. I'm going to cut back to four days a week on the consulting project at the end of this month and I'll use the extra time to add documentation and provide pointers to anyone who wants to help.
Another thing to consider is http://www.wikidata.org . Wikidata is an effort to create a collaborative structured database for Wikimedia projects. It's been under development since 2006 and is still not quite ready for prime time, but it appears close. Not sure if we should consider using it or not.--Dallan 23:14, 7 July 2013 (EDT)
Wikidata certainly looks interesting. You mean for things like place names perhaps, that are of general interest beyond genealogy? Will definitely be something to look into. :-) I have been wanting to do some sort of analysis of the links between here and Wikipedia for a while... — Sam Wilson ( TalkContribs ) … 23:41, 7 July 2013 (EDT)
Actually I was thinking of the possibility of using the wikidata extensions to manage the database of people, in addition to places, etc. We may not write to the same datastore that the official Wikimedia projects write to, but perhaps we should consider switching over to use the wikidata format at some point if it's going to become a standard for storing structured data on Wikimedia projects. I was thinking it may help us petition to become an official Wikimedia project someday.--Dallan 00:36, 8 July 2013 (EDT)
That looks pretty cool. It looks like there is a MediaWiki extension for Wikibase, which looks like it would put us in good shape for using WikiData? -- Jdfoote1 14:18, 10 July 2013 (EDT)
I've been investigating this group of extensions a bit lately, and am playing around with a system for dynamically importing (as in, it traverses family trees and pulls what it can) data and files from werelate. Nothing to show yet though! :-) I'll post on the WR software page if I have anything. — Sam Wilson ( TalkContribs ) … 02:45, 29 July 2013 (EDT)
I'm curious - do you mean that you're walking the werelate tree and trying to pull data into a secondary database? In this case, WikiData? --jrm03063 10:51, 29 July 2013 (EDT)
Yep, exactly that. Well, not that it's functioning yet in the case of Wikibase, but I've been doing the same for other uses for a while. Basically, selecting two or four people and fetching all their ancestors and/or descendants. — Sam Wilson ( TalkContribs ) … 19:13, 29 July 2013 (EDT)
For what it's worth, I've been thinking that an additional way to rationalize our membership in wikimedia would be to demonstrate that we're the most wikipedia-hip genealogy environment going (not just another user of media wiki software, but a cooperating user/contributor respecting content. So, as a personal goal, I'm trying to get us to the point of being source-attached to 100,000+ WP articles (we're presently at about 98,500). Of those, about 21,000 relate to people/biographical pages, while most of the rest are places. There is however, a small but very interesting and growing group that relate to things that make for sensible genealogical categories (Houses of Nobility, Battles-Campaigns-Wars, Civil War Regiments, and more). The idea for the last sort of thing is something Amelia had quite some time back, but I've tried to run with it more actively since the beginning of this year. --jrm03063 15:57, 10 July 2013 (EDT)
"Low five figures" sounds like a figure that could be raised from a mixture of a grant application (e.g. the Wikimedia Foundation), a fundraising among site readers and perhaps some sponsorship. Is that something you would be prepared to consider? AndrewRT 19:07, 12 July 2013 (EDT)

I've found my way back to this discussion of "Wikidata" - in the context of language neutrality. In past discussions of use of English Wikipedia - concerns were raised that other languages might provide better pages than English.

It appears that language-independent Wikidata human "objects" are the way that different language versions of Wikipedia relate biographies of common individuals. To my mind, this suggests that we might want to move from an English Wikipedia orientation for relating pages between WeRelate and Wikipedia - to something that relates pages between WeRelate and Wikidata.

For example, for Louis XIV of France, the English WP page is perhaps less desirable than the french. However, this wikidata page represents both. It's also easy to see why Dallan thought the database might be a particularly appropriate way for us to represent our database of people - since the Wikidata pages seem to represent genealogy simply be some ordinary properties.

Anyway - thought that this might be a useful direction to go for the many Person pages currently related to English Wikipedia. Perhaps what we really want - is to relate Person pages to the Wikidata object - and somehow indicate one or two preferred language forms for an extract? Or something like that... --jrm03063 03:38, 1 December 2013 (UTC)

An additional idea - since user profiles include a language preference (which is presumably recoverable as a wiki variable) - perhaps there's a natural way to dynamically provide users with Wiki extracts from their preferred language wiki? --jrm03063 22:05, 1 December 2013 (UTC)

Foul language on other's talk page [26 September 2013]

I have just had a new user add vulgar and foul language on my talk page over a disputed point on a family line. Although I have admin powers, it isn't clear to me how one should proceed on this, or if there is even a given rule about this. I would have never thought that a geneological website this would be a problem, but I guess it takes all kinds.--Daniel Maxwell 19:41, 4 September 2013 (EDT)

Mediation might be a good strategy, no matter how disruptive the dispute becomes.

If a particular genealogical issue has potential to be disputed, I think it needs to be recorded somehow. If werelate becomes successful as a go to reference, others are likely to rediscover the issue in future. It would save future wasted energy.

Good luck with that, by the way--Dsrodgers34 19:48, 4 September 2013 (EDT)

This was with a line I wasn't currently working on, but that isn't the point. The user was adding unproven information on an important line (Kenelm Winslow, the oldest known member of the Winslow line). In stuations like this, he should have made a comment on the talk page before making major changes and from there discussed it. But that wasn't my point in commenting about this here. I have had disputes with several other people on unproven/etc information, but they also don't leave disgusting language on my talk page over it. That is why I brought this up here, what WR policy is toward this kind of behavior. Daniel Maxwell 19:51, 4 September 2013 (EDT)
In theory, this is a matter for the oversight committee, but don't hold your breath...
With respect to the issue at hand - and presuming constructive engagement among the parties - a number of templates have been created to help mark things like this. Situations such as no known parents, no known mother, speculative relationships and more. So if the present state of the genealogical art does not offer an accepted set of parents for Kenelm Winslow, then you can mark his page as such. If one or more families are offered as possible, as a matter of speculation, then templates exist to indicate such tenuous relationships.
Speaking as one of the parties that developed the templates, we saw the practice of limiting decisions to absolutes as a potential (and pointless) source of conflict. Instead of forcing decisions to be absolute - parties should be able to indicate alternatives that represent reasonable speculation (not pure guesses mind you - but informed conjecture). Likewise, assertions about a negative state of information (the no accepted connection templates) - also represents a kind of information that we wanted to be able to capture. Perhaps the unfortunate situation here would never have occurred, if Kenelm had been marked as having no accepted parents with some backing documentation indicating as much. Then the person adding that information might have been on notice and been able to avoid possible embarrassment.
In any case, good luck.... --jrm03063 21:19, 4 September 2013 (EDT)
I am of course aware of the 'alternate' tabs, although still new. That isn't the problem. I want to know if users who use vulgar language can be warned/blocked/banned. I just about pre emptively banned him for it I was so upset. Daniel Maxwell 21:32, 4 September 2013 (EDT)
Also, I want to be able to keep his edit of my talk page but have that revision hidden to anyone but admins - at wikipedia this is called 'oversighting' but I am unaware of how that works here.
I found a precedent (from 2009) that says that profanity is not allowed on WeRelate, and the user was blocked. I fully support blocking any user who is verbally abusive. Abusive behavior is upsetting and harmful to emotional and mental health (as recognized by all workplaces I have been in in the last decade or so), and none of us should have to put up with it. If you want to see the precedent, search WeRelate for "profanity" and check out the Talk page hit - the profanity was posted by another person on this person's talk page.--DataAnalyst 21:56, 4 September 2013 (EDT)
Thanks Data. I take it then the user should be blocked now? I was uncertain of this because there is no clear policy as to length of ban, etc. On Wiki it is for set lengths. Daniel Maxwell 22:00, 4 September 2013 (EDT)
I don't know the policy. Try asking User talk:Beth - she did the block in 2009.--DataAnalyst 23:12, 4 September 2013 (EDT)

I have nothing to say on the language issue that others can't say better.

The use of UNKNOWN can come across as capricious and arbitrary. There are plenty of cases where the leading experts present facts for which there is no primary documentation and which evidence actually argues against. Family:John Parkhurst and Abigail Garfield (1) is one case. There are others. I guess this should really be John Parkhurst and Abigail Unknown. But I figure anybody that is serious about this couple will read this page, and so does it really hurt to leave it as it stands? There are many cases where an answer is accepted by some number of researchers, so not considered unknown, but in truth they are based on a string of coincidences that may at some point turn out to be wrong when new evidence is presented. So to me, that is the key: present the evidence. This goes for the people who want to make the hypothetical case, and the people that apparently don't like the hypothetical case. If you can't disprove it, maybe the better policy is just to add a note registering that some author in year xxx said that as far as that one author was aware at that time, the fact was unknown, or that so-and-so authority thinks differently. But assume a person that is really interested will read the page, and don't insist that your personal understanding is the only correct one to display. It seems to me the goal is to collect more evidence and get rid of the unknowns, not to erase possibilities that aren't wrong only to add unknowns.

Arguing against me, of course, is the fact that people put outlandish facts with no sources, and these kind of submissions are almost always wrong when confronted by the need for proof, making it very hard to argue that we should try to respect them. So I can't stress that all this depends on both sides giving the primary basis for anything they think is true and clearly labeling as assumption anything that is not fact. But as a guideline, I suggest: if you can't disprove it, leave it. Register your objection, but no more, until you can earn your right to change it by actually proving the right answer. --Jrich 23:26, 4 September 2013 (EDT)

I know. We've been over this before. I don't mind differing opinions - that's why we have those little templates for weak lines that some might want to note. But this doesn't apply here. What I objected to in that case was that he deleted the unknown earlier wife of Kenelm even though the later wife Catherine was probably not the mother and that is what is believed by the current Winslow knowledge. There existed a page for that marriage (since Catherine is named in his will), but with no children listed because Winslow researchers believe the children were by an earlier wife as I said. So it was the other way around - he deleted it for HIS vision and objected when I reverted it, then used foul language. But if this were merely a simple dispute I wouldn't be posting this here. WR needs a clearer policy on vulgar language and abusive comments, there was one example of this in the past from 4 years ago but nothing is set in stone. Daniel Maxwell 23:49, 4 September 2013 (EDT)

How to handle user behavioral problems is a thorny area, but one aspect about it is clear to me - the involved parties shouldn't decide on and implement any sanctions. An admin who is the target of perceived abuse should avoid taking action like suspension or banning as they often are too close to the situation to make a wise decision. Someone who is targeted by abuse should raise the matter with uninvolved admins or experienced users. Just how to do that, and to whom, I'm not sure, and what guidance about abuse issues they should follow is also murky to me. --Robert.shaw 02:04, 5 September 2013 (EDT)

I'd agree, except that WR doesn't have enough admins for a large body of people monitoring this kind of thing. This is actually the first discussion of this issue on the site at all far as I can see, so this might be a discussion worth having. It sounds as though there is no disagreement with blocking/banning of someone who does it, just on how to implement it. I have not taken any action except for removing the offending remark from my page (which for now is viewable in the history). Daniel Maxwell 02:07, 5 September 2013 (EDT)
Per User:Beth, who dealt with a potty mouth before, I have blocked the offender for 1 week and I will post a warning on his talk page. In the future, when a more clear policy is arrived at, I will put it in the hands of other admins Daniel Maxwell 07:52, 5 September 2013 (EDT)
I awoke to this situation this morning and started a private discussion with the Overview Committee regarding creating a policy for this type of behavior. There are a number of issues here the committee will need to address and clarify for future situations:
1. Abusive communication. This type of conduct cannot be tolerated and a clear policy needs to be created.
2. The action of admins reverting edits before engaging a user in discussion. There are times when reverting a user's edits is warranted, but I believe this process needs to be better defined.
3. I agree with Robert.shaw that "the involved parties shouldn't decide on and implement any sanctions". The manner in which we block users needs to be in keeping with professional standards. When a user is involved in the situation, they are not impartial.
I will post back here when the Overview Committee has drafted a policy. --Jennifer (JBS66) 08:27, 5 September 2013 (EDT)
Let me explain myself. I only reverted the first time, and right after posted a notice on said user's talk page. I assumed I would get a reply and we could discuss it. I only reverted again when he put back the changes I had just explained the problem with. I did not do it without comment on my part. I also hesitated to act myself. As I said, in the future, I am happy to let uninvolved admins do the blocking/banning (unless someone is asking me to help in arbitration). Daniel Maxwell 08:31, 5 September 2013 (EDT)
The primary issue here is, without a doubt, the abusive communication. That needs a strong policy and perhaps even a committee under Portal:Maintenance to help manage. I will make sure this happens, because no user deserves this type of treatment. Secondarily to this, I feel that looking at what may precipitate this type of outburst would be good. I am not at all trying to blame your actions for this behavior! Recently, I have seen a few instances where users with admin rights have reverted then posted on the user's talk page - and the results were angry and unproductive. I am just trying to look at the big picture, so that we can prevent and deal with abusive communication in the future. --Jennifer (JBS66) 08:46, 5 September 2013 (EDT)
You're kidding, right? It's just coming to you now that abusive communication and arbitrary edit reversion needs to be dealt with? --jrm03063 09:02, 5 September 2013 (EDT)
OK, thank you. The user was making other unsourced edits to other sourced pages (see comment by jaques just before mine), 'fixing' things by looking around on rootsweb and the like. Lines before about 1750 or so are some of the better sourced (if not best sourced) material on WR, and those of us that have worked on them get a little territorial especially when unsourced information is added (though I admit, I hadn't cleaned up the Winslow line yet). I had considered asking Dallan to consider some kind of user guide for new users in editing people born before the earliest date the GEDCOM upload will allow (1700?) - in other words, pages where the user has to create them by hand. Daniel Maxwell 08:52, 5 September 2013 (EDT)
Wikipedia has a page called ANI - Administrators Noticeboard / Incidents. Do we need the same here, or is this watercooler followed by enough Admins? Given that there are only 30 sysops on this site, is the easiest process just to contact a handful of them to take action? As to an Oversight Committee policy - would this really be useful, or should we just adopt wikipedia:WP:NPA AndrewRT 16:25, 5 September 2013 (EDT)
I don't think there will be many incidents to justify an entire section like WP, where this kind of thing is probably constant. We are not THAT big, in fact not even close. I think JBS66 is right, this should be part of the rest of the Portal:Maintenance and just another aspect of their job.

A policy regarding "Profanity and lewd language" has been added to WeRelate:Policy and linked to from Help:Wiki etiquette as well. The policy states "WeRelate is a family-oriented genealogy site. The use of profanity and lewd language is not allowed. The first offense will result in a 1 week block with the offending language being removed from the page. The second offence will result in a permanent block from using WeRelate. If a complaint is lodged with the Overview Committee, they will use their discretion to address the situation."

I've also added text on the Help:Administrators' guide asking users with Admin rights to refer requests for blocking to the Overview Committee so that an impartial team can address the situation. --Jennifer (JBS66) 14:57, 26 September 2013 (UTC)

Wikipedia updates [8 September 2013]

Will there be an update of places from Wikipedia tomorrow? I have been incorporating Wikipedia data to a number of English places in the past two weeks. Thanks. --Goldenoldie 09:57, 7 September 2013 (EDT)

For whatever reason, it hasn't run for at least a couple weeks. I wasn't pestering Dallan about it because the current wikipedia extract we're working off is pretty old (there are several hundred that didn't resolve the last time it ran) and we really need an overall update. Don't worry though - hooking things to WP when possible has such a great upside long term! I've made a career of this for the last four years or so. --jrm03063 10:32, 8 September 2013 (EDT)

In the past week I've found several WP entries that have been altered since they were originally downloaded to WR. These allow me to ask for {{source-wikipedia|place}} again, along with selective requests for the remainder of the article, now split into sections. So much for trivial bits of late 20th-century "history". --Goldenoldie 11:36, 8 September 2013 (EDT)

Swedish farm location type? [12 December 2013]

In Swedish genealogy, a country side location typically will include the "Gård", or farm that the person lived at. This is highly useful information as many records will be ordered by Gård, and it's also highly useful to distinguish people from each other as people tended to be quite unimaginative with names. The same place also will naturally recur many times in a family tree, so I do think these should be places, not just notes or comments.

(I have an ancestor whose father, both grandfathers, two great grandfathers and two great-great grandfathers were called Per Matsson or Mats Persson, all from just two farms in the same parish during the 18th century. It's quite confusing.)

So the question then is what location type to use for these locations? It's not a farm. Originally a gård would most likely have been one farm, but by the time the record keeping starts they are typically split into several farms. It's not an estate, because it doesn't have a single ownership. And in any cases none of these words are in the list of location types anyway. It's not a village, because although the houses tend to be located together, it's usually just a question of three-four houses.

The Swedish word "gård" comes from proto-indo-europan *gardaz, meaning "enclosed area", but I don't know if that helps either.

Here you can see how one of these places look i real life.

Any opinions on this? --Lennart 08:37, 9 September 2013 (EDT)

My commiserations. My family comes from a rural area of Scotland that has the same kind of divisions (and the same lack of creativity in naming children). When parishes or townships or areas of other parts of the world are fairly large, it would be handy to have another level of "place". Nineteenth century censuses can show numerous individual dwellings on a single farm. --Goldenoldie 11:21, 9 September 2013 (EDT)

The gård sounds fairly similar to the Irish townland - a subdivision of the large parishes that isn't its own political or administrative entity, but does tend to be used as the basis for organising many of the records. Townland is allowed as a place type and many Irish townlands have place pages on WeRelate - on my own tree I know I've linked to several townlands, including: Place:Skirteen, Monasterevin, County Kildare, Republic of Ireland.--RichardK 11:55, 9 September 2013 (EDT)

I have some familiarity with this, and I do agree with Lennart that a gård distinction can be very helpful in differentiating between individuals and that Swedish records often group individuals living in the same gård together within a parish or locale. However, I am not sure it is necessary to give each gård a separate place page. I think it is just too small of a designation that only applies to a handful of individuals. Saying that someone lived in a particular gård is not much different than saying that they lived on a particular farm or small group of farms or on a particular block. I am curious why the desired differentiation can not be accomplished by putting the gård in the description field or the "name suffix" field in the same way that it is done on other pages (i.e. saying "of Beverly Manor" or "of Pike's creek")? --Cos1776 13:24, 9 September 2013 (EDT)

Indeed, a Townland seems very much like the same subdivision, and is of a very similar size, judging from this and this list of townlands.
We *could* put this into the description field, but it is a stable division that doesn't change much over the centuries. The "handful" of individuals are indeed less than a thousand in recorded history per gård, and of course it's not likely that we record the full history of a parish like that any time soon. But as an example, in the GEDCOM I have that's waiting for review there are 38 individuals, and Uddvide, Grötlingbo appears 14 times, Ronnings, Grötlingbo 13 times. For some individuals it appears twice, as the both die and are born there, but still. (The extended tree for Gotland I'm using as a base for my research contains 247 people born or died in Uddvide, btw).
However, I think the more important question here is searchability. You can search for persons on location, but not on the location description.
I'll defer to the general view of this here, but using Townload as the type would probably be acceptable. --Lennart 14:02, 9 September 2013 (EDT)
I have a similar situation to Goldenoldie - my ancestor's family are from Place:North Ronaldshay, Orkney, Scotland, where the so-called "House" was routinely used as the location for people, often contained several households and is actually a very useful tool in tracking family histories. Indeed in North Ronaldshay there are examples of people like "Person:Thomas Tulloch (36)" from Garso who was normally referred to as "Tommy Garso". Can I ask the question the other way round - what is the rationale for the current restriction on places to aggregations above a particular size? AndrewRT 15:43, 9 September 2013 (EDT)

Norway is similar to Sweden, and as far as I can tell, a Municipality in Norway (which appears to be the smallest division currently recommended in WeRelate) is not necessarily like a city in North America. It might be a city, but in rural areas, it is more like a township. I believe that it is the smallest division with an official administrative body (which I assume guides WeRelate policy), but I don't think that that is sufficient reason to make it the smallest division in WeRelate place pages. For one thing, tax lists have been organized by gård (see this example from 1950), making them of at least some administrative importance (at least as much, for example, as a census division, which is supported in WeRelate). I would like to see the gårds added as well - for the same reasons as given above.

I would draw the parallel with the Town of Hempstead in Nassau County, New York (which appears to me to be like a township) which includes many villages and hamlets (although you can't see that in WeRelate, because each hamlet or village just says that it is also in Nassau County). These villages and hamlets have their own place pages - not necessarily because they have/had their own administrative bodies (although they may have), but because they show up on maps, in VRs, etc.

As for the number of people living in a gård - there can be anywhere from 2-3 families to about 40 families - easily as large or larger than many of the villages and hamlets in North America that are recognized in WeRelate with their own place pages.

Lastly, there are at least 2 more-or-less authoritative sources for the list of gårds in Norway. A list begun by Oluf Rygh in the late 19th century (Norwegian Farm Names) is considered a standard, and there is also an updated version from the draft land registry of 1950 (link above).

I would also like to see a place type of "Gård" added, so that we don't have to characterize these as "Townlands". It would help to show that WeRelate is aware of other parts of the world besides the English-speaking world.--DataAnalyst 21:33, 9 September 2013 (EDT)

Gård has been added to the list of place types.--DataAnalyst 03:27, 12 December 2013 (UTC)
Note: People interested in this topic might also be interested in the discussion on place page names for Norway, as there appear to be similarities between Norway and Sweden.--DataAnalyst 03:30, 12 December 2013 (UTC)

Importing early ancestors [13 September 2013]

I just noticed this:

"The Early column is checked for people born 1750 or earlier. Early people are excluded from GEDCOM import."

Ho hum.

"WeRelate already has wiki pages for many early ancestors"

Yeah, that may be, but not for mine. Or is this site only for Americans?

OK, fair enough, these early ancestors often have bad sourcing, but I think the exclusion in that case should be for people who have no sources, not because they are early. --Lennart 17:16, 9 September 2013 (EDT)

This was a big problem when the site first started. Worsening GEDCOM duplicates of Mayflower passengers or other early immigrants were piling up badly, and when people who didn't know what they were doing merged with someone elses you ended up with a jumbled mess. I still run into these on occasion. But jrm03063 is probably right that certain instances it should be able to get waved when approached by an admin, but I still think our policy on this is the correct one. Daniel Maxwell 14:10, 13 September 2013 (EDT)
There's actually more reasons than simply the past transgressions of various GEDCOMs creating a bad impression. The further back you go, the more researchers you potentially intersect with, and the more appropriate it is to be careful in entering data. And of course, yes, everybody think their sources are appropriate. People that use no sources don't think they're necessary, people that use bad sources do so because they think that's all that needed. In previous discussions, no way to automatically assess source quality could be settled on. --Jrich 19:28, 9 September 2013 (EDT)
I am emphatically opposed to deleting unsourced people pages. Working on early New England families, I have often found data, usually from drive-by gedcoms, which is accurate but unsourced. If the source is relatively easy to find and add, it seems counter-productive to delete it only for some one coming along days or years later to have to start over. Even in cases where the sources aren't apparent (just because we don't know about a source does not mean it does not exist), the data sometimes furnishes clues which are helpful in putting families together.--jaques1724 20:35, 9 September 2013 (EDT)
different topic, I think. --Jrich 23:41, 9 September 2013 (EDT)
Definitely different topic, but might be worth bringing up. IMO unsourced people who has had no edits since import could be deleted. The information is typically easily found on other sites. But, no biggie. --Lennart 14:35, 13 September 2013 (EDT)
I agree with jaques. Eventually hopefully someday somebody will come along and clean up all those pages. But they are part of families that have been linked to, so form a junction in a big mesh that is our unified tree, and to create holes by deleting them is just as disruptive. For example, when somebody deletes their tree, it will often delete 2 or 3 children out of a family of, say 8, leaving the family incomplete, etc. Also, occasionally, the source is posted on the family page, and so it's there, just in a different spot than might be expected. Better to let the cleanup on existing problems be done in a thoughtful, careful manner, just limit the amount of new problems that can be created as much as possible. --Jrich 16:20, 13 September 2013 (EDT)
I'm pretty sure that any of these policies can be waived if someone thinks they have a special situation, or their GEDCOM content is particularly well done. The policies represent what seems to be good practice in the general case. Folks should feel free to appeal if they think it appropriate. --jrm03063 11:25, 10 September 2013 (EDT)

Help with a Transcript [10 September 2013]

I'm making my first attempt at creating a Transcript page and am not really clear on the most efficient/useful way of doing it. I'd appreciate it if some of you who have experience with transcripts would take a look at the initial part and provide suggestions on how to improve it.

Transcript:Biographical Sketches of Graduates of Harvard University, in Cambridge, Massachusetts:Wise, John, 1673

--jaques1724 23:00, 9 September 2013 (EDT)

I would be happy to help. Let me know where you want to converse... --jrm03063 11:27, 10 September 2013 (EDT)
[1]. --Jrich 11:51, 10 September 2013 (EDT)

New logo [12 September 2013]

What happens next with the Logo Suggestions? AndrewRT 17:03, 10 September 2013 (EDT)

The next step is a vote, but I will bring this up at the Overview Committee meeting on Sunday. --Jennifer (JBS66) 08:05, 12 September 2013 (EDT)

WR needs clarification of the 'Famous person' living exception [26 September 2013]

I apologize if this was discussed elsewhere, but I couldn't find anything in a quick search. I noticed that several siblings of President George HW Bush were tagged as speedy delete, which I have deleted. But I think WR needs to clarify what persons fall under the famous living person exception. Being the brother or sister of a famous person doesn't seem like a good enough reason, but this isn't defined anywhere I noticed. I suggested something else related to this to Dallan, but I want to bring it up here. Person:George Bush (2) has an ugly 'after 2010' in the death section so he could be added. Could this instead be replaced by a 'famous person' tag which will then enter him and anyone else with it into a category so it can be checked to be certain the person meets WR's criteria for 'famous'. Merely having a wikipedia page doesn't seem like a good enough rule for famous but before I go on a deletion spree of the siblings/nephews of George Bush I want to be sure.--Daniel Maxwell 13:54, 13 September 2013 (EDT)

When you say "clarification" do you mean that or do you mean "change"? My understanding was that the rule was clear cut: no living people unless they have a Wikipedia page. The rationale is simple: the website excludes living people in order to protect privacy. If you are the subject of a Wikipedia article then the information is already in the public domain so there can be no objection to having the information on here. Adding an extra rule trying to define "famous" would be a futile exercise and just lead to endless disputes. What possible advantage could there be in deleting this information? All it does is degrade the quality of this website and annoy the people who have spent time adding it in the first place. AndrewRT 16:47, 13 September 2013 (EDT)
I don't see anything 'clear cut'. In fact I see zero actual stated policy. I am not suggesting deleting George Bush, British royals, or other clear exceptions obvious at all. But what about border line cases? Brothers of famous people, nephews, etc. What about their spouses and children? Many of them are not considered notable enough for wikipedia, why here? And I also don't like the idea of being wedded to the hip of wikipedia policies. Alot of people on Wikipedia I do not believe are famous enough for their public information to be widely known and discussed. A wikipedia article is a pretty low bar considering what passes for 'notable' over there. But assuming that they are, why are non notable nephews of George Bush to be left intact? Daniel Maxwell 16:54, 13 September 2013 (EDT)
I think that the Wikipedia policy explained here makes a lot of sense for us to adopt as well. They say that people's private information (e.g., birthdates) should only be on WP if that information has been widely published or if the person has made it clear that they don't mind that information being known.
Wikipedia has a much larger community, and receives a lot more scrutiny. I definitely don't think we need stricter criteria than they do, and I think it makes a lot of sense to piggyback off of the natural scrutiny that pages there receive (especially pages about living people) - I vote that our criteria for including living people is that person must have a Wikipedia page with a birthdate. That seems both straightforward, and easy to "enforce". -- Jdfoote1 17:08, 13 September 2013 (EDT)
We are not a branch of Wikipedia. Let's get that out of the way first off - not to mention that Wikipedia condones the storing of large amounts of porno on their commons site - including some absolutely unspeakable images. Wikipedia is not a good example of a 'responsible' site. But let me given an example related to my point- perhaps a certain author, or military personnel, or reporter, notable enough for wikipedia - can we really say that some of the Generals added there are notable to have the names of their spouses, children, etc added to WR? +
Actually, this is a sidetrack about my actual point in my first post that AndrewRT flipped out over. Are the non notable siblings and relatives of Presidents now OK here? That is all I was talking about deleting. If there is notability, it should be on a case by case basis. Daniel Maxwell 17:16, 13 September 2013 (EDT)
I start to see the issue. I was just looking at the father of the Duchess of Cambridge. While he doesn't have his own WP page proper, he is discussed explicitly in a section on her WP page. So being absolutist about whether there is or isn't a WP page may be missing the mark a bit. But it does get dicey if we start letting people make an argument on a case-by-case basis. What if the requirement is that there be a WP page dedicated to the person, or that contains discussion of a person's genealogy - and further - that such WP page be provided as a source in support of a death fact/living person exception? --jrm03063 17:51, 13 September 2013 (EDT)
See this page as a for example - Person:Michael Middleton (3) --jrm03063 17:56, 13 September 2013 (EDT)
On the other hand, the page for his father seems more problematic. --jrm03063 18:01, 13 September 2013 (EDT)
It's quite possible that this is one of those things that was discussed to the point of a conclusion - but nothing was ever recorded in a way that we're able to find just now. That said, my understanding is that the only exception is for people with a Wikipedia page - and even then - the only thing we allow is the mechanical extract of the wikipedia content. When I've created such pages, I leave the death date and place empty, but add a description to the death fact that says "wikipedia notability excepetion". I suppose we should get this policy written down somewhere, and I should go back turning those descriptions into a template that takes people to a policy statement... --jrm03063 17:25, 13 September 2013 (EDT)
I think that it's simplest to understand and enforce if it's a hard and fast rule - living people must have a WP page of their own in order to be included here. -- Jdfoote1 17:59, 13 September 2013 (EDT)
But then it can ONLY be for that person. That is what I meant by case-by-case. General so and so's wife is not famous, and neither are his children, or his possibly still living parents. That is where I see the problem and where I believe it steps into invasion of privacy, or could. Under this rule, GWB's nephews are not famous and will be deleted unless they become notable in their own right. Daniel Maxwell 20:47, 13 September 2013 (EDT)

The policy is at WeRelate:Policy#Living People, and says;

Information on living people will be removed unless the person is a notable individual documented on Wikipedia whose shared ancestry is likely to be of interest to the community. (This exception is used primarily for heads of state.)

There is this guidance, which is similar but not the same, on Help: Person pages:

The exception [to "no living people"] is for famous and notable people whose ancestry is of interest to the general public. The general rule of thumb is that if someone has a Wikipedia page listing their birth information and/or parents, a WeRelate page may be created for them. This exception is used primarily for heads of state.

So having a Wikipedia page is a prerequisite, but they also need to be someone "whose ancestry is of interest to the general public." There is much discussion from 2006 to 2012 at WeRelate talk:Living people.--Robert.shaw 18:13, 13 September 2013 (EDT)

I'm going to chime in since I'm pretty sure I wrote both those help pages ... they express the original rationale for the exception that's described above: there's no point in deleting information about (originally, extremely) famous people who happen to be living, and a greater benefit to leaving it because it shows the common ancestry people might be interested in. The policy was defined when it was pretty much only used for Bill Clinton, the George Bushes, and Queen Elizabeth. I didn't expect at the time it would be as widely used as it is now (hence the head of state reference), but that goes to show that different people find different lines interesting. Since it's no longer true that the exception is used mostly for heads of state, that should be deleted.

While ideally I would argue that interest in the ancestry should also be its own criteria, as a practical matter that's impossible to enforce. The only way to have a clear enforceable rule that is something other than allowing or banning all living people is to refer to some external standard to define what's famous. Wikipedia, faults included, is the best thing I can think of -- it's readily accessible to all, it covers all types of famous people, it has a policy on this (that's arbitrated by far more people than we are), and it's constantly updated. It also has a benefit of making this a very easy question to answer--George W. Bush's siblings and one nephew get pages, if people so desire to create them. In relatively rare cases like the Duchess of Cambridge where there are living parents/grandparents not themselves famous, they can be links in the chain listed as "living" for now.--Amelia 01:35, 14 September 2013 (EDT)

I don't have anything more to offer on what the policy is or ought to be, other than running with an idea from User:DMaxwell to provide a common practice for labeling the situation. See this template and this category. Check out any of the pages listed in the category for examples of use of the template. --jrm03063 09:04, 14 September 2013 (EDT)

The Overview Committee discussed this today. The exception to the living person policy is only for people who themselves have a page on Wikipedia (on any of the language versions). The exception does not extend to living people who are mentioned in a Wikipedia article. In the example given above for the Duchess of Cambridge, she would have a page on WeRelate since she has a page on Wikipedia. However, her parents would not have pages on WeRelate. WeRelate no longer allows empty placeholder pages titled Living - so it is advised to place a link on the Duchess' page to her grandparents' page in the free text field as well as a link to her page on her grandparents' pages. This follows the policy that states "If you would like to link pages to others that would otherwise be linked through living people (in-laws with living children, for example), do so by creating direct links in the body of the pages. Do not put information about the living people on the pages."

I have not heard of any requirement that "the only thing we allow is the mechanical extract of the Wikipedia content." I will ask Dallan for clarification on this. --Jennifer (JBS66) 10:30, 15 September 2013 (EDT)

I encourage the committee to review this category. It collects Person pages of the living that I have found, entered by a variety of folks (oddly enough, mostly NOT me...). A number will be found to be without directly corresponding WP pages - but none of them strike me as an intrusion upon privacy. I expect to continue my search and tagging efforts.
My memory as to whether anything other than a mechanical extract is allowed may very well be flawed, as it may simply be my imperfect memory of a good way to prevent misuse of these exceptional pages for the living, and not a policy as such. --jrm03063 20:15, 15 September 2013 (EDT)
The policy states there must be a corresponding WP page for the living person exception. I wonder if it would be wise to add a few parameters to the exception template, namely the page title and language version. Then, the link in the death field could go to WP. The page could still be placed in the FamousLivingPersonException category, but there would be only one link to it on pages instead of two. --Jennifer (JBS66) 08:44, 16 September 2013 (EDT)
I'm not usually in favor of revisiting policy, but this is a case that may be justified on grounds of improved information on the issue. In particular:
  • We now know that the domain we're talking about is relatively small (the current category is just shy of 100 - assuming we double that - it's still pretty small).
  • It's clear that WP won't have a separate page for every person that is openly discussed. Spouses, parents, and other immediate family of a really famous person are often very explicitly discussed in WP - even though they may not justify a WP article in their own right.
  • The value of being able to add pages for a famous person is going to be seriously diminished if we can't also allow entry of linking people that connect to that person to their genealogical past.
I'm not going to try to suggest exactly what the policy really ought to be - beyond the (it seems) generally accepted principle that we should have a common practice for marking this situation. At present, I'm working through the category to see how many don't have their own exactly corresponding WP page. I'll bring those names forward when I have them for wider review. --jrm03063 15:44, 18 September 2013 (EDT)
Ok, I've walked the entire category, adding WP sources where needed, and all I've come up with is Person:Michael Middleton (3), (comment added by User:Jrm03063)

I'm glad that the Oversight Committee has given us a definitive policy on this now - as I said before, the main risk is that the website infers that a category of pages is acceptable, someone like me comes along and adds them and then some time later someone else comes along and deletes them because they have interpreted the policy differently. Now I hope we can all agree to implement the policy that's been agreed.

It's a pity, however, that Jennifer's explanation of the policy chose a bad example that was factually incorrect: "In the example given above for the Duchess of Cambridge, she would have a page on WeRelate since she has a page on Wikipedia. However, her parents would not have pages on WeRelate". Actually, Wikipedia has pages for both at https://en.wikipedia.org/wiki/Michael_Middleton and https://en.wikipedia.org/wiki/Carole_Middleton. Perhaps you can clarify what you meant by this - should we follow the words of your agreed policy or the specific example you gave?

As for her grandfather Person:Peter Middleton (3), he is clearly allowed on WeRelate as he died in 2010. The key thing about this family is that they are a notable family in their own right as they are descended from minor nobility, hence the interest in their ancestry. AndrewRT 20:57, 26 September 2013 (UTC)

Sorry, slight correction: Based on this discussion it seems that there are divergent views on Wikipedia as to whether or not they qualify for separate pages and the situation is currently still fluid. AndrewRT 21:14, 26 September 2013 (UTC)
When I wrote the above message it was factual ;) I checked WP to make sure pages did not exist for Michael or Carole. At that time, I am certain they were both redirected to Catherine's page. It's odd, because Carole's history on WP says it was un-redirected before I wrote the post. Anyway... it would be correct to follow the words "The exception to the living person policy is only for people who themselves have a page on Wikipedia (on any of the language versions). The exception does not extend to living people who are mentioned in a Wikipedia article." --Jennifer (JBS66) 21:25, 26 September 2013 (UTC)

Tree Delete Nomination [2 October 2013]

Been a while since I found anything quite as unhelpful. The GEDCOM upload of User:Wuiske on 7 Jan 2008 - not a large one - but seems uniformly disconnected and utterly unhelpful. I could delete it by hand on my own, but the few dates that it has put it outside the medieval spaces where I'm usually operating. --jrm03063 03:09, 15 September 2013 (EDT)

This tree also contains a large percentage of pages without dates, many of which may be living. Since these types of pages would be rejected in current GEDCOM upload standards, Dallan will delete the tree and inform the user. --Jennifer (JBS66) 10:32, 15 September 2013 (EDT)
The tree has been deleted.--Dallan 02:33, 3 October 2013 (UTC)

Too many DAR GRS Source pages [6 November 2013]

Please excuse this post if this has already been discussed elsewhere. I could not find mention of it.

I have been noticing that there are a lot of different source pages which all seem to be for the same source, namely the online DAR Genealogical Research System, so I did a little search and came up with the list below. It looks like all parties were going for the same thing, but had slightly different approaches and used different page titles which resulted so many duplicates.

What are the opinions on combining them ALL (yes, I did say "ALL") into one source page and what is the favored approach? This may cause some waves with some of the originators, but others seem to have moved on.

Did I miss any? --Cos1776 01:09, 20 September 2013 (UTC)

Well, "Applications for membership" seems more specific than the others. But otherwise, yes, merge. --Lennart 09:27, 20 September 2013 (UTC)

WELL! Please excuse me - I've merged the two "Genealogical Research System" sources and opened a discussion on this below. I'm not sure whether the Descendants database is really the same as the list of ancestors. I also seem to remember seeing a note somewhere that Applications for Membership do not appear online (and some of that material, which may be ordered, remains copyright to the DAR who explicitly refuses having it reproduced on line). So hmmmm! --jrm03063 15:30, 6 November 2013 (UTC)

Signing in [21 September 2013]

Until yesterday it was usually the case that one sign-in was enough for a day. Suddenly I am having to sign in every time I reopen my browser. This is a bit of a pain, but, okay, security is security. HOWEVER, I was just leaving a message on someone's talk page, went to preview it, and was told I had to sign in before editing. The message, which I had spent 15 minutes on, has disappeared. Grrr. --Goldenoldie 10:30, 21 September 2013 (UTC)

What browser & version are you using? --Jennifer (JBS66) 10:37, 21 September 2013 (UTC)

I am experiencing this as well using Chrome. It used to only happen when i stepped away for several hours which was understandable, but yesterday it was happening every 15 min or so. I feel your frustration goldenoldie. My workaround to avoid losing text is to open a new tab or window, sign on in the new window. Then go back to the old window, hit the back button and an alt-p (preview) and you should be able to continue editing. This is not a fix (which is still needed), just a salve to help you avoid losing your work in the future. Best wishes! --Cos1776 13:19, 21 September 2013 (UTC)

I've alerted Dallan to this problem. --Jennifer (JBS66) 13:24, 21 September 2013 (UTC)

I am using Firefox, latest version as far as I know. So glad to know I'm not the only frustrated one. Speed of upload has improved as the day wears on. (I am in the UK so I have been using WR for 8 hours already today.) --Goldenoldie 14:25, 21 September 2013 (UTC)

On another issue, Dallan said some hardware was changed out recently, perhaps some configuration wasn't quite preserved. There seems to be some changes with patrolling too. --Jrich 15:00, 21 September 2013 (UTC)

Problem with images? [22 September 2013]

Is anyone else having issues with some images loading? Like [Image:LibraryBook.GIF] or [Image:Letter from Fanny Cook to Catherine Munday, 29 November 1875, page 2.png]. I'm getting 404 errors for both. (The actual image files, I mean, not the description pages.) Most other images are working though. — Sam Wilson ( TalkContribs ) … 01:05, 22 September 2013 (UTC)

At least I now know it's not my computer or server. Lots of problems with loading thumbnails -- presumably to be fixed soon?
Of greater concern, I can't get the Duplicate families report -- it's "Not Found". --GayelKnott 01:33, 22 September 2013 (UTC)
Well, the site seemed altogether down for a while there. When systems come back up, they sometimes don't immediately return with their full complement of filesystems. It's pretty easy for me to believe that images live on a different filesystem from the wiki database proper. Other reports? Also possibly somewhere not currently up/accessible. So I'ld say hang in there for now... --jrm03063 01:44, 22 September 2013 (UTC)
Search server also seems down - so if you can tear yourself away - it's probably time to call it a night... :) !
Yes, let's see what happens in a few hours or tomorrow. I assume Dallan knows what's up? As for calling it a night — I've only just had breakfast! ;-) Sunday morning in WA... — Sam Wilson ( TalkContribs ) … 01:52, 22 September 2013 (UTC)

Thanks for the Wikipedia Update! [9 October 2013]

To Dallan et. al. - thanks for the wikipedia (WP) update of 9/22. It hadn't run for several weeks and the accumulated backlog of pages waiting for a WP extract was approaching 500. So let me start by saying I'm most appreciative...

However...the extract we're working from is getting a bit tired. Even after the refresh, 120 "source-wikipedia" templates were not resolved. Also, more and more I'm starting to notice that useful internal cross-links aren't resolved. By that I mean - if WP page "A" is extracted and has a reference to some yet-unreferenced page "B". Then, we add a new correspondence that creates a correspondence for "B". The extract present on "A" doesn't get the local cross link to "B" until we perform the full update. It's possible that there's value in having an intermediate WP update to pick up such cross-links - even if we don't go to a new full WP extract (I defer to those who do that work to know whether it's just as easy to do the full update with a new extract).

So thanks again, and please forgive me for asking for yet more! (BTW, our overall correspondence set w/WP is approaching 100,000 - which starts to make us look like we're serious about making use of WP content. I don't know of anyone else that has tried to bring open scholarship like this into genealogy on this scale - between WR native content and integrating WP content. I really think this matters - but then, I always did...). --jrm03063 14:35, 23 September 2013 (UTC)

I would like to second the vote of thanks for the wikipedia update of 9/22. My personal backlog of place pages was about 100--yesterday my email letter box was very large.

A couple of things I noticed: (1) distances appear to be coming across from Wikipedia to WeRelate--is this the end of place A being "about south of" place B? Sure hope so. (2) sometimes the Wikpedia page writers change their titles between our making an original request and the time the request is acted upon (for instance, writing separate sections for "History" and "Geography" when we had noted a single section entitled "History and Geography". In this case the update cannot be made--and worth checking if a section update is still sitting there untouched after several months. --Goldenoldie 19:47, 23 September 2013 (UTC)

New Logo Suggestions - please vote [19 January 2014]

It was suggested back in July that WeRelate could use a new logo. The Logo Suggestions page was set up to collect ideas. Now, we would like to put this to a vote. Please take a moment to view the logo ideas at Logo Suggestions. Then, sign your name here to vote for the logo you would like to see represent WeRelate. Please note that due to attribution requirements, the final logo may need to be tweaked a bit. --Jennifer (JBS66) 13:47, 26 September 2013 (UTC)

  • Votes for Single Tree
--Lennart 08:24, 29 September 2013 (UTC)
  • Votes for Collaborative Forest

I wish I could see where to sign my name. My vote is for Collaborative Forest--if the belt was deeper and more visible. --Goldenoldie 09:50, 29 September 2013 (UTC)

  • Votes for Delijim's Suggestion
--Jhamstra 16:37, 26 September 2013 (UTC)
--Cos1776 18:43, 26 September 2013 (UTC)
--Q 19:53, 29 September 2013 (UTC)
--User:janiejac Though the tree could be just a tad smaller; but NOT small like 'single tree'.
  • Votes for Relating
--AndrewRT 20:40, 26 September 2013 (UTC) My choice (assuming I can't vote for my own), although as per Jrich, I would prefer they were narrowed down and then iterated.
  • Votes for Sharing (color)
--Daniel Maxwell 22:34, 26 September 2013 (UTC)
--Lidewij 08:11, 29 September 2013 (UTC)
  • Votes for Sharing (gray)
  • Votes for keep the original logo
--RichardK - I'm not particularly inspired by any of the suggestions. The current logo may not immediately shout 'genealogy' at you, but it's distinctive, bright and slightly eccentric. I say stick with it unless and until someone comes up with something truly worth changing for.
--Prcb 17:46, 19 January 2014 (UTC) I actually kind of like it, it's abstract, simple, and active. The very clean look of WR is enhanced by this logo. I'd vote for change if an alternative were a clear improvement.
  • Votes for none of the above
Nothing strikes me, nor do I think the old one great. No real ideas, I might combine Relating (interconnected) and Sharing (puzzle) ideas? --Jrich 19:46, 26 September 2013 (UTC)
I do want to express my appreciation for the efforts invested so far, but I don't feel like we're there yet. I would rather see the interested parties continue to work the issue. Changing when we're not ready - leading to another change too soon - would be very unfortunate. --jrm03063 23:04, 26 September 2013 (UTC)
While I did vote, I do think this could use some more work. A ton of other genealogical sites use some kind of tree/branch/forest for a logo. I cannot say I am a fan of the 'pawns' logo, either though. Daniel Maxwell 02:44, 27 September 2013 (UTC)
Agree with users Jrich and jrm 03063. --Beth 00:07, 27 September 2013 (UTC)
I prefer to keep the existing logo while we keep working on something unique to WeRelate. --Susan Irish 17:25, 28 September 2013 (UTC)
Ditto. I like the idea of Relating (prototype), but it is definitely a prototype, and doesn't suggest genealogy. The Trees, however trite, are recognizable as genealogy. So, relating (connecting), collaboration, and quality -- all in one? --GayelKnott 18:59, 28 September 2013 (UTC)
I agree that we aren't there yet, but I think that we can't just let things die here. I think that almost any of the suggestions would be an improvement to the current logo, but I think that it's not worth changing until we've found something we love. My worry is that we'll just push this off forever. How do we move forward to actually get closer to a new logo? -- Jdfoote1 20:23, 28 September 2013 (UTC)
I suggest we leave it open for a couple more weeks to let everyone have their say and then see what the verdict is, although the current prevailing view seems to be that more work is needed. AndrewRT 20:49, 29 September 2013 (UTC)
--Artefacts 03:49, 10 December 2013 (UTC)"Sharing Genealogy" and "Sharing Genealogy Through Collaboration" could be tighter: "Collaborative Genealogy" or "Genealogy Collaboration". Or, there is an opportunity to really globalize the site with "The World Family Tree" as the second line, like how Wikipedia has "The Free Encyclopedia". If that is considered taken, maybe "The Free World Family Tree" of "The Free World Genealogy"? The font in the wordmark seems slightly less professional than possible, given that Wikipedia itself uses an open-source Libertine font: http://en.wikipedia.org/wiki/Logo_of_Wikipedia. To get people to fully associate WeRelate with the idea of a wiki like wikipedia (an online collaboration that goes beyond a database and includes articles), I would go with an all-grey logo and the puzzle piece does seem to draw that association as well -- is it possible to take the puzzle piece globe from wikipedia and stick a tree on top of it?

--Artefacts 05:18, 10 December 2013 (UTC)I don't have Adobe Photoshop c5 but if somebody does: http://psd.tutsplus.com/tutorials/3d/create-a-spherical-3d-puzzle-with-photoshop/ --Artefacts 06:38, 10 December 2013 (UTC)Put my money where my mouth was and built what I could Talk:Logo_Suggestions#Implying_the_Collaboration_with_Wikipedia_elements_.5B10_December_2013.5D

Howdy, I thought I'd take a stab at a "compromise Logo" combining two of the logos that may be a good alternative (combined 5 votes so far):

Jim--Delijim 16:22, 30 September 2013 (UTC)

A good logo is a really hard thing to do. It needs to be identifiable when it's shrunk down to be the tiny left-hand side icon on a browser URL type-in field (perhaps 8x8 pixels?). It also needs to look nice when it's grown to a much larger size. You probably can't just rely on automatic algorithms to do the growth/shrinkage - you will probably have to create a number of different explicit sized versions for tiny, medium, large, and extra-large variants. Somewhat perversely, the different versions will be needed in order to get different size images that will be perceived by a human as, in fact, the same image (the next set of candidates should be shown at different sizes).
If I had a really expensive Madison Avenue firm designing a logo for us, I'ld ask them to try to come up with a design that suggests as much of the following as possible (in no particular order):
  • a single shared space/tree
  • A collaboration environment that isn't just optional - it's fundamental/required
  • We're a wiki
  • We're the cool way to do genealogy.
  • Your information is safely in the care of a real library
  • We're free - and so is your information - now and forever
  • trees (as images) suggest genealogy well enough, but I'm not sure identifying us as another genealogy site/software system is what we need from our logo. I feel like people will already know that - what they need to know is how we're different from the others.
  • Words or a motto can be nice in/underneath the larger versions of the logo, but it would be unfortunate if a wordless version (required in the tiny form) didn't suggest any of the key features/differences about WeRelate versus non-collaborative approaches
Some rough ideas that try to break/expand the trend of trees and individual puzzle pieces -
  • people holding hands suggests collaboration - people working together and making one of those pyramids that we made in HS gym classes years ago suggests something about collaboration and yet a single entity.
  • It wouldn't be a sin to use elements of the existing logo to create the new one - in could be a benefit. Could a different arrangement of the people do a better job suggesting key themes of our site? Different people working on the same puzzle? One of our existing logo's "people" on one side w/a puzzle piece below them, another adding a second piece to the first. Or even - two such people looking down from different sides at two linked puzzle pieces.
Like I said - I'm pretty sure that this is the sort of thing that's really hard to do well. I'm pretty sure I'ld be awful at it. So the people making this effort have my respect and gratitude. That said - if we go to a new logo - I hope we're really sure that it's an improvement, lest we do more harm than good. --jrm03063 17:52, 30 September 2013 (UTC)

Ok, I'm not sure how we'd possibly be able to accomplish communicating everything you've listed above without coming up with a logo with way too much text or way too busy.

My take is as follows:
  • the Logo needs to be fairly clean and not cluttered with "mixed messages", IMO.
  • The collaborative environment of a wiki is still an unknown to many, that is I believe the most important aspect of what wiki sites like WeRelate "bring to the party", and needs to be emphasized most, IMHO. I still run into people that are working on their family tree that are unaware or somewhat unaware of the positives of a wiki environment.
  • Althouth I didn't come up with the puzzle piece logo, the more I thought about it, genealogy is like trying to assemble a very large puzzle, where some pieces fit, but many do not, so I think the puzzle part of the logo works for most serious genealogical researchers, unless they just don't like puzzles. :)
  • As one person noted above, the tree symbol may be sort of over-used, but it still remains the "universal symbol" of genealogy.
  • I'm not particularly big on logos with people "holding hands" and the whole "cumbaya" thing, but maybe that's just me.
  • Finally, I'm not sure we'll ever be able to reach a consensus on this since we have so many varying opinions, which reminds me that a camel was a horse designed by committee, so if anyone wants to step-up and give it a better try, then I'm not sure we'd ever get total agreement.

Anyway, just my $.02. Best regards to all,


I entertain no illusion that all of what I note could be accomplished - like I think I said - if I had a ton of money and could ask for the sky, the moon, and the stars - it might look something like that. Still, there is something there that I'm wanting to stress: we should know what we're trying to communicate in a new logo. The extent to which a new logo does or doesn't do a better job of communication, is the extent to which it should be favored. I don't favor new for the sake of new - because that costs you whatever market identity you already have - without any clear idea that you're going to improve something.
Maybe the holding hands thing isn't your thing - and I'm not sure it's mine - but I think there are more female genealogy enthusiasts than there are male - and maybe it would reach them? Maybe a different image - one of our current WR logo "people" handing a puzzle piece off to another WR "person"?
If you think that people don't know that WeRelate is a genealogy site, then a tree makes sense. Still, a tree on its own is pretty weak and we ought to be able to send a bigger message. Maybe a tree with a trunk that looks like a big number "1"? Suggesting that we're working on one tree? Maybe a tree in front of an obvious background containing a big "1"?
When I see another round of logos - I'm going to try to imagine how they do (compared to what we've got) - on communicating ideas like those in my notes above. They could be subjectively great art and beautiful even - but this is art with a purpose. I mean no disrespect to the people who are working on this - I think this is really, really hard - but I felt like I couldn't vote on other people's efforts without being clear about how I'm measuring them. --jrm03063 19:25, 30 September 2013 (UTC)
Just thinking about process here, there isn't a clear favourite here so it sounds like there needs to be another "round". I suggest the process needs to include some kind of "reward" for the people who have spent the time to develop their logo suggestions, so how about we say the three logos that got more than one vote (i.e. sharing, relating and Delijim, counting jrich and GayelKnott per their comments) should go through and people should be able to submit logos that are developed from one or more of these three? Given the small voting base here, should we try to sample non-users of the site as well? AndrewRT 20:11, 30 September 2013 (UTC)

My understanding of a Logo is that it is simple so it is easily recognised. This is a good example, the banks logo is well know by all Australians but what does it have to do with banking? [2] I like the tree and jigsaw idea but keep it "symbolic". Use the KISS method of design! "Designing a good logo is no simple task" quote from Wikipedia but it doesn't have to be a complicated design.--burgjoh 23:56, 2 October 2013 (UTC)

I am a terrible artist but I am quite good at visualization. Here are my thoughts:

1) A slogan and a logo are not the same thing - they are processed in different parts of the brain. I dislike any verbiage in a logo. It takes too long to read whereas a distinctive logo can be instantly grasped by the visual part of the brain without having to invoke the language processing center.

2) I think that if we simply put hands on opposite sides of the puzzle piece(s) it will convey collaboration. Two hands, each on a separate piece with the pieces interlocking, should convey the concept.

3) I would flatten the tree into the puzzle piece(s) and leave it incomplete - branching off the edges.

I can see this in my head but I cannot draw it: two interlocking side-by-side pieces each held between thumb and forefinger, thumb and forefinger on opposite sides (and rotated) - one above and one below, tree spreads across the two pieces. --Jhamstra 00:57, 3 October 2013 (UTC)

Maybe a snipped of the hands from "The Creation of Adam" - but with the hands a little further separated holding interlocking puzzle pieces? Sacrilegious I know - but struck me a little funny! :) --jrm03063 16:48, 3 October 2013 (UTC)

This graphic and this site is a good place to look for inspiration


Would be nice to convey yhe concept of the whole being greater than the sum of the parts and high quality (Gold standard) maybe one of the pieces could be golden and just connecting mahes the others turn gold (graduated fill)--Dsrodgers34 03:51, 3 October 2013 (UTC)

Based on the hands and jigsaw pieces, how about a dynamic logo ?

Three pieces are already there, could have symbols on them.

A hand adds a fourth gold piece, and the other pieces turn gold

An alternative could be to have the tree or a plant growing out of it--Dsrodgers34 00:22, 4 October 2013 (UTC)

The graphic is a bit of a thought bubble. Im imagining it put on a sphere like wikipedia. The vine represents the connectedness, the interlocking pieces represent exactness and scholarly work

I like this - I think a jigsaw of a tree could be a cool logo - puts together the ideas of collaboration (via puzzle) and genealogy (a tree) -- Jdfoote1 14:31, 6 October 2013 (UTC)
I agree with a lot of what jrm and others have said above, but I'm not sure a puzzle on its own is enough to communicate "collaboration". This is what I had in mind with the shaking hands, although I do agree that the 123rf logo does this better with different people putting pieces into a puzzle. AndrewRT 21:31, 8 October 2013 (UTC)
That is why I suggested different fingers putting different pieces together from opposite sides of the puzzle. Working on jigsaw puzzle with someone is a good way to learn to collaborate.--Jhamstra 22:21, 8 October 2013 (UTC)

My thought was we could leverage of the wikipedia jigsaw globe, which does suggest the collaboration, th exactness. I m suggesting the vine draped over the globe instead of the wikipedia symbols the vine is closer to the pando idea than a single tree symbol--Dsrodgers34 22:44, 8 October 2013 (UTC)

Wow! Cool! Maybe we could go with my mash-up for the Wikipedia inclusion project! :) (ok, probably not...)



Talk:Logo_Suggestions#Implying_the_Collaboration_with_Wikipedia_elements_.5B10_December_2013.5D --Artefacts 06:49, 10 December 2013 (UTC)

This logo seems a step forward to me. But the tree is too small, which I assume is to allow the features of the globe to be seen, so I would probably make it green to increase it prominence. Actually an animated gif going from the proposed picture to a smaller puzzle and bigger tree would also work, i.e., showing progress. Further, I don't like the word "free". Advertises the wrong message, imho, attracting people who want to dump their GEDCOM and invest nothing. I would prefer long-time participants because genealogy is an ongoing process: you never know if you have the final answer. I would prefer something like "Finding Out How We Relate". Personally I find the parallels with wikipedia overdone, but this would be most easily accomplished by calling it WikiRelate instead of WeRelate. --Jrich 15:21, 10 December 2013 (UTC)
I really like this. I mentioned a few concerns on the Talk page for the logo suggestions. I just wanted to chime in here to say thank you for getting this conversation going again - let's keep thinking and working on this, and get a new logo! :) -- Jdfoote1 02:09, 11 December 2013 (UTC)
I love the globe covered with puzzle pieces. Could we overlay a tree on this globe? The tree planted on top looks a bit tacky and out-of-place to me. --Jhamstra 05:15, 11 December 2013 (UTC)
I'm aesthetically challenged, and plan to abstain from the next round of voting on that basis. I did want to offer a couple ideas though (maybe they're horrid - but I wouldn't know...). What if it weren't a globe with a tree on top - but instead - a tree trunk that reached up into the globe? (a sort of lolly-pop tree). Alternatively, what if it were an incomplete puzzle piece globe (only the northern hemisphere with a handful of pieces missing) - with the trunk stretching up and starting to fan out - before it disappears into the northern hemisphere of a puzzle globe? --jrm03063 16:22, 11 December 2013 (UTC)

My vote would be for the single tree (with the poodle cut) in green on the gray puzzle piece. Also, fewer words would be better, so just "Sharing Genealogy" or some such below the image.

I never did quite get the original logo.--KayS 20:37, 11 December 2013 (UTC)

Lost GEDCOM matches [29 September 2013]

I'm in the middle of going through the errors and warnings on a GEDCOM and when I opened it today I noticed all the work I've done on it seems to have disappeared! Is this linked to the problems that other people have been having recently? Is there any way of getting it back? AndrewRT 21:11, 26 September 2013 (UTC)

From my view of your file, 120 families are matched and 143 are not matched and only 2 are updated. 249 places out of 251 are matched. Had you matched or updated more families than this, or are the matched families not appearing in your GEDCOM review? What other work had you done that is missing? Just trying to get more details so I can message Dallan. --Jennifer (JBS66) 21:32, 26 September 2013 (UTC)
Thanks - seems to be ok now. AndrewRT 20:52, 29 September 2013 (UTC)

Full source code for WeRelate available on github [10 December 2013]

The full WeRelate source code and installation scripts are now available on GitHub. This means that developers can now use the WeRelate source code to create custom family wikis and wikis for genealogical societies. In addition, it means that anyone can now help implement new features for WeRelate.org. If you have experience developing software and would like to help us move WeRelate forward, I'd love to have your help! See WeRelate talk:Website features for more information.--Dallan 02:11, 15 October 2013 (UTC)

--Artefacts 03:55, 10 December 2013 (UTC) Hi, I have no programming experience but was wondering how to start, if possible, with creating a feature that would post a summary table to a family page (or person page??) that counts the number of grandchildren, greatgrandchildren, and great-greatgrandchildren from that point and lists their birth and death locations (in summary format so that places are no duplicated?) based on pages entered. Something like this:

Grandchildren: 16 Greatgrandchildren: 42 GGGrandchildren: 108 Birthplaces: Toronto, York, Ontario Canada; London, London, England; etc. etc.

Sandbox is back [14 October 2013]

The Sandbox is back. The sandbox is a bare-bones playground that runs the same software as WeRelate but with a nearly-empty database. New features will be tested on the sandbox before they are moved to WeRelate.org. If you want to play around with ideas that you don't want to become a permanent part of WeRelate, create an account at the sandbox and try them out there.--Dallan 02:15, 15 October 2013 (UTC)

Bye for Now [27 October 2013]

This is a bit of a swan song because you may not see my contributions on the place pages for a while--I have the first of two much-needed cataract operations this afternoon. Hoping to get back to "work" in a few weeks, --Goldenoldie 09:56, 25 October 2013 (UTC)

Best wishes for a successful operation and speedy recovery :-) --Jennifer (JBS66) 10:20, 25 October 2013 (UTC)
Best wishes for a successful operation and speedy recovery.--Lidewij 14:15, 25 October 2013 (UTC)

Get back ASAP and bring back a few more as helpful and competent as you. All the best.--HLJ411 19:59, 25 October 2013 (UTC)

Get well soon! (and maybe a large monitor and large fontsize? :) ?! --jrm03063 20:07, 25 October 2013 (UTC)

Thanks for all your good wishes. The first cataract was very bad and when the dressing first came off yesterday morning I realized what the expression "seeing though a glass darkly" was all about. Now everything is bright and shiny and blue is BLUE. The screen is still pretty bright, so my not be fixing many p;ace pages for a while.

For your information, Jrm03063, I bought the bigger monitor back in August and fiddled with all kinds of settings. When I opened my computer yesterday I first headed to Excel 2007 where I can now see the upper part of the ribbon--I had been depending on lengths of words to get down to the second choices.

Hoping to get back to work on Yorkshire fairly soon (BYW I started with the West Riding). --Goldenoldie 09:04, 27 October 2013 (UTC)

Which to keep? [7 November 2013]

Two repository pages for the same thing. Which name follows conventions?


--jrm03063 15:48, 2 November 2013 (UTC)

Absent guidance, I've merged to Repository:England and Wales. General Register Office. --jrm03063 15:25, 6 November 2013 (UTC)
According to Help:Repository_pages#Is_there_a_format_for_repository_page_titles.3F, "WeRelate automatically creates a Repository page title that uses the fields you've entered to create a unique Page Title". I can't exactly work this out but I think this means it uses the place.title format, similar to sources, which would indicate that your redirection is the consistent one. AndrewRT 21:29, 7 November 2013 (UTC)

DAR Genealogical Research System [6 November 2013]

I've started working with content from this source. For starters, I found that the source was duplicated as both the "DAR Genealogical Research System" and "Daughters of the American Revolution. Genealogical Reseach System". I merged to the latter (hope that was the right choice!). After the fashion of the Find A Grave templates, I've also created a template to conveniently create references to the site's pages for ancestors (those would be folks with an assigned "Annnnnn" number). For example, for Daniel Boone, the record name for this reference contains {{dargrs|012096|BOONE, DANIEL}}, which displays as BOONE, DANIEL.

As I've worked through more pages with this reference, I've noticed that some folks cite member numbers and other sorts of pages on the DAR site, so there may be a need for several templates (and "dargrs" maybe should be "darancestor" or similar).

I'ld like to hear from anyone familiar with that site, on whether there are different types of pages worth citing from WeRelate.

I'ld also like to hear from anyone with an opinion of whether "dargrs" is a sufficient name, and/or whether the "Annnnn" number should be exposed when the template displays - I could make the above noted example display "A012096 BOONE, DANIEL", "A012096: BOONE, DANIEL", etc., etc.

Also - a quick note to the purists out there - I KNOW - this is a secondary source! But it's of a lot of interest to average folks, and it can be the basis for someone looking further.

Thanks! --jrm03063 15:22, 6 November 2013 (UTC)

Free Census [7 November 2013]

I have been asked to post this, though undoubtedly others know more about this than I. Images of all the censuses are available at archive.org for free. Some are available for free at familysearch.org (at least 1850, 1870, my favorite 1900, also 1940, maybe others). familysearch is much easier to use because they have a search engine and then just click on the link to get to the image. You can simply copy the address from the browser navigation bar to the source citation. However, the familysearch.org search engine can also be used to make archive.org easier to use (as could other search engines, such as heritagequest.com, and yes, even the ancestry search engine). As a result of this, it should be possible to totally avoid links to fee-based census images, or to convert existing links to free alternatives.

I assume using familysearch.org is easy enough to need no explanation. Then I hop over to archive.org to find the actual page. For example, search historical records at familysearch.org, I ask for Name: Theodore Roosevelt, Birth: New York 1855-1860 (he was in early 40's when became President in 1901), Residence: New York 1880-1880 (because I want 1880 census).

Usually I use the reel and image number to get close in archive.org. The familysearch film number usually has the reel number as the last three digits. In the above example, 1254895, so reel 895. Event Place is New York (city), New York (county), New York (state), United States. Image is given as 256, page 426B.

So in archive.org, I search for "1880 New York county Census" in archive.org, then find the desired reel number (895) in the list returned by archive.org. For small counties, there may be only one candidate and you can find the reel simply from the description. If you don't have the reel number, the enumeration district (ED) can also help you locate the correct reel since the description given on archive.org may list the enumeration districts covered by each reel. Click on the reel and select "view online" to browse the actual images.

Drag the slider button at the bottom over until it is on the desired image, 256. I use one up viewing, just one page at a time, for simplicity. It is my experience that the image number given by familysearch is off by one or two. So then use the page number they give, 426B, stepping forward and back until you find the desired page. In this case, page 426B turns out to be image 255. You often have to find the "A" page to find the page number, then backtrack to the "B", "C", or "D" page as necessary. Page numbers are not consistent, usually at the top, sometimes at the bottom, sometimes they have been renumbered, so this is not always this trivial, but most of the time it works well. In this case, page 426B turns out to be image 255 according to the slider, one off from where I started: dwelling 236.

For the most part, page numbers are ordered within an enumeration district, which is identified at the top of the page. So if you are not getting the right town, etc., check that the page you are viewing is in the right enumeration district. It seems like most of the time, the enumeration districts are on the film in order so you can usually jump forward and back if the first attempt doesn't put you in the correct location. I seem to recall some of the older ones (pre-1850) didn't use enumeration districts, rather alphabetical by town, but this becomes obvious pretty quickly as you page forward and back.

Most of the time I find this to be a quick process. One or two cases involved lengthy explorations. Not sure if this was pilot error, or just inaccurate or inconsistent indexing. But experience seems to make this easier. --Jrich 16:11, 6 November 2013 (UTC)

Question: Does archive.org support censuses from other countries, or just from the United States? --Goldenoldie 17:04, 6 November 2013 (UTC)

Personally I don't know. You would have to try searching from the main screen. --Jrich 17:52, 6 November 2013 (UTC)
Ok! This is great information. I'll have to take some time to digest it. I've been wanting to fix my fee-based links for a long time - since I left ancestry years ago because I didn't want to be a shill for them. Hope there aren't any hitches due to [this]! --jrm03063 20:10, 6 November 2013 (UTC)

So now I'm looking at some of my "ancestry.com" generated census cites. The first one on the page for my Grandfather comes with the usual ancestry stuff. The question - how much of this is worth keeping? The standard stuff present there is:
I'm going to start by assuming that the two ancestry.com URLs are worthless outside the ancestry.com universe (I think they may code up individual lines in the census document, but they're not doing it in a way that seems worth reverse-engineering).
Since the source title is Source:Carroll, New Hampshire, United States. 1930 U.S. Census Population Schedule, 1930, Caroll, and New Hampshire seem redundant. Enumeration district on the actual image shows as "2-5", not simply "5". Sheet No. does correspond to "Page: 5B". "Image: 548.0" seems not to have any relevance for the archive.org content - which itself is reached on page "555". I suspect that those numbers are specific to ancestry.com and archive.org respectively.
A minimal, but absolutely specific, reference to the archive.org image could be {{USCensus1930|1298|555}}, line 52 -

[[Transcript:1298, United States. 1930 U.S. Census Population Schedule/555/{{{3}}}|{{{4}}}]], line 52. But I'm reluctant to drop things like the enumeration district - which presumably had some meaning even if it isn't needed for this purpose. Likewise the sheet/page number.

 ???? --jrm03063 23:00, 6 November 2013 (UTC)
Very interesting question - I have been thinking about this myself as well, not just for the ancestry generated cites but also for the FreeCEN citations I've added myself. Given modern indexing, I suspect much of this is redundant if you know the name and location of the record in question, although I would appreciate any other views on this. As a related question, is there any benefit in splitting up the source pages into the individual areas rather than just linking them all to the generic country/census year source? AndrewRT 21:24, 7 November 2013 (UTC)
I'm starting to think that there's a role for either a translation table or even a limited (very sparse) transcript. The hierarchy for 1930 seems like this: state/county/enumeration_district/sheet/line. We've already decided that the sources for 1930 go down to the level of the county - so if you create a transcript for any given 1930 census source, you could create a hierarchy of enumeration districts, and beneath them, their pages. While each page could be a full transcript, it could also be as simple as a list of the 52? lines on that page - and a header that points at the image(s) available from various providers. Of course, the value of having the names on such pages is to link them where possible - which starts to give you a reverse-citation process that could be processed by software into nice back-links. What I don't really like is to populate the individual (person) page records with items that are artifacts of someone's scanning process - and not actual census reference parameters. --jrm03063 21:58, 7 November 2013 (UTC)

Wikipedia - over 100K pages correspond now - time for a fresh extract? [11 November 2013]

We've reached a bit of a milestone with inclusion of wikipedia content. There are now over 100,000 WeRelate pages that correspond to individual Wikipedia pages. They come in a number of forms, so I'll break it out a little bit:

  • 76,822 Place pages - (including 5084 cemeteries or burial locations, 83 castles)
  • 22,374 Person pages
  • 877 Category pages (battles, campaigns, wars, military units, royal dynasties & houses of nobility)
  • 72 Surname pages
  • 53 Repository pages
  • 47 Source pages
  • 12 Givenname pages

Among the more extensive and interestingly nested categories are Wars and Houses of Nobility.

Remember, the point of "attaching" to a WP page in this way is to try to derive whatever benefits we can from the WP community of contributors and content - both as it exists presently and as it may exist when currently modest WP articles are expanded. It doesn't mean WeRelate won't provide unique content - but we need to use care to remain engaged with as wide a community of contributors as possible. When we provide alternative content to that present on WP - we should do so because it is specifically appropriate or necessary for genealogical research. --jrm03063 19:36, 11 November 2013 (UTC)

An overly done page....! [16 November 2013]

I've taken a small but notable historical document and done everything with it that I can imagine. The document is known as The Exeter Combination, and the group can be best understood starting from the corresponding category. It has:

  • A template (transcribed text of the document, with links to appropriate Person pages)
  • A source
  • An image (which includes the template)
  • A transcript (which also includes the template)

The Person pages referenced, themselves refer to the source and include the image (which is attached to the source as an appropriate "I<n>"). The Person pages fact lists contain entries supported by the source - containing a fact that is described with a reference to the category. The only actual bit of category syntax is found in the template page.

It's much more than the situation requires, but I thought it might be an interesting example of some of the possibilities.

--jrm03063 20:04, 11 November 2013 (UTC)

Jrm, I think you've just demonstrated what WeRelate could hope to be some time in the future. --GayelKnott 20:28, 11 November 2013 (UTC)

Thank you so much for this example! I've been trying unsuccessfully to get my head around using Categories / Templates / Transcripts / Sources and what the relationships between them all are intended to be. Your example is fantastic and I've bookmarked it for future reference. One question, though - to my way of thinking a Transcript is the purest form of extract - the very words to be read. You use the Template for this function, and then refer to this from the Transcript. Is there a reason it is done this way (and thanks in advance).--Wongers 10:54, 12 November 2013 (UTC)
In principle, you're exactly right. However, I wanted the same text to appear on a transcript page and the text box for the image - but I wanted only one "live" copy for maintenance purposes. The fundamental wiki item for doing that is a template - even though we more commonly think of it as a way to do orderly parameter substitution and handle nasty little bits of syntax. An alternative approach would be to let the text live on the transcript page, and transclude that into the text box of the image. I havn't tried that (feel free to try and see what happens) but I think you would wind up with a mish-mash of transcript-specific items mixed in on the image page.
All that said, as I've continued to reflect on this, I think the approach I took creates more problems than it solves. I agree that the transcript ought to be pure and we don't want to distract from that. Instead, I might put a small "See transcript" active link in the image page's text box (perhaps also a link to the source page). The image page already has a separate mechanism for creating bi-directional links with the person page - so the hyperlinked text is semi-redundant in that respect. I'll be changing this shortly. Stay tuned and let me know what you think!
Thanks also for your kind words and observations! I had hoped a small example could bring together some of the nuances of how the different page types can be made to relate (pun intended) usefully! --jrm03063 15:31, 12 November 2013 (UTC)
Following up on my prior remarks: I've made the changes that I contemplated. I think this makes the group easier to comprehend and doesn't cost anything in terms of capabilities. Only a minor cosmetic - on the presentation of the image page - at least on my browser - the bullets of my bullet list are overlaid by the image. Can anyone offer some syntax that will cause the text to be shifted below the image - pretty much regardless of browser circumstances? --jrm03063 15:52, 12 November 2013 (UTC)
I've added some HTML into Image:Exeter Combination.jpg which I think does what you wanted. It uses style "clear:left" which causes following things to come only after the lefthand side is clear. I got the relevant syntax from Wikipedia's {{Clear}} template. (If there's a general need, we could have that template here). --robert.shaw 08:20, 16 November 2013 (UTC)
Thanks! --jrm03063 17:30, 16 November 2013 (UTC)

Early rule [2 December 2013]

The pre-1700 "Early" rule is a major turn-off from WR. The stated purpose - to save time from duplicates since almost every documented human before 1700 is already in WR - is demonstrably, clearly, starkly, and obviously mistaken. Perhaps there were multiple uploads of Mayflower passengers, however there were 150,000 to 200,000 other pre-1700 immigrants, including over 5000 enslaved Africans, besides this. (see http://www.zanran.com/preview/pdf/113151005.010101?q=north+american+immigration+history) Not to mention the millions around the world who missed their chance to immigrate to America before 1700, and the millions of Native Americans who were already here to greet the Pilgrims. And not to mention the millions of pre-1700 descendants the immigrants produced.

This rule wastes so much human time and effort. And it contradicts the stated aim of WR to link genealogies. It works squarely against that purpose. I've taken to listing pedigree outlines to link early northern Clevelands with more modern ones. Someone else can hand-enter the thousands of early Clevelands not in WR. I've done my share, thank you.

I have a pending GEDCOM upload with about 1/3 rejected because they were early. There was one semi-famous family - Richard "Bull" Smith of Smithtown, LI - that I deleted from the GEDCOM before I tried to upload it.

This amount of rejection turns the GEDCOM into a disjointed, unmanageable mess. What's the point of having a GEDCOM upload at all?

I understand the desire to control quality and merge GEDCOMs. This is not the way to do it. How about having at least one reference not to an amateur website or GEDCOM? There a thousands of WR persons without any refs at all!

Similarly the "One Date" rule is misguided. Some people - like my hillbilly southern ancestors - didn't leave many written records. This does not mean they didn't exist. Again, having some sort of source for these people would be more helpful than forcing manual entry and linking of their family members, which may entail a substantial effort for even one rejected person.

In summary, I simply don't understand why these onerous and senseless rules are tolerated. I hope they can be changed.

Prcb 21:27, 16 November 2013 (UTC)

In respect, were it not for a rule like this, WeRelate would probably not still be here.
In the early days - there were no rules. Enormous amounts of unsourced content was dumped by users who then disappeared. Those of us who want the site to succeed, have spent years trying to clean up and de-duplicate content that was loaded back then. To get an idea of the scale of the problem, I invite you to look at the page for Charlemagne. From there, go to the "what links here" page. Count up the number of "redirect" pages. Each such redirect represents a GEDCOM with lineage to Charlemagne - and many thousands of intervening individuals - every one needing de-duplication and individual editing.
You are quite right that many pages don't have references of any quality at all. That is unfortunate - but it too is a product of the early days of no rules at all. It's not a great reason to continue an unsound practice.
We have found that the larger the GEDCOM - the greater the reason to be concerned. The best use - and only one I would suggest for a GEDCOM - is to use it for your personal and immediately documented family. Perhaps a few thousand individuals at most. If you are determined to bring a large amount of material to the site - then we would suggest breaking your GEDCOM into chunks.
Finally - if you feel that your content is of an unusually high quality - you can ask that the rules be waived. You would need to justify that - but it's a possibility if you really have some good content. --jrm03063 21:48, 16 November 2013 (UTC)

Your comments are perpendicular to my criticism.

I quite agree with breaking the GEDCOM into chunks and merging small pieces. This would be my my plan.

Likewise, I understand that regulating GEDCOM imports to WR is essential and important. I am remarking that you are doing it wrongly and harmfully.

It is rather astounding that you would allow this criticism, which illustrates how unnecessarily painful WeRelate is to use for many people with substantial new content to contribute, to pass without some cogent response.--Prcb 22:15, 16 November 2013 (UTC)

Simply for clarification, all but one of the excluded individuals within your GEDCOM already have Person pages represented on WeRelate. Peter and Alice Wright and Nicholas Wright and Margaret Nelson are two of the families which represent many of your Wright family ancestors. It is unfortunate that the upload system did not match the pages to show you this fact, but hopefully this will help to at least resolve the immediate issue, if not the far-reaching issue you describe.--Khaentlahn 22:37, 16 November 2013 (UTC)

Indeed the rejected ones are in WR. This casts doubt over my impression that many of my uploads are being spuriously rejected. Are matches not shown for pre-1700 uploads? If so, in my case it gave a negative impression about WR.

Also, please forgive my use of the word "senseless". I believe your policies and procedures are for good purpose and intentions.

Prcb 23:20, 16 November 2013 (UTC)

Perhaps someone with experience on the back-end of this system can answer your question about the way individuals are matched in the upload system (that would not be me, sorry). All the best, --Khaentlahn 23:36, 16 November 2013 (UTC)

Point taken about the vast number of people before 1700 not in WeRelate. I have made the same argument myself in the past, and was granted the right to upload people prior to 1700 (after demonstrating the quality of post-1700 data I was uploading). I recently uploaded a number of German Mennonites living in Prussia in the 1600's, with just a handful of matches. However, I support the WeRelate rule because I believe that it gives us a reasonable balance between efficiency of uploading information and effectiveness in getting it right. I spent 6 months cleaning up medieval data in WeRelate and just scratched the surface (luckily others have taken up the work), so I am well aware of the garbage that was dumped in WeRelate through GEDCOM uploads prior to the establishment of the rule.

Once you prove yourself to be a careful contributor (well-researched and cited data, good citizen about matching and not adding duplicates, etc.), and if you still find that you have a significant amount of pre-1700 data that is not in WeRelate, ask for the right to upload it.

A note about the absence of dates: While you might not have dates for some of your ancestors, a GEDCOM with no dates at all is usually a sign of unsubstantiated poor quality data (hence the rule). If it is truly impossible to find any dates for a whole tree, it should be at least possible to estimate some years, which adds greatly to the value of the information. If this is not possible, that particular tree might not be ready for sharing. My personal approach is to add at least an estimated birth year to every record that has no dates, as it is extremely useful in searching (and has also helped me to discover errors in family groupings).

Welcome to WeRelate. I hope you find that through collaboration, you find information to add value to your own personal family tree.--DataAnalyst 15:35, 17 November 2013 (UTC)

I felt I had to offer a defense of the measures taken to avoid GEDCOM dumping. While I'm sorry for the burden that some people feel they impose, I remain of the belief that WeRelate would have died without them.

The measures taken to avoid bad GEDCOM dumps can, and should, continue to be reviewed and discussed.

Were it up to me - the real measure wouldn't be on any GEDCOM - but on the user offering the GEDCOM. I would allow new users a tiny amount of total GEDCOM upload content - perhaps a few hundred people. I would expand it as a function of the hand-edits/contributions that they made, and/or on the basis of the quality of the work they were seen to be doing. I'm not concerned if a GEDCOM starts out as weak content - as long as the user is committed to WeRelate and to the ongoing integration and improvement of whatever they're adding. --jrm03063 22:20, 17 November 2013 (UTC)

I'd like to second Jrm's reasoning for NOT allowing pre-1700 gedcoms. I too have spent perhaps hundreds of hours cleaning up many inaccurate and unsubstantiated lineages that were "dumped" here, left for many of us to cleanup the "mess" left behind. It is certainly easy for some to criticize what has evolved here (perpendicular or not), especially when they have no idea how much time has been spent by many here making sure WeRelate doesn't turn into what most of the "Ancestry Member Trees" have become, poorly researched, poorly sourced and questionable lineage at best. There have been way to many "gedcom dumpers" that have come here and left for us to turn back the clock and go back to how it was. We've learned from this, and frankly, even though it is somewhat more difficult, we don't need to repeat the mistakes we've already learned from. Those who think otherwise have not "walked in our shoes"..... --Delijim

A bit late to this party, but I have to agree with the pre 1700 rule, which can be waived in certain circumstances. I have spent the last year cleaning up alot of unsourced pre 1700 ancestries. I've started to make a crack at nobility/visitations, but the going there is slow. The amount of garbage that was dumped here in 2007-9 is STAGGERING. Between myself and about 4-5 other admins, we have deleted about 25,000 'living' person pages, with over 90,000 left to go, and another unknown number of 'livings' that are simply undated. The early site was pure chaos. JRM is right. Without these 'strict' rules, this site would probably today be a parked godaddy webpage. Daniel Maxwell 13:55, 2 December 2013 (UTC)
I have to say I'm also a bit frustrated about this rule. It can be particularly annoying to have the "heads" chopped off a GEDCOM upload - the temptation is to leave them off rather than going through and manually adding them back in again. It's interesting that people are open to "waivers" for experienced contributors and I think this would be a positive thing to publicise more - it would give an incentive for people to stay around and contribute more! I wonder if it's worth have something more formal and more explicit about saying that experienced users - maybe ones who have already been here x months and uploaded y GEDCOMs - are allowed to upload GEDCOMs with an earlier date cut-off or ones that are larger in size? AndrewRT 22:25, 2 December 2013 (UTC)
The rule for it probably needs to be formalized. I think if you are an established user, and you are able to show that 1) the material you are adding is of a high quality, and 2) that there not many (or any) duplicates (this is key I think), then on a case by case by basis it could be waved after checking by an admin. I would never want to see 'auto-waving' because it would bring back the old problems, particularly with royals/nobles/unsubstantiated lines going back to 100 BC.. But I don't know that I would publicize it so much - when the general public hears something like that they may think "WR is dropping their standards" Daniel Maxwell 23:49, 2 December 2013 (UTC)

Content Language Neutrality via Wikipedia/Wikidata [5 December 2013]

Moved this item to WeRelate:Suggestions/Content Language Neutrality via Wikipedia/Wikidata, and follow up discussion to the associated talk page. --jrm03063 18:30, 6 January 2014 (UTC)

Policy update regarding inclusion of obituaries [5 December 2013]

The Overview Committee has updated WeRelate's policy regarding the inclusion of Obituaries. This policy is similar to those found on other websites (such as Find-A-Grave). As with other texts, if an obituary is published after 1923, it may be subject to copyright and should not be added to WeRelate. However, some of the facts contained in the obituary such as name, age, birth/marriage/death/burial dates and places, names of parents/spouse/siblings/children are not copyrighted. You may include a link to the obituary (if published online), a brief summary of the facts (please exclude names of living relatives), the name of the newspaper, and date of publication. The full policy can be found here.--Jennifer (JBS66) 11:59, 4 December 2013 (UTC)

The policy was revised slightly to be more in line with guidelines that appear on Help:FAQ that say "On pages for People/Families who are deceased, information about still living people that is publicly available (ie, 1940 census data) - can be included on the pages." That is why I crossed out a bit of the text above. --Jennifer (JBS66) 12:10, 5 December 2013 (UTC)
Just to be clear - I'm not seeing a policy change per se. This seems only to be a revised description of practice, calculated to better help people to avoid inadvertently infringing. Right? If not, then I'm missing something... --jrm03063 14:58, 5 December 2013 (UTC)

Savage Transcript Contents Updated! [9 December 2013]

The contents page for the WeRelate transcript of Savage's Dictionary has been rebuilt.

The former version was obtained from direct processing of Dr. Kraft's ASCII files, using logic that was necessarily imprecise. The result being that section names were sometimes abruptly shortened (leaving out alternate name forms) or even missed altogether. The new version is built directly from the WeRelate transcript pages, processed through a program that recognizes the section marking template. While not strictly a part of the transcript (Savage's dictionary had no such table), I hope others will find it as helpful as I have.

For example, the following:




And, this:




Besides offering a more faithful representation of Savage's section names/introducers, the new index also creates a single link entry per transcript page (combining all the sections that begin on a particular page into a single link - hence a larger individual text/mouse target). Since we don't have anchors that allow addressing within individual pages, there is no value in having separate links that all head to the same page. Separate links are also now set off from each other with bullets, while sections on the same page are set off with a semi-colon.

Questions, comments and corrections welcomed!

--jrm03063 17:36, 9 December 2013 (UTC)

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 [30 jul 2014]

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)

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)